Versionierung und Agenten: Vor- und Nachteile von GitOps

Inhaltsverzeichnis

Autopiloten im Straßenverkehr lassen sich grob in assistiertes, automatisiertes und autonomes Fahren gliedern. Übertragen auf Entwicklungsprozesse entspricht DevOps dem assistierten bis automatisierten Level, während GitOps in die Bereiche Automatisiertes bis Autonomes vorstößt.

Mit Assistenzsystemen und Automatisierungen können ITler gut umgehen, schließlich liegt es in ihrer Natur, Arbeit zu automatisieren. Autonomie ist hingegen in der IT ungewohnt. Es bedeutet, die Kontrolle an ein System abzugeben, das selbstständig bewertet, entscheidet und eingreift. Möglich ist das nur, weil GitOps dafür klare Prinzipien aufstellt, die es genauestens zu befolgen gilt. Entwicklungs- und Plattformteams profitieren von optimierten Entwicklungsprozessen, durchgehender Transparenz und uneingeschränkter Wiederholbarkeit.

Prinzipien von GitOps

Vier Prinzipien liegen GitOps zugrunde: Deklarieren, Versionieren, Automatisieren und Kontrollieren. Im Zusammenspiel schaffen sie die enormen Vorteile von GitOps im Vergleich zu den bisherigen Ansätzen. Wie so oft in der IT bedeutet dies allerdings auch, Kompromisse eingehen und Zugeständnisse machen zu müssen.

Deklarieren: GitOps wechselt von einem IT-typisch imperativen auf einen deklarativen Ansatz. Die Entwicklerinnen und Entwickler legen also nicht mehr Schritt für Schritt fest, wie der Zielzustand zu erreichen ist, etwa durch Befehlsfolgen (imperativ). Stattdessen beschreiben sie lediglich, welcher Zustand und welches Ziel gewünscht sind. Sie deklarieren, was sie erreichen wollen.

Versionieren: Diesen einmal deklarierten Zielzustand halten die Entwickler unveränderbar fest. Jede Änderung der festgehaltenen Deklaration führt zu einer komplett neuen Version und das bei einer vollständig nachvollziehbaren Historie. Das ist im Grunde mit jedem Versionskontrollsystem möglich, wobei auf Git basierende schon aufgrund der Namensgebung naheliegend sind.

Automatisieren: Softwareagenten lesen den in Git deklarierten Zielzustand automatisch aus. Wann die Automatisierung greift, lässt sich frei festlegen, etwa mit jedem Commit, mit jedem Merge, mit einem neuen Release, bei bestimmten Tags oder anderen Ereignissen. Entscheidend ist, dass die Agents automatisch agieren, um den deklarierten Zielzustand herzustellen. Sie treten damit in Aufgaben ein, die zuvor die Entwicklungs- und Plattformteams selbst leisten mussten.

Kontrollieren: Während des Betriebs vergleichen die Agents permanent den aktuellen Zustand der Systeme mit dem in Git deklarierten. Stellen sie dabei einen Unterschied fest, ermitteln sie, wie sie ihn ausgleichen und den deklarierten Zielzustand wiederherstellen können. Die notwendigen Korrekturen nehmen sie dann ebenfalls selbstständig vor.

Vorteile von GitOps

Entwicklungsteams sind diejenigen, die von GitOps am meisten profitieren, denn für sie entfallen viele bislang manuelle oder eher umständliche Tätigkeiten.

Optimierter Entwicklungsprozess: GitOps optimiert den Bereitstellungsprozess, indem es ihn deklarativ gestaltet. Entwicklerinnen und Entwickler definieren den gewünschten Zustand der Anwendung als Konfiguration im Textformat und legen diese in einem eigenen Repository ab. In Konsequenz sind das Repository für das auszuliefernde Artefakt, etwa ein Monolith oder ein Microservice, und das Repository für dessen Betriebskonfiguration sauber separiert.

Plattformteams können durch GitOps eine Entwicklungsplattform nach dem Selbstbedienungsprinzip aufbauen. Grafische Bedienoberflächen, die mitunter komplex oder wenig intuitiv sind, entfallen dabei. Anstatt also bestimmte Dienste und Konfigurationen dieser Dienste über ein GUI vorzunehmen, erfolgt deren Auswahl und Konfiguration über deklarative Textdateien. Somit müssen weder GUIs detailliert entwickelt, aufwendig gepflegt noch langwierig umständlich bedient werden.

Das Entwicklungsteam erhält wiederum direkten, aber geschützten Zugang zur Betriebsumgebung. Das Plattformteam entscheidet dabei, welche Konfigurationsmöglichkeiten es dem Entwicklungsteam bereitstellen will. Dabei kann letzteres nicht direkt in die Betriebsumgebung eingreifen, diese aber deutlich besser an den Entwicklungsstand der Anwendung anpassen.

Eine manuelle oder gar mündliche Übergabe an das Plattformteam entfällt, Missverständnisse und daraus resultierende Fehler können nicht entstehen. Das vereinfacht nicht nur die Bereitstellung, sondern ermöglicht auch schnelle Rollbacks von Änderungen. Dieser hohe Grad der Automatisierung und Autonomie senkt wiederum die Kosten. Zum einen entfallen manuelle Routinetätigkeiten, was Personalressourcen freigibt, zum anderen verringert GitOps viele Risikofaktoren.

Ein weiterer Vorteil für Plattformteams ist, dass sie Generatoren, Reporting-Tools und andere Werkzeuge einsetzen können, um zusätzliche Dienstleistungen bereitzustellen oder Informationen zu aggregieren. Sie sind somit nicht mehr auf die Tools beschränkt, die die Hersteller mitgeben. Übergreifend aggregierte Daten erlauben zusätzliche Schlussfolgerungen.

Nachvollziehbare Historie: Versionskontrollsysteme bieten eine durchgängige Nachvollziehbarkeit: Alle Änderungen an den Dateien eines Repositories sind dauerhaft dokumentiert, und es existiert eine nahtlose Historie aller Betriebshandlungen mit Urheber, Zeitpunkt, Änderung und Begründung, sofern die Anwender sinnvolle Commit-Kommentare eingetragen haben.

Diese Historie erlaubt nicht nur nachzuvollziehen, wie sich eine Anwendung im Laufe der Zeit entwickelt hat, sondern auch, warum es zu bestimmten Betriebssituationen gekommen ist. Lief eine Bereitstellung nicht fehlerfrei ab, lässt sich der Grund dafür klar erkennen – und das nicht durch langwierige Auswertung mehrerer, verteilter Log-Dateien. Ein Blick in die Commits reicht.

Ist der Commit erkannt, der den Fehler ausgelöst hat, können ihn sowohl das Plattform- als auch das Entwicklerteam zurücknehmen und so einen funktionierenden Betriebszustand wiederherstellen. Bei grafischen Bedienoberflächen ist das nur möglich, wenn ein Rücksprung in der Änderungshistorie vorgesehen und programmatisch umgesetzt ist.

Transparente Zusammenarbeit: GitOps fördert die Zusammenarbeit zwischen verschiedenen Entwicklungs- und Plattformteams und erhöht nochmals die Transparenz. Entwicklerinnen und Entwickler können Code und Änderungen mit allen anderen teilen und einsehen, bewerten, kommentieren und diskutieren.

Auf Basis dieser Zusammenarbeit lassen sich Änderungen freigeben, zusammenfassen und anwenden. Die Wissenssilos zwischen verschiedenen Teams entfallen zwar nicht vollständig, werden aber kleiner und wirken sich weniger gravierend aus. Halten sich zudem alle Beteiligten an eine wertschätzende Kommunikationskultur, lassen sich die Diskussionen und Kommentare auch als Wissensbasis für neue Teammitglieder nutzen.

Kontinuierliche Bereitstellung: Continuous Integration (CI) und Continuous Delivery (CD) sind Maßnahmen der Automatisierung und Kernbestandteil von DevOps. GitOps führt diese Automatisierung weiter und autonomisiert sie größtenteils, da die Teams nicht mehr die Schritte imperativ vorgeben. Das liegt im Wechsel zum deklarativen Ansatz begründet. Entwicklerteams genießen den Vorteil, dass sie nur noch deklarieren, wie die Betriebsumgebung aufgebaut sein soll. Der imperative Ansatz bedeutete in der Regel hingegen, dass stets ein vollständiger und gegebenenfalls langwieriger Build- und Deployment-Prozess erforderlich ist. Denn jede Maßnahme, um den Betriebszustand zu erreichen, wird Schritt für Schritt bis zum Erfolg oder frühzeitigen Scheitern abgearbeitet. Kommt es bei einem der Schritte zu einem Fehler, muss das Team den Fehler finden, verstehen und korrigieren – und dann den gesamten Prozess von vorn starten. Von solchen Problemen ist das Entwicklungsteam mit GitOps entlastet.

Plattformteams profitieren wiederum davon, dass sie weniger eingreifen müssen. Denn der Agent schaltet sich ein, wenn eine Komponente ausfällt, wenn es eine neue Version von dieser gibt oder wenn die Entwickler einen anderen Betriebszustand wünschen. Die Agenten identifizieren die Diskrepanzen automatisch und korrigieren sie, im Idealfall minimalinvasiv und mit geringster Verzögerung.

Uneingeschränkte Wiederholbarkeit: Mit der zentralen Ablage der Konfigurationsdateien in einem Repository ist es nun auch möglich, vorherigen Betriebszustände jederzeit wiederherzustellen. Änderungen lassen sich vollständig zurückrollen, falls Probleme oder Fehler auftauchen. Entwicklungsteams genießen den Vorzug, einen Betriebszustand beliebig oft in derselben oder auch unterschiedlichen Varianten bereitstellen zu können – eine klare Commit-Strategie vorausgesetzt. Den Teams sollte also ein ordentliches Branching-, Tag- oder Versionskonzept vorliegen, das sie auch einsetzen müssen. Die Konfigurationen lassen sich dann wiederum für unterschiedliche Betriebsumgebungen wie Test und Produktiv definieren.