GitLab-CI-Setup mit Vagrant und Ansible
Bausatz zur Automatisierung
Bei der Installation von GitLab-CI gibt es unter anderem wegen des Einsatzes von TLS-Zertifikaten Hürden. Mit Ansible und Vagrant lässt sich ein automatisiertes Setup einrichten.
Wie lässt sich GitLab mit passender CI-Pipeline vollständig automatisiert aufsetzen? Von Let’s-Encrypt-Zertifikaten über die Container-Registry bis zur Konfiguration der Runner gibt es einige Stolperfallen. Dieser Artikel zeigt, wie diesen mit Infrastructure-as-Code-Werkzeugen wie Ansible der Schrecken genommen werden kann.
Seit einiger Zeit fällt die Wahl des Continuous-Integration-Servers (CI) nicht mehr automatisch auf Jenkins. Dass gerade bei Open-Source-Projekten beliebte TravisCI nutzt beispielsweise eine prägnante und leicht zu lernende YAML-Syntax für die Definition der CI-Pipelines. Dagegen wirken die oft ausufernden Pipeline-Definitionen in der Groovy-Syntax der Jenkins-Files komplex. Zusätzlich eröffnen diese mit der Zeit die nächste Wartungshölle – neben dem eigentlichen Source Code der Anwendungen.
Allerdings ist TravisCI eine Software aus der Cloud. Oft möchte man die Kontrolle über den CI-Server aber nicht vollständig abgeben. An dieser Stelle bietet sich der Einsatz von GitLab-CI an. Das stellt die CI-Pipeline direkt als Teil des Git-Servers bereit. Ein zentraler Git-Server ist meist sowieso notwendig innerhalb einer Continuous-Integration-Pipeline. Der Integrationsaufwand zwischen Git- und CI-Server entfällt demzufolge.
Zertifikate für nicht öffentliche URL
Obwohl inzwischen mit der GitLab-Omnibus-Installation ein ausgereifter Prozess bereitsteht, bleiben für das komplette Setup einige Hindernisse bestehen. Das fängt schon bei den notwendigen Zertifikaten für die Domain an, die für GitLab grundsätzlich verwendet werden sollte. Denn ist der Server nicht öffentlich erreichbar, funktioniert das automatische Generieren von Let’s-Encrypt-Zertifikaten leider nicht.
Soll noch ein moderner CI/CD-Ansatz auf Basis von Docker implementiert werden, wird die GitLab-Dokumentation schnell unübersichtlich. Besonders auf die richtige Konfiguration der Container-Registry und der GitLab-Runner ist zu achten. Durch die größere Isolierung dank Containern können auf der anderen Seite unerwünschte Wechselwirkungen zwischen Builds vermieden werden. Denn so bekommt jede Anwendung genau die Umgebung geboten, die sie für einen optimalen Build benötigt. So lässt sich die Konfiguration des CI-Pipeline-Servers von der der Anwendung entkoppeln.
Außerdem verringert man die Abhängigkeit von einem konkreten CI-System: CI-Pipelines auf Basis von Docker lassen sich leicht zu einem anderen CI-Server migrieren. Nicht zuletzt kann der grundsätzliche Aufbau der CI-Pipeline für beliebige Programmiersprachen und Frameworks wiederverwendet werden, was vor allem im Umfeld von Microservice-Architekturen zu Wartbarkeit und Transparenz beitragen kann. Die GitLab-CI-Dokumentation empfiehlt den folgenden Ablauf:
build: Docker-Images für die Applikationen erzeugen,
test: Tests gegen die Docker-Images und die davon abgeleiteten Container laufen lassen,
push: Docker-Images in der Registry ablegen,
deploy: Anwendungen als Docker-Container auf die Umgebungen verteilen.
Einen GitLab-CI-Server auf Knopfdruck
Mit dem Pipeline-as-Code-Ansatz wird bereits die CI-Pipeline-Definition innerhalb eines Versionskontrollsystems aufbewahrt und für jeden im Team transparent. Infrastructure-as-Code-Werkzeuge dehnen diese Transparenz auf die Installation und Konfiguration des CI-Servers selbst aus. Neben der vollständigen Dokumentation aller notwendigen Schritte führt diese Automatisierung dazu, dass ein neuer GitLab-CI-Server in wenigen Minuten und ohne manuellen Eingriff einsatzbereit ist.
Für den vorliegenden Artikel kommen Vagrant und VirtualBox für die Infrastrukturautomatisierung zum Einsatz. Ansible setzt darauf auf und bringt Provisionierung, Konfigurationsmanagement und Deployment in das Setup ein. Alle Werkzeuge sind leicht austauschbar. An die Stelle von VirtualBox kann ein beliebiger Server treten, egal ob im eigenen Rechenzentrum oder in der Cloud. Statt Vagrant bietet sich eventuell Terraform an – wichtig ist nur die vollständige Automatisierung des Setups.