Code-gesteuerte Anwendungsumgebung über Git Wie funktioniert GitOps in der Praxis?

Wenn GitOps eines ist, dann aktuell ein großes Thema. Überall sprießen Artikel, Services und Produkte aus dem Boden, die sich mit GitOps schmücken. Aber um herauszufinden, was GitOps denn nun genau ist, was da passiert und wo es her kommt, braucht es bisweilen eine Ewigkeit.

Einmal angenommen, Sie sollen oder wollen sich in das Thema GitOps einarbeiten. Der Grund dafür liegt vermutlich darin, dass Ihnen selbst das Schlagwort alle zwei Tage irgendwo begegnet oder es jemand weiter oben im Management aufgeschnappt hat.

Sie werden GitOps-Beiträge wie hier auf Dev-Insider finden, die die Vorteile ausarbeiten, die Revolution der Software-Entwicklung und -Bereitstellung prophezeien oder auf spannende Services hinarbeiten, die Sie erwerben dürfen. Das Ganze ist gerne gespickt mit wahlweise Dutzenden Fachbegriffen und Tools aus der Developer-Schiene, die höchstens versteht, wer seit 20 Jahren in dieser einen Nische tätig ist.

E-Book zum Thema

Unser eBook „Ein kleiner GitOps-Guide“ befasst sich mit den Grundprinzipien von GitOps und zeigt einige Tools und Best Practices für die GitOps-Pipeline auf.

eBook herunterladen

Mitunter hagelt es aber auch fantasievolle Begrifflichkeiten aus der Management-Welt, bei der Entwickler schnell an ein gewisses Bingo-Spiel denken. Mit anderen Worten: Es ist ein typisches Hype-Thema irgendwo an der Schnittstelle IT-Management und Software-Entwicklung – ein Ort, an dem sich bekanntlich mit warmen, aber kaum verständlichen Worten wertschöpfen lässt.

Hintergründe zur GitOps-Vorgehensweise

GitOps ist aber viel mehr: nämlich ein tolles Konzept! Und das liefert im Grunde auch schon den ersten Baustein zum Verständnis: Es ist weder ein Service noch ein Produkt, sondern lediglich ein Konzept der Firma Weaveworks. Genauer gesagt ist es eine Bezeichnung für die eigene Arbeitsweise, ins Licht der Welt getreten durch einen kurzen Blog-Beitrag zu GitOps. Und freilich bietet Weaveworks eigene Produkte und Services rund um diese GitOps genannte Vorgehensweise an.

Klar dürfte sein, dass Git etwas damit zu tun hat. Das Ops steht einmal mehr für Operations und gemeint ist hier der Bereich CI/CD, also Continuous Integration, Continuous Delivery, Continuous Deployment. Fall Sie bislang darum herumgekommen sind: Im Grunde meint CI nichts weiter, als dass Code-Änderungen aller Beteiligten kontinuierlich zusammengeführt und automatisiert getestet werden – was die Arbeit der Entwickler vereinfacht.

Am Ende der CI steht zusammengeführter Code. Continuous Delivery wiederum nimmt diesen rohen Code und stellt ihn, nach weiteren Tests, als produktionsreife Code-Basis in einem Repository bereit. Die Phase Continuous Deployment überführt diese Code-Basis – natürlich wieder erst nach automatisierten Tests – letztlich in eine produktiv nutzbare Anwendung.

Ein kurzes Beispiel für Continuous-Praktiken

Ein übersimplifiziertes Beispiel dazu: Alice und Bob entwickelt gemeinsam eine Website auf GitHub, die schlicht eine Tabelle mit Sportergebnissen anzeigt. Jedes neue Ergebnis wird umgehend in einen Branch „entwicklung“ gepusht. Ein simples Testwerkzeug prüft, ob die Tabellenzeile leer ist – falls nicht, wird zusammengeführt (merge) – der CI-Part.

Ein weiteres Testwerkzeug prüft die HTML-Syntax und wenn diese okay ist, wird der aktuelle Stand in den Branch „master“ übergeben – der Continuous-Delivery-Teil. Letztlich könnte nun ein Testwerkzeug zum Beispiel die Performance des Website-Codes prüfen und bei Bestehen automatisch auf einen Webserver kopieren – das Continuous Deployment.

GitOps macht nun Git zum Zentrum dieses ganzen Prozesses – und zwar für die Entwicklung von Cloud-Native-Anwendungen. Und das heißt heute generell und hier speziell vor allem Kubernetes. Ein damit orchestriertes Docker-Cluster liefert die nötige Infrastruktur, um Anwendungen bereitzustellen und auch kontinuierlich aktualisieren zu können.

Das Schöne an Kubernetes: Es funktioniert komplett deklarativ. Natürlich können Sie Cluster und Anwendungen über das Standard-Tool kubectl verwalten. Aber es funktioniert eben auch über YAML-Dateien, die schlicht und einfach den gewünschten Zustand von Cluster und laufender Software definieren. Und hier genau setzt nun GitOps an.

Was passiert bei GitOps?

Der Grundgedanke von GitOps ist, dass ein einzelnes Git-Repository der Anlaufpunkt für Entwicklung und CI/CD ist, die Single Source of Truth, wie man so schön sagt. Ein Entwickler kann eben nicht nur seinen Code ins Repository pushen, sondern auch YAML-Dateien, die deklarieren, wie genau die Anwendung laufen soll, sprich wie das Cluster aufgebaut ist, welche Ressourcen die App bekommt, wie sie erreichbar ist und so weiter.

Der Urbeitrag von Weaveworks hat den Titel „GitOps – Operations by Pull Request“. Und genau das ist der Punkt: Wenn beispielsweise das Operations-Team einem Kunden eine Version für einen Betatest bereitstellen oder eine App in einem leistungsfähigeren Cluster testen will, kann das schlicht über einen Pull Request laufen, über den die Konfiguration (die YAML-Datei) geändert wird. Jegliche Änderungen, nicht bloß am Code, laufen über die eine Git-Repo.

Im laufenden Betrieb sind es vor allem Diff-Tools, die GitOps den besonderen Nutzen stiften sollen. Durch den deklarativen Charakter von Kubernetes können einfache Diff-Werkzeuge stets den per YAML-Konfiguration gewünschten Zustand mit dem Ist-Zustand von Clustern und Anwendungen abgleichen und bei Bedarf Alarmierungen ausgeben. Über Synchronisierungs-Tools kann dann entsprechend in die eine oder andere Richtung korrigiert werden.

Nochmal zum obigen Alice-und-Bob-Beispiel: Beim letzten Punkt Continuous Deployment soll Code auf den Webserver kopiert werden. Soll nun dort zum Beispiel eine andere Server-Version laufen oder mehr Arbeitsspeicher genutzt werden, müsste traditionell ein Mitarbeiter den Server anhalten, aktualisieren, Software einspielen und wieder starten.

In einem via Textdateien deklarierten Cluster genügt es, Kubernetes mitzuteilen, welchen Zustand man wünscht – die Konvergenz läuft dann Kubernetes-intern ab, im laufenden Betrieb. Und wenn eben diese Änderung der Konfiguration in einem Git-Repo stattfindet, ist es schon die Grundform von GitOps.

Ein kleiner Link fehlt noch: Die gepushten Änderungen müssen natürlich auch tatsächlich kontinuierlich ausgelesen und von Kubernetes umgesetzt werden. Und da beginnt dann letztlich das Geschäft mit entsprechenden Tools. Eine recht simple Form kommt als Open Source Software von Weaveworks selbst: Flux synchronisiert, standardmäßig im 5-Minuten-Takt, den im Repo definierten/gewünschten Zustand mit dem Ist-Zustand des laufenden Clusters (sorgt also dafür, Images und Konfiguration aus dem Repo ins Cluster gespielt werden).

Warum GitOps?

Änderungen im laufenden Betrieb über deklarative Konfiguration? Das ist ein Pluspunkt, den Kubernetes mit sich bringt. Dafür braucht es nicht unbedingt Git. Automatisches Testen und Bereitstellen von gepushtem Code? Auch das geht schon lange über traditionelles Scripting.

Die Konfiguration und die Automatisierung neben dem eigentlichen Code mit in ein Git-Repo zu übernehmen, bringt aber einige ganz klare Vorteile: Entwickler können bei ihrem geliebten Git bleiben und müssen sich nicht mit Skripten oder kubectl herumschlagen – quasi ein softer Aspekt. Auf der harten Seite: Alles in Git ist für immer nachvollziehbar – und damit ist so ein System auch gut auditierbar! Jede Änderung lässt sich zudem jederzeit wieder rückgängig machen, jeder Zustand lässt sich wiederherstellen.

Man könnte durchaus sagen, dass GitOps einfach nur meint, dass alle Eigenschaften und Prozesse, die rund um die Entwicklung und Bereitstellung von Anwendungen anfallen, über Dateien in einem Git-Repo verwaltet werden – wodurch sie nachvollziehbar, wiederherstellbar und eindeutig sind.

Vielleicht denken Sie sich nun: Das machen wir doch im Grunde sowieso schon so ähnlich – was soll der Hype? Und ja: Ein Großteil all dieser, vereinfacht dargestellten, Konzepte ist nichts weiter als Best Practices aus ungefähr der letzten Dekade – sagt Weaveworks selbst im Original-Post: „[…] GitOps, which is 90% best practices and 10% cool new stuff [...].“

Zusammenfassung

Wie so oft bei Hype-Themen im IT-Bereich wurde mit GitOps also vor allem ein Name für etwas gefunden, was man eh schon längst tut, oder tun sollte. Im Kurzabriss meint GitOps alo, ein Git-Repository nicht nur mit Code, sondern auch mit den für den Bereich Operations (Konfiguration) benötigten Daten zu füttern und jegliche Automatisierung aus dieser einen Repo zu speisen.

Weaveworks hat den Grundgedanken schön formuliert: „[…] config is code, and code should be stored in version control.” Das Universum an Tools, Best Practices und Standards rund um das Thema GitOps wächst stetig und ist weit komplexer als das grundlegende Konzept. Und es ist nicht ganz unwahrscheinlich, dass Sie bereits einen Großteil Ihrer Arbeit in GitOps-Manier erledigen, ohne es je so genannt zu haben.

Git als das alleinige technische Zentrum eines kompletten Geschäftsbetriebs von der Entwicklung über das Testing bis zur Auslieferung ist jedenfalls äußerst charmant. Entwickler dürften es lieben. Wer GitOps mal schnell und einfach in der Praxis erleben möchte, darf auf unseren Artikel zu Argo CD gespannt sein – eine simple und doch mächtige Umsetzung der GitOps-Basis.

E-Book zum Thema

Ein kleiner GitOps-Guide

GitOps soll die Cloud-native Entwicklung containerisierter Anwendungen von Grund auf umkrempeln. Unser eBook „Ein kleiner GitOps-Guide“ befasst sich mit den Grundprinzipien von GitOps und zeigt einige Tools und Best Practices für die GitOps-Pipeline auf.

Im eBook erfahren Sie mehr über:

• GitOps-Prinzipien, Vorteile und Alternativen
• Tooling für GitOps
• Troubleshooting von GitOps-Pipelines

eBook „Ein kleiner GitOps-Guide“ herunterladen

(ID:46555986)