⇒ In der DOAG gibt es seit kurzem eine Cloud Native Community. Diese beschäftigt sich nativ mit Cloud-Themen. Eins davon ist "GitOps". In Teil 2 von 3 standen GitOps & Kubernetes, Infrastructure-as-Code und klassische Betriebsmodelle im Blickpunkt. In Teil 3 kommt der Autor abschließend auf die Benefits von GitOps sowie Anwendungsbeispiele zu sprechen und zieht darüber hinaus ein Fazit.
--
Einleitung: Dieser mehrteilige Beitrag soll einen Eindruck zu GitOps vermitteln – wo es herkommt, wo es hingeht und was auf dem Weg liegt. Eins vorweg: "Die Cloud", respektive Kubernetes, verzeichnet zwar das erste Auftreten von GitOps, jedoch sind seine Prinzipien und die Einsatzmöglichkeiten universell; sie können – und sollen – damit natürlich nach Möglichkeit überall angewandt werden.
Außerdem sollte GitOps nicht isoliert betrachtet werden. Vielmehr verändern seine Prinzipien die Art und Weise, wie wir professionelle IT betreiben. Es ist das Puzzlestück, das viele 'gehypte' Themen der letzten Jahre erst sinnvoll ermöglicht: autarke Teams, echtes DevOps, ganzheitliches (Software) Engineering inklusive Betrieb aus einer Hand. Nette Nebeneffekte, die sich einstellen, wenn man GitOps lebt, sind bessere Nachhaltigkeit bei der Arbeit durch die Vermeidung manueller Tätigkeiten und höhere Qualität unserer Systeme.
--
Benefits von GitOps
Natürlich lautet die Lösung für alle diese "Herausforderungen": GitOps. Mein eigenes Team ist zu GitOps gekommen, als wir uns mit einem Team aus drei Entwicklern ohne Infrastruktur-Erfahrung entschlossen hatten, unser Schicksal selbst in die Hand zu nehmen; also autark, auf Basis einer Public Cloud unser Produkt eigenständig aufzubauen und zu betreiben. Spoiler: Wir waren erfolgreich. Das hätte niemals funktioniert, wenn wir uns mit manuellen Prozessen, dem Bauen von Deployment-Pipelines oder zig verschiedenen Tools oder Methodiken hätten beschäftigen müssen.
Aber den Betrieb unseres Systems mittels Pull-Request zu koordinieren, Infrastruktur-Deklarationen verschiedener Zeitpunkte zu vergleichen und zu jedem Stand springen zu können, war genau unser Ding. Eine neue Umgebung aufzubauen, kein Problem, geht ja vollautomatisch. Ein Experiment hat die Umgebung wieder mal zerstört? Auch kein Problem, löschen und kurz warten, kommt von allein wieder.
Warum weicht die Konfiguration vom Standardwert ab? Steht in der Git-Historie. Dadurch, dass restlos alles, was das System ausmacht, im Git zu finden ist, braucht man keine zusätzliche Dokumentation, sofern zumindest ein bisschen sinnvoll kommentiert wird und die Commit-Nachrichten nicht aus Binsenweisheiten bestehen. Manuelle Eingriffe sind absolut verboten, dadurch ist man gezwungen, alles zu automatisieren. Dadurch, dass alles automatisch passiert, wird alles, was möglich ist, auch automatisch geprüft, denn auch Tests will man nicht mehr manuell durchführen. Da die umständliche Arbeit von Software-Agenten durchgeführt wird, kümmern wir uns auch gar nicht mehr groß ums Deployment. Wir beschreiben, was bereitgestellt werden soll. Wie dieser Zustand erreicht wird, überlassen wir den GitOps-Operatoren.
Man sagt, man könne Feuer, fließendes Wasser und Downloadbalken beliebig lange beobachten. Anfangs ist es auch superspannend, das GitOps-System bei seiner Arbeit zu bewundern, relativ schnell wird das allerdings so selbstverständlich, dass man sich gar nicht mehr drum kümmert. Sollte es doch mal ein Problem geben, wird man vom Monitoring benachrichtigt, dessen Regeln auch vollständig deklarativ beschrieben sind. Betrieb, der funktioniert, wie er soll, und einfach nur Spaß macht, weil es sowohl Experten als auch eine große Community gibt, die sich um die Software-Agenten kümmern. So können wir uns auf unsere eigenen Kernkompetenzen konzentrieren: Fachanwendungen auf Infrastruktur bauen, die perfekt zu den Anforderungen passt.
Anwendungsbereiche
Für einen typischen Kubernetes-Stack ist GitOps wie gemacht. Es existiert zahlloses Tooling und die deklarative Natur von Kubernetes selbst könnte nicht besser dazu passen. Auch übliche Infrastrukturprobleme lassen sich mit GitOps meist gut lösen, gegebenenfalls bedarf es aber etwas Kreativität, um die existierenden Werkzeuge GitOps-konform einzusetzen. Warum will man das haben? Um ohne Ausnahme alles, was ein System ausmacht, in Git zu haben, lückenlos versioniert und damit intrinsisch dokumentiert.
Und weil wir das für unsere Infrastruktur und unsere Fachanwendungen so machen, wollen wir es überall so machen, selbst wenn es erst mal unnatürlich erscheint oder die GitOps-Prinzipien nicht vollständig eingehalten werden können. Dokumentation ist ein Beispiel, das jeder versteht. Diese kann man in einer Text-Verarbeitung schreiben oder mit dem gleichen Aufwand, aber allen genannten Vorteilen als Plain-Text in Markdown oder AsciiDoc. Damit kann der tatsächliche Code referenziert werden, Aktualisierungen machen wir ganz komfortabel zusammen mit den Code-Änderungen, so wird die Dokumentation niemals veralten und kann sogar automatisch geprüft werden.
Diagramme als Code sind auch nichts Neues, die ganze Dokumentation kann bei Änderung direkt von einem Build gerendert und veröffentlicht werden. Es braucht keine weiteren Tools und kann vollständig automatisiert werden. Letztendlich passt alles, das deklarativ "als Code" ausgedrückt werden kann, in unser GitOps-Weltbild. Und nach kurzer Zeit will man überhaupt gar nicht mehr anders arbeiten.
Fazit
Alles in allem dürfte folgende Aussage jetzt nachvollziehbar geworden sein: Wenn wir versuchen, mit all unserem Schaffen den GitOps-Prinzipien gerecht zu werden, maximiert sich unser Qualitätsanspruch und wir liefern bestmögliche Ergebnisse – wir werden somit bessere Engineers. Qualität heißt nicht, fehlerlose Lösungen zu bauen, das ist zwar ein hehres Ziel, doch letztendlich unmöglich. Qualität bedeutet, für eine gewisse Problemstellung die am besten passende Lösung bereitzustellen, und das Ganze möglichst ressourceneffizient.
Allein dadurch, dass es so gut wie keine manuellen Tätigkeiten am Zielsystem mehr gibt, wird eine große Fehlerquelle und auch ein Effizienzkiller ausgemerzt. Dadurch, dass wir keine Delivery Pipelines mehr selbst bauen, sondern uns auf etablierte Werkzeuge verlassen, haben wir weniger Tätigkeiten, die nichts mit unserem Kerngeschäft zu tun haben. Um zur bestmöglichen Lösung zu kommen, müssen oft Dinge ausprobiert werden. Das ist in einem sauberen GitOps Setup einfach und gefahrlos möglich. Jede Änderung kann schnell rückgängig gemacht werden und wenn etwas wirklich nachhaltig kaputt geht, können wir das ganze System einfach in der letzten stabilen Version automatisch neu aufbauen lassen.
Damit wir nichts manuell tun müssen, wird alles automatisiert, unser gesamtes System wird dadurch viel stabiler. Natürlich kann das auch auf anderen Wegen erreicht werden, ein vollständig deklarativer Ansatz zwingt uns allerdings dazu. Und weil niemals etwas "grad mal schnell" von Hand gemacht werden kann, ohne gegen die vier Prinzipien zu verstoßen, sind wir viel professioneller unterwegs. Meist ist man mit der sauberen Variante nicht viel langsamer gegenüber einer augenscheinlich schnelleren manuellen Anpassung, aber es bedarf keiner Nacharbeiten mehr. Und das wiederum führt zu mehr Spaß an der Arbeit, mehr Spaß bedeutet bessere Arbeit, bessere Arbeit schafft bessere Lösungen.
⇒ Florian Heubeck ist DOAG Themenverantwortlicher Cloud Native Git Ops.
--
Bild: Gerd Altmann auf Pixabay
