Wie viele andere Agenturen setzen wir CI/CD in unseren Projekten ein. Das Prinzip ist simpel: Entwickler schreiben Code, pushen ihn nach GitLab, und nach jedem Push laufen automatisierte Build- und Test-Jobs – z. B. statische Codeanalyse, Akzeptanztests, usw.
Sobald ein Merge in den Main-Branch oder ein Tag erfolgt, starten automatische Deployments in Test- und Produktionsumgebungen.
Für unsere CI-Jobs nutzten wir virtuelle Maschinen von Hetzner Cloud. Die Plattform bietet eine gute API, eigene Tools für GitLab CI und ist "Made in Europe".
Unsere Infrastruktur bestand aus drei Teilen:
Um die Anlaufzeit beim Start einer VM zu umgehen, hielten wir tagsüber einen Pool von VMs im Standby. Das Setup war lange stabil und skalierbar.
Mit Hetzners wachsender Popularität stieg auch die Last auf deren Infrastruktur. Mehr und mehr CI-Jobs scheiterten schlicht an fehlenden Ressourcen in den Hetzners Rechenzentren – teilweise nach minutenlangem Warten, was extrem frustrierend war.
Kein Vorwurf an Hetzner – sie wurden schlicht Opfer ihres eigenen Erfolgs.
Auch die Performance-Limits der Cloud-Instanzen machten sich bemerkbar: Full-Stack-Tests brauchten bis zu 15 Minuten, manche Testszenarien stürzten mit OOM-Fehlern ab.
Hinzu kam, dass docker-machine, die Software zum Verwalten der Hetzner-VMs, mittlerweile deprecated ist und durch Fleeting ersetzt werden soll – ein neues, pluginbasiertes Produkt, das von GitLab selbst entwickelt wird.
Ein Umstieg auf Fleeting hätte unser Grundproblem jedoch nicht gelöst – auch die Entwickler des Hetzner-Plugins für Fleeting kämpfen mit dem Problem von den beschränkten Ressourcen.
Kurzzeitig haben wir erwogen, in die Public Cloud zu wechseln – also GCP, Azure oder AWS. Alle drei Anbieter werden offiziell von Gitlabs Fleeting-Architektur unterstützt, haben eine ausgereifte API für VM-Management und sind durch viele andere Agenturen im Einsatz erprobt.
Letztlich haben wir uns jedoch dagegen entschieden, und zwar aus folgenden Gründen:
Als ITler wissen wir: Fast jedes Problem lässt sich mit Kubernetes lösen 🙂
Trotzdem haben wir uns dagegen entschieden.
Im Alltag arbeiten wir mit einem völlig anderen Stack. Unser Tagesgeschäft sind FreeBSD- und Linux-Server – Container nutzen wir fast ausschließlich in lokalen Entwicklungsumgebungen oder für spezielle Edge-Cases.
Eine Kubernetes-basierte CI-Infrastruktur neu aufzusetzen, hätte eine steile Lernkurve, erheblichen Zeitaufwand sowie zusätzlichen Setup- und Wartungsaufwand bedeutet.
Unzufrieden mit den Alternativen sprachen wir mit TYPO3-Core-Entwickler Stefan Bürk über deren Test-Infrastruktur, ihre Entstehung und die Herausforderungen dabei.
Auf den ersten Blick wirkt ihr Ansatz fast altmodisch: statt Cloud-VMs nutzt TYPO3.org Runner auf dedizierten Bare-Metal-Servern.
Der Effekt: keine Wartezeiten für VM-Provisioning und genug Power, um hunderte von CI-Tests kontinuierlich auszuführen.
Anstelle von Docker setzen sie auf Podman, ein OCI-Runtime mit entscheidenden Vorteilen:
Inspiriert von TYPO3 mieteten wir einen dedizierten AX102-Server bei Hetzner: 128 GB RAM, 16 CPU-Kerne.
Statt GitLab-Server + Control-Node + Cloud-VMs gibt es nun: GitLab-Server + einen leistungsstarken Runner.
Das bringt sofortige Vorteile:
TYPO3.org stellt seine Core Testing Infrastructure der Community als öffentlichen Service zur Verfügung. Jeder Contributor kann die CI-Infrastruktur nutzen, um seinen Code zu testen und zu validieren.
Dadurch sind natürlich eine Reihe von Sicherheitsmaßnahmen notwendig:
Neben diesen Sicherheitsaspekten liegt ein starker Fokus auf einem reproduzierbaren Test-Workflow, der sowohl lokal als auch in der CI laufen kann.
Dafür gibt es ein einheitliches Testskript namens ./runTests.sh, das auch auf Entwickler-Rechnern ausgeführt werden kann.
Diese Maßnahmen funktionieren im Kontext der TYPO3-Testinfrastruktur sehr gut, da dort ausschließlich ein einziges Softwareprojekt (TYPO3) innerhalb klar definierter Umgebungen getestet wird.
Bei punkt.de hingegen nutzen wir unsere CI, um eine Vielzahl an Projekten auf Basis unterschiedlicher Technologien zu bauen und zu testen – darunter natürlich TYPO3, aber auch Neos, Keycloak, Sylius und Ansible.
Eine Beschränkung auf bestimmte OCI-Images und die Nutzung eines einheitlichen Testskripts würde in unserem Fall jedoch bedeuten, zahlreiche Ausnahmen einzubauen und eine Menge Edge-Cases für die unterschiedlichen Projekte und Technologien manuell abzufangen.
Wie es der Zufall wollte, hatten wir bereits einen Großteil unserer CI-Pipelines auf GitLab CI/CD Components migriert.
Anstatt für jedes Projekt eine komplett neue Pipeline zu schreiben, können wir so einheitliche, wiederverwendbare und gleichzeitig individuell anpassbare Bausteine definieren, die in jedes Projekt importiert werden können.
Beispiele: Wir haben eigene CI Components für composer, npm, php-stan, php-cs usw.
Dadurch war der Umstieg auf Podman im Wesentlichen nur eine Frage, diese Components auf Podman anzupassen. In den einzelnen Projekten selbst waren somit nur minimale Änderungen notwendig.
Unsere Full-Stack-Tests laufen mit docker-compose. Podman bietet zwar podman-compose, aber dieses ist nicht vollständig kompatibel.
Fehlende Features: Healthchecks und der --wait-Parameter. Lösung: zusätzliche docker-compose.override.yml, in denen Healthchecks und service_healthy-Dependencies deaktiviert werden, z.B.
services:
php:
depends_on: !reset null
postgres_schema_modify: !reset null
keycloak:
depends_on: !reset nullDa wir uns nicht auf Healthchecks verlassen konnten, setzten wir auf einfachere Methoden, etwa wiederholte curl-Aufrufe gegen Endpunkte, bis diese „ready“ zurücklieferten.
Abgesehen davon konnten wir die Tests mit nur geringen Anpassungen auf Podman umstellen.
In den Ubuntu/Debian-Repositories war zum Zeitpunkt des Setups nur Podman 4.x verfügbar – mit bekannten Bugs bei der DNS-Auflösung. Wir mussten Domain-Namen hartkodieren, um Probleme zu vermeiden.
Die Bugs sind in Podman 5.x behoben, das allerdings erst in Ubuntu 25.04 enthalten ist. Unsere Lösung: Pakete aus 25.04 einbinden und die Podman-abhängigen Pakete pinnen. Nicht ideal, aber funktional.
Der Umstieg hat sich gelohnt – die Zahlen sprechen für sich:
Und am wichtigsten: keine instabilen Jobs mehr durch Ressourcenmangel.
Vorher zahlten wir zwischen 200 € und 240 € pro Monat für die Cloud-Infrastruktur.
Jetzt: 104 € für einen AX102-Runner – mit deutlich mehr Leistung.
Die Maschine ist bis heute weit davon entfernt, an ihre Grenzen zu stoßen.
Natürlich ist auch dieses Setup nicht perfekt. Dinge, die man bedenken muss:
Dem stehen klare Pluspunkte gegenüber:
Nach einigen Monaten im Einsatz sind wir überzeugt: Der Wechsel von Cloud-VMs zu Bare Metal hat sich absolut gelohnt.
Um anderen den Umstieg zu erleichtern, haben wir die Ansible-Rolle, mit der wir unseren GitLab Runner eingerichtet haben, veröffentlicht. Probiert sie aus, richtet eure eigenen Runner ein und gebt uns Feedback.
Und wenn ihr ebenfalls eure Pipelines beschleunigen und gleichzeitig Kosten reduzieren möchtet, bieten wir auch GitLab-Consulting an – kontaktiert uns gerne für Details.
