GitOps in der Softwareentwicklung
Die Geschwindigkeit der Softwareentwicklung hat aufgrund der neuen Anforderungen durch die Digitale Transformation in den letzten Jahren immens zugenommen. Diese Entwicklung ist noch nicht am Ende, da kontinuierlich neue Ansätze gefunden werden um Prozesse effizienter zu gestalten und zu beschleunigen. GitOps ist ein neues Konzept, bei dem der IT-Betrieb (Engl. „Operations“) noch weiter automatisiert werden soll. Eine wichtige Kernkomponente ist der vollständig deklarativ und versionierte Zielzustand, der in Git definiert ist. Eine spezielle Software vergleicht kontinuierlich diesen Zielzustand mit dem Ist-Zustand auf der Infrastruktur und sorgt dafür, dass der Zielzustand hergestellt wird.
GitOps vs. Continuous Delivery vs. DevOps
Rein von der Begrifflichkeit „GitOps“ lässt sich eine gewisse Verwandtschaft zu DevOps vermuten. Allerdings bezeichnet der Begriff DevOps ein eher abstrakte Mentalität zur Zusammenarbeit ehemals getrennter Berufsgruppen wie Development und Operations. GitOps hingegen ist deutlich konkreter und fokussiert sich auf den Betrieb (Ops). Der Betrieb mittels GitOps passt dennoch gut zu einer DevOps-Mentalität. Laut dem Erfinder des Begriffes GitOps, Alexis Richardson, ist GitOps sogar der richtige Weg DevOps zu machen (siehe unten verlinktes Interview). Wir sind der Meinung, dass GitOps prinzipiell auch ohne DevOps gemacht werden kann (beispielsweise als Operations-Team). Umgekehrt ist auch DevOps ohne GitOps möglich. GitOps setzt Praktiken wie „Infrastructure as Code“ (IaC), Configuration As Code und Konfigurationsmanagement konsequent durch. Die Grundideen von GitOps werden am deutlichsten im Vergleich zum klassischen, imperativen Continuous Delivery (CD) mittels CI-Server. Dies wird zur Abgrenzung von GitOps mittlerweile als CIOps bezeichnet.
CIOps-Ansatz
Im CIOps-Ansatz wird der Sourcecode von den Entwicklern in der Sourcecodeverwaltung gespeichert. Von dort holt sich der CI-Server die Daten, führt die Builds und Tests imperativ durch und legt die im Build erstellte Applikation (bestehend aus einem oder mehreren „Artefakten“, beispielsweise ein Docker© Image) auf einem Server (Artifact Repository oder Registry) ab.
Anschließend wird das Deployment der Applikation vom CI-Server vorgenommen (Push-Prinzip). Die Konfiguration für das Deployment kann im CI-Server vorgenommen oder auch in Git abgelegt und versioniert werden. Dabei ist es auch denkbar, dass der CI-Server den Zustand noch verändert. Häufig schreibt er die gerade gebaute Version des Artefakts in die Deployment-Beschreibung.
GitOps-Ansatz
So wie der Continuous-Delivery-Ansatz setzt auch GitOps darauf, dass alle Informationen in der Sourcecodeverwaltung gepflegt werden. Der Unterschied jedoch ist, dass sich die Betriebsumgebung ihren Zustand direkt aus dem Git synchronisiert (Pull-Prinzip) und nicht der CI-Server das Deployment übernimmt. Dieser kümmert sich nur noch um Build und Tests. Die Konfiguration muss also vollständig im Git versioniert sein.
Das Deployment in der Betriebsumgebung wird durch einen kontinuierlich ausgeführten „Reconciliation Loop“ angestoßen, welcher alle Abweichungen vom Ziel-Zustand erkennt und versucht diese auszugleichen. Die Betriebsumgebung konvergiert dadurch immer zum Ziel-Zustand. Auch Fehler können dadurch automatisiert behoben werden. Im Prinzip ist das „Continuous Operations“.
Durch diesen Ansatz entstehen mehrere Vorteile:
- Die vollständig deklarative Beschreibung wird durchgesetzt. Es sind keine imperativen Schritte durch den CI-Server mehr möglich. Dadurch werden die Auditierungen und die Reproduzierbarkeit verbessert.
- Mehr Sicherheit:
- Der Cluster bekommt alle notwendigen Informationen aus Git. Dadurch lassen sich Zugriffe von außen auf diesen Cluster weiter einschränken.
- Der CI-Server benötigt keinen Zugriff auf den Cluster. Daher müssen dort keine Zugangsdaten hinterlegt werden.
- Der Zugriff auf Git ist organisatorisch oft einfacher zu bekommen, als Zugriff auf einen API-Server (Stichwort: Firewall-Freischaltung).
Eine formellere Definition von GitOps ist derzeit bei der GitOps Working Group, einem Projekt der CNCF in Arbeit. Dabei entstehen die GitOps-Prinzipien, die eine eindeutige Abgrenzung zwischen GitOps und CIOps ermöglichen sollen.
Mehr Details zur Motivation und zur Geschichte hinter GitOps gibt dieses Interview mit Alexis Richardson von Weaveworks, der dort 2017 den Begriff GitOps prägte:
GitOps und Kubernetes
Die Idee zu GitOps entstammt dem Kubernetes-Umfeld. Mittlerweile entstehen aber auch immer mehr Möglichkeiten, GitOps mit anderen Betriebsumgebungen zu nutzen. Die Umsetzung von GitOps erfolgt bei Kubernetes nach dem Operator-Pattern. Ein Operator ist eine Cloud-native Anwendung, die den Betrieb von anderen Anwendungen unterstützt. Ein GitOps-Operator (oft auch „Custom Controller“ genannt) prüft kontinuierlich den im Git beschriebenen Ziel-Zustand gegen den Ist-Zustand des Clusters. Bei Änderungen passt der GitOps Operator den Cluster entsprechend an. Die bekanntesten Implementierungen sind Flux und ArgoCD. Beide sind Projekte der Cloud Native Computing Foundation, unter deren Schirmherrschaft auch Kubernetes entwickelt wird.
GitOps für die Infrastruktur
Für Anwendungs-Deployments in Kubernetes ist GitOps ausgereift und wird bereits in Produktion verwendet. GitOps ist allerdings nicht auf diesen Anwendungsfall beschränkt. So lassen sich GitOps-Operatoren auch für das Ausrollen von Kubernetes-Clustern verwenden. Die Vorteile in der Nutzung von GitOps für den Betrieb der Infrastruktur zeigen sich vor allem beim Skalieren: Ein einzelner Cluster kann noch einfach über eine grafische Oberfläche konfiguriert werden. Bei steigender Anzahl von Clustern werden aber früher oder später Automatisierung und programmatische Ansätze notwendig. Ein solcher Ansatz ist GitOps.
Eine Möglichkeit zum Ausrollen von Kubernetes Clustern ist die Cluster API (CAPI). Über das Erstellen von Kubernetes-Clustern hinaus entstehen auch zunehmend Möglichkeiten, verschiedene Infrastructure-as-Code-Werkzeuge (IaC) wie Terraform mit GitOps zu nutzen. Allerdings sind viele der vorhandenen Tools ebenfalls als Operator für Kubernetes umgesetzt. Wer GitOps ganz ohne Kubernetes umsetzen will hat daher nur wenig Auswahl. Generell zeigt sich aktuell noch, dass der Reifegrad von GitOps mit der Nähe zur Infrastruktur abnimmt. Anwendungs-Deployments sind ausgereift, Ausrollen von Clustern funktioniert schon recht gut, physische Infrastruktur lässt sich noch nicht per GitOps betreiben.
GitOps Werkzeuge
Zur Implementierung von GitOps stehen eine wachsende Zahl an GitOps-Werkzeugen zur Auswahl. Unser Blogartikel „Automatisierungsgehilfen: GitOps-Werkzeuge im Vergleich“ gibt hier eine Übersicht. Er unterscheidet Tools aus folgenden Kategorien:
- Werkzeuge für Kubernetes (Operatoren),
- ergänzende Werkzeuge (Security Management und Deployment Strategien) und
- infrastrukturnahe Werkzeuge (CAPI, Terraform, Ansible, VMs).
Die Kategorisierung von Werkzeugen als „GitOps-Werkzeug“ wird dadurch erschwert, dass eine einheitliche Definition des Begriffs GitOps derzeit noch nicht existiert. Zudem besteht ein gewisser Hype um den Begriff und Produktanbieter schmücken sich sehr gerne mit der Bezeichnung GitOps. Insofern ist bei der Auswahl des passenden Werkzeugs für eigene Anwendungsfälle ein genauer Blick gefragt.
Der verlinkte Artikel bietet zudem eine Liste von Kriterien, die unserer Erfahrung nach in der Praxis durch ein GitOps-Werkzeug erfüllt werden sollten. Als Beispiel enthält der Artikel einen Vergleich zwischen den beiden bekannten GitOps-Operatoren ArgoCD und Flux.
Weitere Übersichten über GitOps-Werkzeuge finden Sie bei awesome-gitops und gitops.tech.
GitOps bei Cloudogu
Bei Cloudogu setzen wir GitOps schon seit einiger Zeit zum produktiven Betrieb des Backends unseres EcoSystem ein. Diese Erfahrung haben wir in unsere Open-Source-Bibliothek GitOps-Build-Lib für Jenkins überführt (siehe auch unseren Blogartikel zu CIOps vs. GitOps mit Jenkins). Die GitOps-Build-Lib erleichtert den Übergang von CIOps zu GitOps in dem sie beispielsweise eine Verzeichnisstruktur vorgibt und Schritte wie Validierung (fail early), Staging und die Erzeugung von Pull-Requests sowie Templating von Kubernetes Manifesten im CI-Server automatisiert. Außerdem ermöglicht sie den gesamten Code einer Anwendung im Anwendungs-Repository (App Repo) zu halten. Die Überführung ins GitOps-Repository automatisiert der CI-Server. Dies erleichtert unter anderem die lokale Entwicklung, weil „alles an einem Ort ist“ und hier kein GitOps-Operator notwendig ist.
GitOps (mit Application Repository)
Wer erste praktische Erfahrungen mit GitOps und Kubernetes ohne große Konfiguration sammeln möchte, dem steht mit unserem GitOps Playground ein weiteres Open Source Projekt zur Verfügung.
