News

GitLab Fleeting: flexible resources for your tests

GitLab provides you with a comprehensive platform for software development that goes far beyond pure source code management and that you can host yourself, which makes it different to similar products. In the process, GitLab Runners carry out your automated tests and can dynamically request the required computing power from e.g. cloudscale. In the past, GitLab used Docker Machine for this purpose, but this was deprecated quite some time ago, so GitLab "Fleeting" was developed as a modern replacement and we provided the appropriate cloudscale plugin. This means that the required cloud resources are always available for your tests.

The advantages are obvious: with sufficient computing power, it takes less time to run through (or even get to) your pipelines and you receive the feedback required for the next stage of work more quickly. If there is nothing to be tested, the resources can automatically be deleted, thus minimizing costs. By regularly replacing GitLab Runners with new instances, you also reduce the risk of your tests being falsified by accumulated artifacts, configs, and the like.

Try out autoscaling for yourself

The cloudscale plugin for GitLab Fleeting was written in cooperation with Puzzle ITC AG and to a significant extent by Yannik Dällenbach. In his blog post at Puzzle, Yannik takes you through the development process step by step. In our Engineering Blog, Denis Krienbühl additionally provides you with insights into the packaging of the plugin. If you want to try it out immediately, you can set up a GitLab server with Runners and plugin in a few steps using an Ansible playbook and some brief instructions, which will allow you to test autoscaling in a risk-free, hands-on manner.

The best way to do this is to create a new project in the cloud control panel (this makes it clear at all times what is part of your test) and to create an API token with write access within this project. You will also need a Python environment from where you initiate the creation of the setup. Depending on your system, you may also need to add some additional software packages; a virtual server with a fresh Ubuntu 24.04 LTS installation, for example, will be missing python3.12-venv. There is no assumption, however, that you are using Ansible already, as the repository provides everything you need to automatically set up a GitLab server with autoscaling.

Start by cloning the "gitlab-runner" repository and then follow the few required steps in the Readme. After running the playbook, which may take a while, you will find two new virtual servers in your cloudscale project. As the name implies, your GitLab installation will run on the "gitlab" server. You can access it via an HTTPS-protected web interface, and the access data is provided towards the end of the playbook output. There is also an instance of "GitLab Runner" on this server, which is responsible for the dispatching of CI jobs and the creation/deletion of the virtual servers required for them. In addition, you will find a "fleeting-*" virtual server, which is already available for your first CI jobs. Further servers of this kind will be automatically created and deleted again as required.

The Readme also contains a sample CI job so that you can see your Runners in action at once. This job tests whether it can access artifacts in the shared CI cache. If you activated the s3_cache during setup and indicated access data to a bucket in our object storage, the job should notify you that it has found the cache from the second run onwards. Take a look at the configuration behind the scenes, too: you can, for example, choose which flavor and thus which level of performance the servers use for your CI jobs. You can also determine how much spare capacity needs to be available for immediate use at any time – even based on specific days and times.

If you do not yet have a self-hosted GitLab, use our Ansible playbook to create a fully functional setup in a jiffy and start using it at once. If you prefer a manual setup or if you already work with GitLab, have a look at the code of our Fleeting plugin and of the playbook and simply take what is suitable for your use case. Use the full performance when your CI jobs require it – and reduce your costs at other times.

Always exactly what you need.
Your cloudscale team