The Uncloud Howto delves deep(er) into what you get when you have an Uncloud cluster to play with. Keeping services within a cluster up to date is essential, but manually updating versions can quickly become tedious. This guide explains how to connect a GitLab project to an Uncloud cluster to automate the deployment of new images and services. Prerequisites An Uncloud cluster. For Gitlab to have access the config.yaml should: current_context: test contexts: test: connections: - ssh: uc@uncloud5.vm.science.ru.nl ssh_key_file: $UNCLOUD_SSH_PRIVATE_KEY machine_id: 0b104736144524a903ae4d523c0e0ed5 The idea of the $UNCLOUD_SSH_PRIVATE_KEY variable is that it is populated by Gitlab. SSH access to the cluster. See the access section. As the SSH private key need to be uploaded into GitLab it is advisable to just create another SSH key of type login for cluster access. Make sure your application is available as a container image. See our image project for an example. You’ll need a runner that is able to run docker or docker-in-docker. Of course you are also free to run container images from the Docker registry. A compose.yaml with the services you want to deploy. See compose.yaml changes for Uncloud specific differences below in this document. CI/CD Configuration Next, we need to teach Gitlab how to connect to the cluster. Lets create the following variables in the Gitlab project: ...

You were just given an Uncloud cluster. Now what? This howto explains what Uncloud is, why we think its needed and some pointers other documentation. At the end you’ll find a FAQ like section. We very much want Uncloud to profit from our use, so our intention is to upstream as much documentation as possible. Also see my personal journey with Uncloud; those articles are also in the process of being integrated with the Uncloud documentation. ...

See the Uncloud howto for tips and details on how to run your cluster. Some time ago C&CZ experimented with remotely managing docker containers. This turned out to be a success and a failure. A success because it filled a niche, and a failure because we had not thought through all the security implications. We are currently looking at launching a new system for managing containers called Uncloud. The security boundary for this will be a virtual machine. I.e. we supply you with a virtual machine with Uncloud running and you and your colleagues can control it using the Uncloud tooling. ...