GitOps ist nicht mehr nur ein Buzzword; es ist im Grunde eine Methodik, die für Entwickelnde wie uns geschaffen wurde, um die Art und Weise zu verändern, wie wir Software ausliefern. Sowohl in den Unternehmen als auch auf den Konferenzen stellen wir ein großes Interesse für das Thema GitOps fest. Kurz gesagt: GitOps ist hier, um zu bleiben.
Die vier Prinzipien als Grundlage
Die Idee von GitOps basiert auf DevOps, das eine engere Integration von Entwicklung und Betrieb anstrebt. GitOps selbst wird durch vier Prinzipien zusammengefasst: Das System wird deklarativ beschrieben und versioniert in einem Repository hinterlegt. Ein GitOps-Operator überwacht das Repository kontinuierlich und gleicht den Systemzustand mit dem Soll-Zustand ab. Dadurch erreichen wir höhere Zuverlässigkeit und Stabilität. Durch kontinuierliches Ausrollen wird die zeitliche Diskrepanz zwischen Soll- und Ist-Zustand des Systems für uns Entwickelnde drastisch reduziert. So können sich Entwickelnde auf Anforderungen konzentrieren und sowohl neue Features entwickeln als auch die Zuverlässigkeit des Systems erhöhen.
GitOps geht über reine Technik hinaus.
Auf den ersten Blick scheint GitOps eine rein technische Methodik zu sein. Allerdings beinhaltet GitOps auch soziotechnische Merkmale, welche die anfänglichen schnellen Erfolge aufheben können, wenn Kultur, Prozesse und Tooling nicht an die neuen Gegebenheiten angepasst sind. Wir glauben, dass Teams, die beginnen, GitOps einzuführen, mit Enttäuschungen rechnen müssen, bis die Zuverlässigkeit in Bezug auf die Performance der Softwarelieferung und den Erfolg der Organisation nachhaltig wieder steigt.
Asynchronität und Secrets Management
Ebenso verändert die bei GitOps inhärente Asynchronität bestehende Deployment-Flüsse tiefgreifend. Das Verwalten von Secrets im oder außerhalb des Git-Repository ist eine weitere Herausforderung, der wir uns bei GitOps sehr explizit stellen müssen.
Argo CD und Flux
Natürlich ist auch eine gute Tool-Auswahl wichtig, um GitOps erfolgreich einzuführen. Glücklicherweise stehen uns mit Argo CD und Flux zwei ausgereifte Lösungen zur Verfügung, die jeweils individuelle Stärken und Schwächen haben. In diesem Buch konnten wir einige davon vorstellen, aber der Teufel steckt oft im Detail. Argo CD ist benutzerfreundlicher und für Einsteiger einfacher, während Flux modular aufgebaut und flexibler einsetzbar ist.
GitOps Chasm
Eine weitere Herausforderung besteht darin, die Tools so einzusetzen, dass sie zum eigenen Anwendungsfall passen. Beim Design des GitOps-Prozesses ist die Herausforderung die Überwindung des GitOps Chasm, also die Abbildung der Realität auf die vorhandene Infrastruktur: Wir haben Teams, Anwendungen und Environments, die wir abbilden auf Kubernetes-Cluster, GitOps-Operatoren und Repositories. Hierbei ist es ratsam, das Gesetz von Conway zu beachten, das heißt: die Kommunikationsbeziehungen der eigenen Organisation zu kennen und diese in seinem Prozess entsprechend aufzugreifen, beispielsweise durch ein Repo per Team-Pattern.
Kubernetes als Plattform
Die Prinzipien von GitOps lassen sich auch abseits der bekannten Pfade wie Kubernetes, Flux oder Argo anwenden, wie wir in diesem Buch an zwei Beispielen zeigen konnten. Was wir mit Sicherheit sagen können, ist, dass die Zukunft deklarativ sein wird. Der deklarative Ansatz sowie die Möglichkeit, Kubernetes durch eigene CRDs zu erweitern, schaffen ein enormes Potenzial auch außerhalb des KubernetesÖkosystems. Wir haben dies in den weiterführenden Kapiteln bereits beschrieben, aber der Trend geht dahin, dass Kubernetes als Plattform für weitere Lösungen genutzt wird. Wir glauben, dass dieser Ansatz die Akzeptanz von GitOps erhöhen wird, da Unternehmen zunehmend nach Methoden suchen, um ihre Softwarebereitstellung agiler, zuverlässiger und sicherer zu gestalten.
Wachsende Tool-Landschaft
Das Tool-Ökosystem für GitOps wird weiterhin expandieren, indem bestehende Tools verbessert und neue Lösungen entwickelt werden. Schon jetzt gibt es mehr Tools, als wir in diesem Buch vorstellen können. Jenseits von Argo CD und Flux gibt es beispielsweise GitOps-Operatoren wie Jenkins X37, Fleet38 oder das im Buch kurz erwähnte PipeCD. Neben den im Buch genannten CM- und CLI-Tools oder Operatoren wie Helm, Kustomize, Jsonnet, Cuelang, Timoni und TestKube gibt es Tools wie Werf39, Updatecli40, Carvel41, Keptn42, kpt43 und Kargo44. Diese sind weitere Alternativen, die uns als Entwickelnde unterstützen können. Viele dieser Tools bieten Operatoren, die Kubernetes-typisch asynchron, lose gekoppelt und kontinuierlich arbeiten und damit kompatibel mit den Prinzipien von GitOps sind – GitOps liebt Operatoren! Daher können wir diese Tools unkompliziert in bestehende Prozesse integrieren. Auch im Bereich der Infrastruktur wird GitOps weiter wachsen. Der Übergang von Terraform zu OpenTofu als Projekt der Linux Foundation kann hier ein Türöffner für breitere Community-Arbeit sein.
Lebendige Community
GitOps beziehungsweise OpenGitOps erhält weiterhin Unterstützung von einer aktiven und wachsenden Community. Die Beteiligung an Open-Source-Projekten und der Austausch bewährter Praktiken werden die Entwicklung vorantreiben und neue Innovationen fördern.
Insgesamt wird die Zukunft von GitOps von einer kontinuierlichen Anpassung an die sich ändernden Anforderungen der Softwareentwicklung und -bereitstellung geprägt sein. Die Prinzipien von GitOps werden weiterhin eine wichtige Rolle dabei spielen.
Grenzen des Buchs
Die weiterführenden Themen Infrastruktur und Multi-Cluster mit GitOps sowie GitOps außerhalb von Kubernetes sind groß und komplex. In diesen Bereichen hoffen wir mit diesem Buch zumindest einen Blick über den Tellerrand des Applikationsbetriebs auf Themen zu geben, die in Zukunft ebenfalls von GitOps bestimmt werden könnten.
Dasselbe gilt für das Thema Sicherheit. Hier sprechen wir einige Themen an wie die Vorteile von GitOps in diesem Bereich, Secrets Management, Mandantentrennung und Zugriffsschutz, Shift Left und statische Codeanalyse, Least Privilege, Supply Chain Security, Aufruf externer Binaries sowie Security und Network Policies. Hier bleibt noch Raum für Erweiterung, beispielsweise für eine dedizierte Betrachtung des Themas Sicherheit mit Fokus auf GitOps. Auch hilfreich können Designprinzipien in Bezug auf Sicherheit beim Entwurf des GitOps-Prozesses sein. Neben dem bereits genannten Least Privilege halten wir Defense in Depth, die Betrachtung von Pfaden zur Privilege Escalation, Vulnerability Scanning, Signaturen und Runtime Security für betrachtenswert. Ein Threat Modelling an einem beispielhaften GitOps-Prozess bietet sicherlich Raum für Erkenntnisse.
Auch verspricht eine Betrachtung bestehender Dokumente und Standards aus dem Cloud-Native-Umfeld mit Fokus auf GitOps Mehrwerte. Dabei denken wir an Richtlinien wie den »Kubernetes Hardening Guide« von NSA/CISA45 (mit eigenem Threat-Modell), den Grundschutz des BSI für Kubernetes46, die Cloud Native Security Map47 oder das Cloud Native Security Whitepaper der CNCF48 (das tatsächlich bereits ein Kapitel zu GitOps enhtält).
All diese Themen bieten Raum für eigene Bücher oder zukünftige Auflagen.