GitLab CI und CD installieren und konfigurieren
Quo vadis, DevOps?
Continuous Integration und Delivery hilft beim frühzeitigen Aufdecken von Fehlern. Mit on Premises betriebenem GitLab CI/CD und dessen Web-IDE hat man auch Multiplattformanwendungen im Griff.
Dass „Works on my machine“ keine hinreichende Auslieferungsvoraussetzung ist, merkt man spätestens dann, wenn die Anwender sich beschweren, weil die Programme bei ihnen nicht sauber laufen. Das mag zum Beispiel daran liegen, dass mit einer aktuellen Version der eingesetzten Programmiersprache entwickelt wurde, in der Produktion aber noch ein Enterprise-Linux der vorletzten Version im Einsatz ist. Im Zweifel müsste jeder Entwickler nun alle unterstützten Plattformen in einer lokalen Umgebung nachstellen. Das ist zwar mit dem Einzug von Vagrant-VMs und Docker-Containern deutlich einfacher geworden als früher. Doch neben dem immer noch nicht zu unterschätzenden Aufwand beim Aufsetzen solcher Testumgebungen müsste das jeder Entwickler und Release-Manager direkt vor der Release machen, was das Auslieferungsdatum zu einem „Moving Target“ werden lässt.
Als Lösung entstand in den letzten Jahren das Konzept „Continuous Integration“. Nicht erst vor der Auslieferung, sondern sobald ein Git-Commit in das zentrale Repository geladen oder ein neues Feature in einem Branch entwickelt ist, starten entsprechende Tests automatisch. Das Feedback erhält der Entwickler direkt als Pop-up oder Mail, und er kann den Fehler sofort analysieren und korrigieren.
Auf Continuous Integration (CI) folgt dann Continuous Deployment beziehungsweise Continuous Delivery (CD), die sofortige Ausspielung auf Staging- oder Produktionssystemen, was sogenannte „Rolling Releases“ impliziert.
GitLab CI: Installieren und konfigurieren
Die Basisinstallation von GitLab liefert bereits die notwendigen Komponenten für CI mit. Auf dem lokalen Server läuft ein CI-Runner, der Docker-Container starten kann. Es empfiehlt sich jedoch, von vornherein eine dedizierte VM mit genügend Ressourcen bereitzustellen und lediglich mit einem CI-Runner zu bestücken. So vermeidet man, dass andere Jobs und Container die Performance von GitLab selbst beinträchtigen. Schon der GitLab-Server ist sehr ressourcenhungrig – im Hintergrund laufen die Komponenten Ruby on Rails, nginx, PostgreSQL und Redis und bieten Webinterface, REST-API und Hintergrundjobs an.
Für die Installation von GitLab bietet sich das Omnibus-Paket an (siehe Kasten „Erste Schritte“). Nicht vergessen, zum Schluss das Administratorpasswort zu ändern! Die weitere Einrichtung von GitLab sieht vor, dass man sich Gedanken über Benutzer, Gruppen, Organisationen und Rollen macht und die Projekte mit Git-Repositories verwaltet. Um GitLab CI/CD ein wenig besser kennenzulernen, kann man zunächst mit dem Administrator-Account weiterarbeiten. Zum Testen reicht auch, wie in den gezeigten Beispielen, eine kostenlose Installation bei einem Cloud-Anbieter wie NWS (alle Onlineverweise sind auf ix.de/ix1904118 zu finden).
GitLab CI Runner: Plattformübergreifend durch Go
GitLab CI Runner sind in Go geschriebene Dienste, schlanke Runtime-Umgebungen, die auf fast jeder Plattform laufen können. Als Hostsystem können Linux, Windows, macOS und FreeBSD dienen. Auf jeder dieser Plattformen läuft auch Docker. Die Runner im klassischen Anwendungsfall führen direkt Shell- oder PowerShell-Skripte aus.