GitOps — Grundlagen

Einleitung

Dieser Artikel ist eine Einführung in GitOps und erklärt die Hauptkomponenten von GitOps im Vergleich zum traditionellen Continuous Integration/Continuous Deployment (CI/CD)-Ansatz.

Für die zukünftigen Beispiele wird Kubernetes als Orchestrierungsplattform dienen, während Argo CD oder Flux als GitOps-Operatoren eingesetzt werden.

CICD vs GitOps

 

Der CI/CD-Ansatz

Wir konzentrieren uns auf den Continuous-Deployment-Ansatz und nicht auf Continuous Delivery, um die Unterschiede auf ein Minimum zu beschränken. Es gibt viele Erklärungen zu CI/CD, auf die ich hier nicht näher eingehen werde.

 

Das Diagramm zeigt den Workflow von CI/CD in vereinfachter Form.

Der CI-Teil läuft wie folgt ab: Ein Entwickler committet und pusht eine Änderung im Quellcode. Anschließend werden erfolgreiche Unit-Tests ausgeführt, die neue Änderung wird in die Anwendung integriert, und ein Release wird als Docker-Container erstellt.

Der CD-Teil erstellt eine Deployment und bringt es auf das Zielsystem.

 

Herausforderungen mit CI/CD

Wenn es bei einer Ihrer Anwendungen ein Problem mit großer Auswirkung gibt, möchten Sie möglicherweise manuell eingreifen und notwendige Änderungen vornehmen. Diese Änderungen müssen jedoch in das nächste Release integriert werden, um das Problem tatsächlich zu lösen.

Bei längeren Release-Zyklen entstehen durch manuelle Änderungen mehr Abweichungen, was zu Diskrepanzen zwischen dem Zustand in Ihrem Versionskontrollsystem und dem Zustand auf den Produktionsservern führen kann. Selbst bei regelmäßigen Deployments können manuelle Eingriffe unerwartete Abweichungen verursachen.

Darüber hinaus haben die meisten Unternehmen feste Spezifikationen dafür, wann Änderungen in ein Produktivsystem eingebracht werden dürfen (z. B. QA, Sprints, Deployment-Fenster usw.).

In solchen Fällen kann GitOps eine gute Lösung bieten, um den tatsächlich laufenden Zustand eng an den im Versionskontrollsystem erfassten Zustand anzupassen, indem regelmäßig Deployments durchgeführt werden.

 

Der GitOps-Ansatz

Das folgende Diagramm zeigt den Unterschied zum CI/CD-Ansatz. Beachten Sie den Unterschied darin, wie das neue Release in das Zielsystem gebracht wird. GitOps verwendet einen Synchronisierungsmechanismus über einen Agenten oder Operator und überwacht den Status im Git-Repository in bestimmten Zeitintervallen.

Wenn eine neue Version (Commit) verfügbar ist oder eine Abweichung zwischen dem ausgerollten Zustand und dem Zustand im Repository festgestellt wird, wird der Agent je nach Konfiguration aktiv und synchronisiert den Zustand im Zielsystem.

 

 

GitOps basiert auf diesen Schlüsselfunktionen:

• • Deklarativ: Alle Systemkomponenten (Infrastruktur und Anwendungen) werden deklarativ beschrieben.

• • Versioniert und Unveränderlich: Der gewünschte Systemzustand wird in einem versionierten Git-Repository gespeichert.

• • Automatisch Abgerufen: Genehmigte Änderungen werden automatisiert und auf das System angewendet.

• • Kontinuierliche Rekonfiguration/Synchronisierung: Agenten/Operatoren werden verwendet, um die Korrektheit sicherzustellen und auf jede Abweichung vom gewünschten Zustand aufmerksam zu machen.

 

Erklär es mir, als wäre ich 5 Jahre alt

| HINWEIS: Der GitOps-Ansatz geht davon aus, dass alles, einschließlich geheimer Daten (Secrets), im Repository gespeichert ist.

Wenn man die 4 Punkte auf die Analogie anwendet, dann werden sowohl die Infrastruktur (Schloss) als auch die Anwendungen (Eimergröße) deklarativ beschrieben. Die Eimer sind durch ihre Versionen (Größe) zuweisbar, sind unveränderlich durch ihre feste Form und im Git-Repository (Sandkasten) gespeichert. Änderungen werden automatisch erkannt, abgerufen und vom Kind genehmigt, sobald genügend Platz im Sandkasten vorhanden ist. Danach wird die kontinuierliche Rekonfiguration durch das Kind erfüllt.

 

Jetzt schauen wir uns an, wie GitOps mit zwei einfachen Anwendungsfällen basierend auf der Analogie funktioniert.

 

Anwendungsfall: Änderungsanforderung, die bereitgestellt werden soll

 

 

Anwendungsfall: Infrastrukturabweichung durch eine manuelle Änderung

 

 

Fazit

Man kann erkennen, dass der GitOps-Ansatz eine nahezu unveränderliche Infrastruktur ermöglicht und somit die Abweichung zwischen dem gewünschten Zustand und dem ausgerollten Zustand im Zielsystem so klein wie möglich hält. Ein Software-Agent erkennt Änderungen, die ins Repository gepusht werden, und ist so konfiguriert, dass diese Änderungen automatisch angewendet werden, um sicherzustellen, dass der Systemzustand dem versionierten gewünschten Zustand entspricht. Für Kubernetes wird der GitOps-Agent im Cluster bereitgestellt und überwacht ein oder mehrere Git-Repositories mit Kubernetes-Manifests (oder Helm-Charts/Kustomize-Dateien). Um das System zu aktualisieren, werden alle Änderungen über Git-Operationen und niemals direkt über manuelle Befehle vorgenommen — Entwickler, Betreiber und andere Beteiligte arbeiten alle über denselben Kanal.

Im nächsten Artikel werde ich Anwendungsfälle für GitOps beschreiben, die Vor- und Nachteile erläutern, die GitOps-Pattern mit Git vorstellen und mehr.

 

Kontaktinformationen

Wenn du mehr über GitOps erfahren möchtest dann kontaktiere uns hier oder füge mich einfach in dein LinkedIn-Netzwerk hinzu!

 

Referenzen

 

• • Argo CD — https://argo-cd.readthedocs.io/en/stable/
  • Flux — https://fluxcd.io
  • GitOps Approach — https://www.weave.works/technologies/gitops/