Das Feld der Softwareentwicklung hat in den letzten zehn Jahren einige revolutionäre Veränderungen durchlaufen. Eine dieser "Revolutionen" ist im Umfeld von DevOps entstanden. Development- und Operations-Teams werden hier in einen gemeinsamen Arbeitsprozess eingebunden. Eine weitere liegt im Dunstkreis von Continuous Integration und Continuous Delivery (CI/CD), eine Methode, bei der Devops-Teams konstante, inkrementelle Updates für eine Codebasis liefern. Damit verbunden ist der Wechsel von monolithischen Codebases zu Cloud-basierten Microservices, die in Containern laufen, welche wiederum mit Orchestrierungs-Plattformen wie Kubernetes verwaltet werden.
Container-basierte Anwendungen, die auf geclusterten Systemen oder in der Cloud laufen, können komplex und schwierig zu verwalten sein - selbst wenn sich eine Plattform wie Kubernetes um die Orchestrierung kümmert. GitOps ist ein neuer Ansatz, der diese Verwaltungsaufgaben durch die Anwendung von Techniken aus der Welt von Devops und CI/CD vereinfachen soll.
Der Grundgedanke von GitOps ist die Idee von "Infrastructure as Code", die bei Provisionierung von Infrastruktur denselben Ansatz verfolgt wie DevOps bei Applikationen. Sowohl die App als auch die zugrundeliegenden Host-Maschinen und Netzwerke werden in Dateien beschrieben, die innerhalb eines Versionskontrollsystems - wie jeder andere Code - behandelt werden können. Automatisierte Prozesse sollen dann dafür sorgen, die tatsächliche Anwendung mit der in den Dateien beschriebenen Idealform zu konvergieren. Im GitOps-Jargon ist der Code im Versionskontrollsystem die "Single Source of Truth", die darüber Auskunft gibt, wie die App in der Produktion aussehen sollte.
GitOps - Definition
GitOps-Anbieter Weaveworks hat wesentlich zur Popularisierung des Konzepts beigetragen. Die GitOps-Definition des Unternehmens umfasst zwei Aspekte:
Ein Betriebsmodell für Kubernetes und andere Cloud-native-Technologien, das eine Reihe von Best Practices für die Vereinheitlichung von Deployment, Mangement und Überwachung von containerisierten Clustern und Apps bereitstellt.
Ein Weg zu einer "Developer Experience" für die Verwaltung von Anwendungen, bei der End-to-End-CI/CD-Pipelines und Git-Workflows sowohl für den Betrieb, als auch für die Entwicklung eingesetzt werden.
Mit anderen Worten: GitOps ist ein spezielles Methodenset, um Kubernetes und ähnliche Plattformen zu managen. Darüber hinaus eignet sich GitOps aber auch für ein breiteres Einsatzgebiet, da immer mehr Entwicklungsabteilungen DevOps-Praktiken übernehmen und Code in die Cloud migrieren. Um zu verstehen, wie GitOps funktioniert, ist es nötig, das Methodenset näher kennenzulernen.
Git-Definition
Das "Git" in GitOps bezieht sich auf das äußerst beliebte Versionskontrollsystem, das 2005 von Linus Torvalds entwickelt wurde. Git ist ein Tool, mit dem Entwickler-Teams gemeinsam an der Codebasis einer App arbeiten können. Dabei werden verschiedene Zweige des Codes gespeichert, an denen gearbeitet wird, bevor sie in den Produktionscode eingebunden werden. Ein wichtiges Konzept bei Git ist der "Pull-Request", bei dem ein Entwickler formell darum bittet, einen Code, an dem er gearbeitet hat, in einen anderen Zweig der Codebasis zu integrieren.
Ein Pull-Request bietet den Teammitgliedern die Möglichkeit, vorab Konsens darüber zu erzielen, ob der neue Code in die Anwendung aufgenommen werden soll. Git speichert auch ältere Versionen des Codes, was bei Störungen den Rückgriff auf die letzte korrekte Version erleichtert. Zudem sind die Änderungen zwischen den Revisionsschritten leicht zu erkennen. Git bildet auch die Grundlage von GitHub, einem in der Cloud gehosteten Versionskontrollsystem. Bei Git handelt es sich um Open Source Software, die überall eingesetzt werden kann - von internen Firmenservern bis hin zum Privat-PC.
Zu betonen ist auch, dass Git zwar in der Regel als Programmierungs-Tool gesehen wird, aber eigentlich unabhängig von den konkreten Inhalten ist, für die man es heranzieht. Git behandelt beliebige Textdateien als "Codebasis" und kann zum Beispiel von Autoren verwendet werden, die Änderungen an einem gemeinsamen Werk nachverfolgen möchten. Das ist wichtig, weil ein Großteil der GitOps-Kern-Codebasis aus deklarativen Konfigurationsdateien und nicht aus ausführbarem Code besteht.
Außerdem gut zu wissen: Obwohl "Git" im Namen steht, erfordert GitOps nicht die Verwendung von Git. Unternehmen, die bereits in eine andere Versionskontrollsoftware (wie zum Beispiel Subversion) investiert haben, können GitOps ebenfalls implementieren. Git ist in der DevOps-Welt allerdings aufgrund der Implementierung von CI/CD ohnehin schon weit verbreitet, so dass die meisten GitOps-Projekte am Ende Git verwenden werden.
Was ist der CI/CD-Prozess?
Ein vollständiger Blick auf CI/CD würde den Rahmen dieses Artikels sprengen. Dennoch lohnt ein kurzer Einblick, weil CI/CD im Kern der Funktionsweise von GitOps steht. Die "kontinuierliche Integration" (CI) wird durch Versionskontroll-Repositories wie Git ermöglicht: Entwickler können ständig kleine Verbesserungen an ihrer Codebasis vornehmen, anstatt alle paar Monate oder Jahre riesige, neue Monolithen auszurollen. Das "kontinuierliche Deployment" (CD) wird durch automatisierte Systeme (sogenannte Pipelines) realisiert, die den neuen Code bauen, testen und in der Produktion einsetzen.
Auch wenn hier immer wieder von "Code" die Rede ist, meint das nicht einen ausführbaren Code, der in einer Programmiersprache wie C, Java oder JavaScript geschrieben wurde. Bei GitOps besteht der verwaltete "Code" größtenteils aus Konfigurationsdateien. Dieser Umstand ist nicht nur ein beiläufiges Detail - er ist das Herzstück von GitOps. Die Konfigurationsdateien bilden nämlich die "Single Source of Truth", die eher deklarativ als anweisend beschreibt, wie das System aussehen soll. Statt beispielsweise die Anweisung "Starte zehn Server" zu geben, ist der Inhalt der Konfigurationsdatei: "Dieses System enthält zehn Server."
Die "CI-Hälfte" der GitOps-Gleichung ermöglicht es den Entwicklern, schnell Verbesserungen an diesen Konfigurationsdateien durchzuführen; geht es um die "CD-Hälfte", tun automatisierte Software-Agenten ihr Bestes, um sicherzustellen, dass die Live-Version der App die Beschreibungen in den Konfigurationsdateien widerspiegelt.
GitOps und Kubernetes
Ursprünglich wurden die Konzepte von GitOps für die Verwaltung von Kubernetes-Anwendungen entwickelt. Weaveworks gibt eine Zusammenfassung, wie Updates an einem nach GitOps-Prinzipien verwalteten Kubernetes vorgenommen werden sollten:
Ein Entwickler stellt einen Git-Pull-Request für ein neues Feature.
Der Code wird geprüft, genehmigt und dann in die Hauptcodebasis eingebunden.
Die Zusammenführung löst die CI/CD-Pipeline aus, die den neuen Code automatisch testet, umbaut und an eine Registry weiterleitet.
Ein Software-Agent bemerkt das Update, holt sich den neuen Code aus der Registry und aktualisiert die Konfigurationsdatei (geschrieben in YAML) im Konfigurations-Repository.
Ein Software-Agent im Kubernetes-Cluster erkennt anhand der Konfigurationsdatei, dass der Cluster nicht mehr aktuell ist, übernimmt die Änderungen und stellt die neue Funktion bereit.
Weaveworks und GitOps
Es ist klar, dass ein großer Teil der Arbeit auf die Schritte 4 und 5 entfällt. Die Software-Agenten, welche die "Quelle der Wahrheit" im Git-Repository mit der realen Kubernetes-Anwendung synchronisieren, sind die Magie, die GitOps möglich macht. Wie bereits erwähnt, wird der Prozess der Annäherung des Live-Systems an das in den Konfigurationsdateien beschriebene Idealsystem in der GitOps-Sprache "Konvergenz" genannt. Idealerweise würde die Konvergenz durch automatisierte Prozesse erreicht, aber die Automatisierung stößt an Leistungsgrenzen. Dann ist menschliches Eingreifen notwendig.
Neben dieser sehr allgemeinen Beschreibung des Prozesses lässt sich auf der Weaveworks-Website sehen, dass die erwähnten "Software-Agenten" tatsächlich Teil der Weave-Cloud-Plattform des Unternehmens sind. Der Begriff "GitOps" wurde von Weaveworks-CEO Alexis Richardson geprägt und dient zum Teil dazu, die Weaveworks-Plattform für Entwickler interessant zu machen, die bereits in der Devops- und CI/CD-Welt zu Hause sind.
Trotzdem hat Weaveworks nie ein Monopol auf GitOps beansprucht, da dies mehr einer grundlegenden Herangehensweise und einer Reihe von Best Practices als einem spezifischen Produkt gleichkommt. Wie im Blog von CloudBees zu lesen ist, stellt GitOps ein offenes, herstellerneutrales Modell dar, das als Reaktion auf die verwalteten, proprietären Kubernetes-Lösungen der großen Cloud-Anbieter AWS, Google und Micrsoft entwickelt wurde. CloudBees bietet - wie eine Reihe weiterer Anbieter - auch eigene GitOps-Lösungen an.
GitOps und Devops
Atlassian hat einen ausführlichen Blogbeitrag über die Geschichte und den Zweck von GitOps verfasst. Aus Sicht des Softwareunternehmens stellt GitOps eine logische Ausweitung des DevOps-Konzepts dar. Genauer gesagt ist GitOps eine Weiterentwicklung von "Infrastructure as Code", das seinerseits aus dem DevOps-Milieu hervorgegangen ist. GitOps schloss aus Sicht von Atlassian die Lücke zwischen den bestehenden DevOps-Techniken zur Lösung von Problemen bei der Systemadministration und den spezifischen Anforderungen von verteilten, in der Cloud gehosteten Anwendungen. Die automatisierte Konvergenz, die von verschiedenen Cloud-Anbietern angeboten wird, ist das, was GitOps besonders macht.
Obwohl sich GitOps bis heute auf Kubernetes konzentriert, dürfte deutlich geworden sein, wie es auf den breiteren Kontext der verteilten, Cloud-basierten Apps anwendbar ist. Ein Blogbeitrag des Open-Source-Sicherheitsanbieters WhiteSource umreißt die Vorteile von GitOps:
Observability: GitOps-Systeme bieten Monitoring, Logging, Tracking und Visualisierung in komplexen Anwendungen, sodass Entwickler Probleme präzise lokalisiern können
Versionskontrolle und Änderungsmanagement: Ein wesentlicher Vorteil von Versionskontrollsystemen wie Git: Fehlerhafte Updates können leicht zurückgenommen werden.
Leichte Akzeptanz: GitOps baut auf den DevOps-Fähigkeiten auf, die viele Entwickler bereits besitzen.
Produktivität: GitOps bietet die Produktivitätssteigerungen, die DevOps und CI/CD in anderen Bereichen erzielt haben.
Auditing: Dank Git kann jede Aktion zu einem bestimmten Commit zurückverfolgt werden, was es einfach macht, die Ursache von Fehlern aufzuspüren.
Selbst wenn Sie Kubernetes nicht nutzen: Die Chancen stehen gut, dass GitOps früher oder später Teil Ihres Workflows sein wird.
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.com.