Cloudscale Logo
2025
Juli
31
2025

Fleeting: GitLab Runners automatisch skalieren

Cloud-Computing ermöglicht die Nutzung von Server-Ressourcen nach Bedarf. Im Fall von cloudscale stehen neue virtuelle Server innert Sekunden bereit; werden die Server nicht mehr benötigt, können sie – und mit ihnen die entsprechenden Kosten – genauso schnell auch wieder abgebaut werden. Die Software-Entwicklung mit Continuous Integration und automatisierten Tests ist ein Paradebeispiel für eine solche Nutzung. GitLab mit Fleeting und dem cloudscale-Plugin macht es dir dabei leicht, diese Vorteile voll auszureizen.

GitLab Fleeting: Flexible Ressourcen für deine Tests

GitLab bietet dir eine umfassende Plattform für die Software-Entwicklung, die weit über die reine Sourcecode-Verwaltung hinausgeht und die du – im Unterschied zu ähnlichen Produkten – selbst hosten kannst. GitLab Runners führen dabei deine automatisierten Tests aus und können dynamisch die dazu benötigte Rechenleistung anfordern, z.B. von cloudscale. Früher hatte GitLab hierzu auf Docker Machine zurückgegriffen, das jedoch seit Längerem "deprecated" war. Als moderner Ersatz wurde deshalb GitLab "Fleeting" entwickelt und passend dazu unser cloudscale-Plugin. Damit hast du jederzeit die nötigen Cloud-Ressourcen für deine Tests zur Verfügung.

Die Vorteile liegen auf der Hand: Mit ausreichend Rechenpower wartest du weniger lange, bis deine Pipelines durchgelaufen sind (oder überhaupt erst an die Reihe kommen), und hast schneller das Feedback, das du zum Weiterarbeiten brauchst. Gibt es gerade nichts zum Testen, so können die Ressourcen automatisch abgebaut und die Kosten damit minimiert werden. Indem die GitLab Runners regelmässig durch neue Instanzen ersetzt werden, senkst du zudem das Risiko, dass deine Tests durch angesammelte Artefakte, Configs und ähnliches verfälscht werden.

Autoscaling einfach selbst ausprobieren

Geschrieben wurde das cloudscale-Plugin für GitLab Fleeting in Zusammenarbeit mit Puzzle ITC AG und zu einem wesentlichen Teil von Yannik Dällenbach. In seinem Blogbeitrag bei Puzzle kannst du Yannik sozusagen Schritt für Schritt bei der Entwicklung zusehen. Einblicke ins Packaging des Plugins gibt dir zudem Denis Krienbühl in unserem Engineering Blog. Wenn du gleich zum Ausprobieren übergehen möchtest, kannst du mit einem Ansible Playbook inklusive kurzer Anleitung einfach und in wenigen Schritten einen GitLab Server mitsamt Runner und Plugin aufsetzen und das Autoscaling gefahrlos "hands-on" testen.

Der Server "gitlab" beherbergt die GitLab-Installation, die "fleeting-*" Server werden nach Bedarf automatisch erstellt und gelöscht.

Am besten erstellst du dazu im Cloud Control Panel ein neues Projekt – so ist jederzeit klar, was zu deinem Test gehört –, und in diesem Projekt ein API-Token mit "Write access". Zudem benötigst du eine Python-Umgebung, aus der heraus du das Aufsetzen des Setups anstösst. Abhängig von deinem System musst du möglicherweise noch einzelne Software-Pakete ergänzen; bei einem virtuellen Server mit frischem Ubuntu 24.04 LTS etwa fehlt noch python3.12-venv. Nicht vorausgesetzt wird hingegen, dass du bereits mit Ansible arbeitest: Das Repository bringt alles Nötige mit, damit du deinen GitLab Server mit Autoscaling automatisiert einrichten kannst.

Beginne mit dem Klonen des Repositories "gitlab-runner", und folge den wenigen nötigen Schritten im Readme. Nach dem Ausführen des Playbooks, das eine Weile in Anspruch nehmen kann, findest du in deinem cloudscale-Projekt zwei neue virtuelle Server. Auf dem Server "gitlab" läuft – wie der Name vermuten lässt – deine GitLab-Installation. Diese erreichst du über ein HTTPS-geschütztes Web-Interface; die Zugangsdaten werden dir gegen Ende des Playbook-Outputs angezeigt. Ebenfalls auf diesem Server läuft eine Instanz von "GitLab Runner", die für das Dispatching von CI-Jobs und den Auf-/Abbau der dafür nötigen virtuellen Server zuständig ist. Daneben findest du einen virtuellen Server "fleeting-*", der schon für deine ersten CI-Jobs bereitsteht – weitere solche Server werden nach Bedarf automatisch erstellt und wieder entfernt.

Der Beispiel-CI-Job prüft, ob er auf den gemeinsamen CI Cache zugreifen kann.

Im Readme findest du auch einen Beispiel-CI-Job, um deine Runners gleich in Aktion zu sehen. Dieser Job prüft, ob er auf Artefakte im gemeinsamen CI Cache zugreifen kann; hast du beim Setup den s3_cache aktiviert und die Zugangsdaten zu einem Bucket in unserem Object Storage angegeben, sollte der Job ab dem zweiten Durchlauf melden, den Cache gefunden zu haben. Schau auch mal in die Konfiguration hinter den Kulissen: So ist es etwa dir überlassen, welchen Flavor und damit wieviel Performance die Server für deine CI-Jobs mitbringen. Auch kannst du bestimmen, wieviel "spare" Kapazität jederzeit zur sofortigen Nutzung bereitstehen soll – sogar abhängig von Wochentag und Uhrzeit.


Wenn du noch kein selbstgehostetes GitLab hast, richtest du dir mit unserem Ansible Playbook im Handumdrehen ein voll funktionsfähiges Setup ein, mit dem du gleich loslegen kannst. Wenn du ein manuelles Setup bevorzugst oder sogar bereits mit GitLab arbeitest, dann wirf einen Blick in den Code unseres Fleeting-Plugins und des Playbooks und übernimm einfach, was zu deinem Use-Case passt. Hol dir die volle Performance dann, wenn deine CI-Jobs sie brauchen – und spar dir die Kosten für den Rest der Zeit.

Immer genau das, was du brauchst.
Dein cloudscale-Team

Zurück zur Übersicht