GitOps: Die Power von Git in Ops

GitOps könnte für Entwickler und Einsatzteams endlich das sein, was DevOps schon so lange versprochen hat. [...]

Inzwischen haben Sie wahrscheinlich schon von GitOps gehört, und wenn dem so ist, fragen Sie sich vielleicht immer noch, was es bedeutet. Wahrscheinlich wird es nicht viel helfen, wenn ich Ihnen sage, dass GitOps nicht zwangsläufig auch Git beinhaltet, ebenso wenig wie Kubernetes, die Orchestrierungsmaschine, mit der es regelmäßig gepaart wird.

Sehr verwirrt? Dann versuchen Sie das hier: GitOps ist eine Möglichkeit, eine entwicklerzentrierte Erfahrung für die Verwaltung von Anwendungen zu schaffen, wie es das Unternehmen Weaveworks, das den Begriff „GitOps“ vornehmlich geprägt hat, ausdrücken würde. Um es noch deutlicher zu sagen: Es ist eine Möglichkeit, Entwicklern noch mehr Kontrolle über ihre eigene Arbeit zu verschaffen. Stellen Sie es sich als DevOps auf Steroiden vor, oder als DevOps, das zu seinem natürlichen Zweck eingesetzt wird.

Der Zweck? Entwickler in die Lage zu versetzen, eine viel größere Rolle im Betrieb ihrer Anwendungen zu übernehmen, und gleichzeitig auch das Leben von Ops-Profis deutlich zu verbessern.

Am Anfang war Git

Linus Torvalds ist wahrscheinlich am besten als der Schöpfer von Linux bekannt, aber Git, das dezentrale Versionskontrollsystem seiner Erfindung, ist sogar noch wichtiger.  Laut Torvalds hat „Git bewiesen, dass [er] mehr als nur ein One-Hit-Wonder sein kann“, aber das wäre eine extreme Untertreibung. Denn obwohl es vor Git bereits Versionskontrollsysteme gab (z.B. Subversion), hat Git seit seiner Einführung im Jahr 2005 die Art und Weise, wie Entwickler Software bauen, unweigerlich revolutioniert.

Heute ist Git ein „fast universeller“ Bestandteil der Software-Entwicklung, wie Studien des Analytikers Lawrence Hecht belegen. Inwiefern „fast universell“? Nun, Umfragen zum Stack Overflow beziffern den Anteil im Jahr 2018 auf 87 Prozent, während die Daten von JetBrains einen Sprung von 79 Prozent (2017) auf 90 Prozent (2019) bei seiner Einführung verzeichnen. Da so viel Code in öffentlichen und (noch mehr) privaten Git-Repositories gespeichert ist, befinden wir uns in einer fantastischen Position, um die Operationen um Git herum durchzuführen.

Um den CEO von Weaveworks, Alexis Richardson, zu zitieren: „Git ist die Power-Option, [und] wir würden es immer empfehlen, wenn wir könnten; aber es wäre falsch zu sagen, dass GitOps Expertise in Git erfordert. Die Verwendung von Git als UI ist nicht erforderlich. Git ist der Quell der Wahrheit, nicht die UI.“ Banken verfügen zum Beispiel über alte Repositorien, die in Subversion oder Mercurial gespeichert liegen. Können sie mit diesen Repositories GitOps durchführen? Ja. Tatsächlich wurden einige Elemente von GitOps bereits in den 2000er Jahren eingeführt.

Aber für die meisten Unternehmen ist die Abhängigkeit von Git das, was GitOps zu einem so faszinierenden Fortschritt bei DevOps und zu einer großen, kurzfristigen Chance macht.

9 dunkle Geheimnisse aus der Welt von DevOps

Ops in der Art von Kubernetes

Oh, und Kubernetes natürlich auch.  Warum Kubernetes? Obwohl verschiedene Container-Orchestrierungsmaschinen verwendet werden können, ist Kubernetes der Branchenstandard. Laut Weaveworks umfasst GitOps zwei Dinge:

• Ein Betriebsmodell für Kubernetes und cloud-nativ. Es bietet eine Reihe bewährter Verfahren zur Zusammenführung von Bereitstellung, Management und Überwachung für containerisierte Cluster und Anwendungen.
• Den Weg zu einer entwicklerzentrierten Erfahrung für die Verwaltung von Anwendungen.

Vielleicht brauchen Sie nicht für alles Kubernetes, aber viele Unternehmen verwenden es als einen wesentlichen Aspekt bei der Bereitstellung von Software. Und doch sind viel zu viele von ihnen blind auf ihren Kubernetes-Clustern unterwegs. Wie kann das sein? Laut Cornelia Davis, CTO bei Weaveworks, hatte die IT-Abteilung zwar verschiedene Tools zur Verfügung (z.B. Konfigurationsmanagement, Discovery usw.), um zu versuchen, das Geschehen innerhalb und zwischen den Systemen zu verfolgen, aber vieles war weitgehend unbekannt, weshalb sich das Patch-Management als so schwierig erwiesen hat.

„Der Umzug nach Kubernetes hat die IT nicht auf magische Weise weniger blind gemacht“, so Davis. „Sie trugen die Probleme, die sie bereits hatten, einfach nach Kubernetes weiter.“

Oder, wie Richardson es formulierte: „Woher wissen Sie, ob sich Kubernetes im korrekten Zustand befindet, wenn Sie es aktualisieren? Wird Ihnen gesagt, ob es im falschen Zustand ist? Die Antwort ist nein. [Die Entwickler] haben keine Ahnung. Sie fliegen blind.“ Daher sind die Benutzer von Kubernetes „festgefahren“, weil sie mit Clustern feststecken, die sie nicht aktualisieren wollen.

5 Möglichkeiten, mit Kubernetes serverlos zu arbeiten

Hier kommt GitOps ins Spiel.

Eine echte DevOps (GitOps!)-Erfahrung

Das GitOps-Modell heilt eine solche Kubernetes-Lähmung, ohne dass die Entwickler dafür Kubernetes-Gurus werden müssen. Dies geschieht durch den Einsatz automatisierter Direktoren, die Änderungen an einem Kubernetes-Cluster vornehmen, um es wieder in Einklang mit einem deklarativen Modell des gewünschten Zustands zu bringen, so Richardson:

Was wäre, wenn alles in dem Cluster über ein Modell aktualisiert würde? Wenn Sie einige Agents in Ihrem Cluster installieren, die den aktuellen Zustand überprüfen und ihn mit dem Modell vergleichen, können Sie dann Änderungen vornehmen, um die Übereinstimmung mit dem Modell zu erzwingen. Sie aktualisieren sie nicht direkt – Sie aktualisieren die Modelle. Auf dem Weg dorthin erhalten Sie eine kontinuierliche Integration, progressive Bereitstellung usw.

Weaveworks beschreibt dies ausführlicher, aber mir gefällt auch die Zusammenfassung des Redmonk-Analysten James Governor:

• Die Bereitstellung von AWS-Ressourcen und der Einsatz von Kubernetes ist deklarativ.
• Der gesamte Systemzustand steht unter Versionskontrolle und wird in einem einzigen Git-Repository beschrieben.
• Operative Änderungen werden per Pull-Anforderung (plus Build- und Release-Pipelines) vorgenommen.
• Diff-Tools erkennen jede Abweichung und benachrichtigen Sie über Slack-Alarme; und Sync-Tools ermöglichen die Konvergenz.
• Rollback- und Audit-Protokolle werden ebenfalls über Git bereitgestellt.

Dieser Ansatz klingt für Entwickler und die Anwendungsteams, die sie bedienen, großartig. Aber was ist mit dem Plattform-Engineering-Team, den Leuten, die wir oft als „Ops“ bezeichnen und die eine besondere Verantwortung für Sicherheit, Compliance, Kostenmanagement und mehr haben?

Für den Bereich Ops ist GitOps durch seine Wiederholbarkeit von großem Wert. Sie müssen eine Verfügbarkeitszone wiederherstellen? Das Plattform-Engineering-Team weiß, dass es, da alles modelliert ist, einfach die Reconciler laufen lassen kann, um die Dinge wieder in Einklang mit den Modellen zu bringen. In Verbindung mit der Fähigkeit von Git, umzukehren/zurückzufahren und zu gabeln, erhält das Operations-Team stabile und reproduzierbare Rollbacks, ganz zu schweigen von den Sicherheitsvorteilen von Git und mehr.

GitOps, kurz gesagt, könnte genau das sein, was DevOps schon lange angestrebt hat: eine großartige Möglichkeit für Entwickler, mehr von der operativen Last für ihre Anwendungen zu übernehmen, selbst wenn die Plattformtechnik (ops) ihre Aufgaben besser bewältigen kann.

*Matt Asay schreibt unter anderem für InfoWorld.com.