GitOps ist ein Betriebsmodell, bei dem der gewünschte Zustand verwalteter Ressourcen versioniert festgehalten wird, häufig in einem Git-Repository. Agenten beobachten diese Ressourcen, vergleichen Soll und Ist und versuchen, den beschriebenen Zustand anzuwenden [1].
Der Vergleich, der trägt, ist der Bestellzettel im Lager. Auf dem Zettel steht, was in den Regalen liegen soll. Der Lagerist geht nicht nach Zuruf durch die Gänge, sondern gleicht die Regale gegen den Zettel ab. Wer etwas ändern will, ändert den Zettel, nicht das Regal.
Dieser Artikel erklärt das Modell, seine vier Prinzipien und die Grenzen, an denen es in der Praxis anstößt. Produktnamen kommen erst im vorletzten Abschnitt vor.
Die vier Prinzipien
Die OpenGitOps-Arbeitsgruppe der CNCF hat das Modell auf vier Prinzipien festgelegt [1]:
- Deklarativ. Der gewünschte Zustand ist als Beschreibung ausgedrückt, nicht als Befehlsfolge.
- Versioniert und unveränderlich. Sollzustände werden unveränderlich versioniert und ihre Historie aufbewahrt. Dafür müssen Ablage und Zugriffsregeln passend eingerichtet sein.
- Automatisch gezogen. Die Umgebung holt sich Änderungen selbst ab, statt dass jemand sie hineinschiebt.
- Laufend abgeglichen. Agenten beobachten den Istzustand laufend und versuchen, den Sollzustand anzuwenden.
Was das mit Infrastructure as Code zu tun hat
GitOps baut auf Infrastructure as Code und deklarativer Konfiguration auf. Zum versionierten Sollzustand kommen Agenten hinzu, die ihn automatisch abrufen und laufend mit den verwalteten Ressourcen abgleichen.
Der Unterschied zeigt sich im Alltag. Bei IaC allein stößt oft eine Person oder Pipeline den Lauf an. Im GitOps-Modell übernehmen Agenten den laufenden Abgleich. Direkte Änderungen bleiben technisch möglich; ihre Erkennung und Korrektur hängen vom verwalteten Umfang und den Einstellungen des Werkzeugs ab.
Push und Pull: wer stößt die Änderung an
Beim Push-Modell wendet die Pipeline Änderungen direkt in der Zielumgebung an. Beim Pull-Modell holt sich ein Agent den versionierten Sollzustand und wendet ihn dort an [2].
Für die Auslieferung muss die CI-Pipeline dadurch keine direkten Zugänge zur Produktionsumgebung halten [2]. Dafür werden die Schreibrechte am Repository und die Berechtigungen des Agenten besonders wichtig. Der laufende Abgleich kann außerdem Änderungen erkennen, die außerhalb der Pipeline erfolgt sind.
Wofür GitOps sofort zahlt
Der erste Gewinn ist Nachvollziehbarkeit. Änderungen am Sollzustand werden versioniert und lassen sich mit Begründungen und Reviews verbinden. Verbindliche Reviews müssen als Freigaberegeln eingerichtet werden [5]. Direkte Eingriffe in die Umgebung brauchen zusätzlich eine Betriebsprotokollierung.
Ein Revert kann eine frühere deklarative Konfiguration wieder zum Sollzustand machen. Bereits veränderte Daten oder externe Nebenwirkungen werden dadurch nicht automatisch zurückgesetzt; dafür braucht es eigene Wiederherstellungsverfahren.
Wo das Modell an Grenzen stößt
Geheimnisse. Passwörter und Schlüssel gehören nicht im Klartext in ein Repository. In der Praxis liegen sie verschlüsselt im Repository oder in einem externen Tresor, auf den die Beschreibung nur verweist. Beide Wege funktionieren, keiner ist umsonst.
Datenbankmigrationen. Ein Schemawechsel ist kein Zustand, den man laufend abgleichen kann, sondern ein Übergang mit Reihenfolge. GitOps liefert den Rahmen, die Migration selbst braucht weiter ein eigenes Verfahren.
Der Notfalleingriff. Ein direkter Eingriff kann durch den laufenden Abgleich wieder überschrieben werden. Teams brauchen deshalb ein abgestimmtes Verfahren, um den Abgleich bei Bedarf zu pausieren, den Eingriff zu protokollieren und den Sollzustand anschließend nachzuführen.
Beispiel: Argo CD und Flux
Argo CD und Flux sind zwei verbreitete GitOps-Projekte für Kubernetes innerhalb der CNCF [3][4]. Beide gleichen verwaltete Ressourcen mit dem Sollzustand ab. Bei Argo CD werden automatische Korrekturen bestehender Ressourcen (Self-Healing) und das Entfernen nicht mehr deklarierter Ressourcen (Pruning) gesondert konfiguriert [2].
Wie bei IaC-Werkzeugen hängt der Nutzen vom eingerichteten Verfahren ab: verwalteter Umfang, Synchronisierung, Zugriffsrechte, Freigaben und Wiederherstellung müssen zur Umgebung passen.
GitOps verbindet versionierte Sollzustände mit laufendem Abgleich. Verbindliche Reviews, geschützte Repository-Zugänge und begrenzte Agentenrechte müssen eingerichtet werden [5][6]. Für Daten und weitere Systemzustände bleiben eigene Wiederherstellungsverfahren erforderlich.
Was Sie danach entscheiden können
- Ob Ihre Auslieferung auf ein Pull-Modell wechseln sollte und welche direkten Zugänge die Pipeline dann nicht mehr benötigt.
- Wie Ihr Team den Notfalleingriff regelt, bevor er das erste Mal passiert.
- Wo Ihre Geheimnisse liegen sollen: verschlüsselt im Repository oder in einem externen Tresor.
Häufige Fragen
Braucht GitOps zwingend Kubernetes?
Nein, das Modell ist unabhängig davon. Die ausgereiften Agenten kommen allerdings aus der Kubernetes-Welt, dort ist der laufende Abgleich am einfachsten zu haben.
Ersetzt GitOps die CI-Pipeline?
Nein. Die Pipeline baut und prüft weiterhin. GitOps übernimmt den letzten Schritt: das Ausrollen und das Halten des Zustands. Beide zusammen ergeben den Weg von der Änderung bis in den Betrieb.
Was passiert mit Änderungen, die jemand direkt in der Umgebung macht?
Bei verwalteten Ressourcen erkennt der Agent die Abweichung. Ob er sie automatisch korrigiert, hängt von der Konfiguration ab. Bei Argo CD steuert Self-Healing die automatische Korrektur bestehender Ressourcen; Pruning regelt das Entfernen nicht mehr deklarierter Ressourcen [2].
Quellen
- OpenGitOps: Principles CNCF OpenGitOps Working Group
- Argo CD: Automated Sync Policy Argo Project, CNCF
- Argo CD Documentation Argo Project, CNCF
- Flux Documentation Flux, CNCF
- Merge request approvals GitLab-Dokumentation
- Argo CD: Security Argo Project, CNCF