Das GitOps System

Werden in einer IT-Landschaft mehrere Applikationen kontinuierlich deployed und Betrieben — meistens von verschiedenen Teams — kann die IT-Landschaft schnell unübersichtlich werden. Ein Ansatz um das Problem zu beheben ist GitOps. In diesem Beitrag zeige ich die Vorteile auf, die GitOps bringt und welches Problem es löst.

Damit Applikationen ausgeführt werden, müssen diese auf einer IT-Infrastruktur (z.B. auf einem Cluster) deployed sein. Nicht selten werden allerdings mehr als eine Applikation, häufig von verschiedenen Teams, auf dieser IT-Infrastruktur deployed.

CI-Ops

Im Bild: Das CI Ops System ist ein klassisches Szenario mit drei Teams zu sehen. Jedes dieser Teams entwickelt eine Applikation mit ihrem eigenem Source-Control-Management (SCM) System wie beispielsweise git. Gibt es eine Änderung im Source Code, wird diese in das SCM eingecheckt, welches wiederum ein Continious Integration (CI) System instruiert, den Source Code zu kompilieren und auf Qualitätsstandards zu überprüfen.

Hier folgt häufig der Step des Continous Deployment (CD)-Systems, häufig in Form von bash-scripts o.Ä., welches dafür sorgt dass das ausführbare Artefakt der Applikation auf die Infrastruktur, im Falle des Bildes des Clusters, ausgeführt bzw. aktualisiert wird.

Es gibt also viele CD-Systeme die das Deployment-System mutieren. Aufgrund, dass viele CI-Systeme das Deployment am Ziel-System bestimmen, wird dieses System häufig auch CI-Ops genannt. Es gibt damit einen IST-Zustand der IT-Landschaft. Beobachtbar ist, was in welcher Version deployed ist.

Es ist allerdings nirgendwo zu erkennen, was in welcher Version deployed sein soll, oder welche Version der Applikation vorher deployed wurde, um Rollback-Szenarien abzudecken. Eine Historie über verschiedene Deployments hinweg fehlt weitesgehend. Der IST-Zustand ist somit beobachtbar, der SOLL-Zustand der Landschaft existiert nicht, bzw. ergibt sich implizit aus dem IST-Zustand. Das führt dazu, das vor allem Konfigurationen des Systems AD-Hoc deployed werden. Die IT-Landschaft verliert einen wichtigen Faktor des Site-Reliability Engineering: Die Nachvollziehbarkeit — “Was wäre wenn meine Landschaft heute woanders komplett neu aufgezogen werden muss” (Mit Einschränkung: dazu später mehr).

Der SOLL-Zustand

Die Idee ist jetzt also ganz simpel: Der SOLL-Zustand muss abgebildet werden. Damit dieser SOLL-Zustand hergestellt werden kann, muss dieser in einem Format beschrieben werden, das es erlaubt Deployments verschiedener Applikationen deklarativ zu beschreiben.

Die Differenz zwischen dem Bild: Das CI-Ops-System und Bild: Das GitOps System ist, dass es eine extra Komponente, ein git-Repository, gibt, das genau diese Beschreibungen persistent, versioniert, vorhält: Die Single Source of Truth. Hier steht genau beschrieben, was in welcher Version deployed sein soll.

Damit CI-Systeme also neue Versionen der Applikationen ausrollen können, müssen diese anstatt laufende Prozesse hoch und herunterzufahren, den persistenten SOLL-Zustand im git-Repository verändern.

Wichtig ist noch das Kern-Stück zu erkennen. Nachdem der Zustand im git-Repository beschrieben ist, muss auf dem laufenden System ein Agent laufen, der den SOLL-Zustand des git-Repositories in einem bestimmtem Interval aktualisiert, und den IST-Zustand auf den SOLL-Zustand übertragt.

Dabei ist zu erkennen, dass keines der CI-Systeme mehr Zugriff auf die in der Produktion laufenden Systeme erhält, wie durch den vertikalen Strich symbolisiert. Die einzige Schnittstelle zwischen laufendem System und CI-System ist das Repository. Damit ist jede Änderung am Gesamtsystem durch eine versionierte Historie nachvollzieh- und zurückrollbar. Menschen können durch gewohnte git-Flows zur IT-Landschaft beitragen, Beiträge gereviewed werden und der Zugriff auf das Cluster von einzelnen Teams minimiert werden.

GitOps ist also der Schritt aus vielen CI/CD-Systemen die in ein laufendendes System eingreifen, einen gemeinsamen bewussten Soll-Zustand herauszulösen, der automatisch durch einen Agent vom Zielsystem übernommen werden kann. Das bringt Vorteile in der Nachvollziehbarkeit und geschenkten Historie. In der Theorie ist es möglich auf einem beliebigen Cluster einen Agent zu platzieren, welcher sich mit der Source of Truth synchronisert und somit ist die IT beinahe portabel (z.B. um von K8s-AWS auf ein On-Premise Cluster umzuziehen). In der Praxis gibt es natürlich diverse Unterscheide. Beispielsweise ist es bei self-hosted Systemen nötig ein eigenes Block-Storage-System (wie beispielsweise longhorn) bereitzustellen, bzw einen Ingress-Controller zu installieren, während bei GCP oder AWS diverse Komponenten bereits inklusive sind. Dieser Aufwand ist aber in der Regel minimal.

Bewusstsein für zustandsvolle Systeme

Natürlich hat gitOps auch Grenzen. Zwar ist das Zurückrollen durch einfache git commands möglich

git revert 00de44c4

das betrifft aber in erster Linie das Deployment / die Konfiguration. Der Entwickler ist nicht davon erlöst, zustandsvolle Systeme wie Datenbanken gewissenhaft zu migrieren.

Beispiel: Eine Applikation kann in zwei Versionen deployed sein: Version 1 benötigt eine DB-Tabelle Users um lauffähig zu sein, während diese in Version 2 wieder gelöscht wurde. Im Bild ist am Ende vom Deployment von Version 2 und dessen Migration die Datenbank leer und die Version 2 lauffähig. Passiert jetzt im git-Repository ein Rollback auf Version 1, ist die Applikation erst einmal nichtmehr lauffähig. Kein Problem das nicht lösbar ist, aber was einem bewusst sein sollte: Daten auf externer Systeme auf Block Storages wie Datenbanktabellen, Images aus Docker Registries etc. sind nicht durch gitops betroffen. Es kann z.B. auch passieren, dass im git-Repo eine alte Image Version referenziert wird, die eventuell im Zustandsvollen System, der Docker Registry, gelöscht wurde.

Fazit

GitOps ist die Idee, Systeme als Code abzubilden. Dabei werden Secrets, Konfigurationen und Listen von Applikationen in einem Text-Format innerhalb eines git-Repositories gepflegt. Durch etablierte git-workflow-Prozesse, wie Pull Requests und Rollbacks wird ein Kollaboratives Arbeiten am Gesamtsystem ermöglicht. Der Mensch greift kaum noch in das Produktionssystem ein. Stattdessen wird ein Agent installiert, der dafür sorgt, dass die Single Source of Truth regelmäßig deployed wird.