GitOps: Infrastruktur aus dem Git-Repository betreiben

GitOps ist ein Betriebsmodell für Infrastruktur und Anwendungen, bei dem ein Git-Repository die einzige Quelle der Wahrheit über den gewünschten Zustand eines Systems ist. Ein Automatismus sorgt dafür, dass das laufende System diesem Zustand entspricht – nicht ein Mensch, der Befehle absetzt.

Die vier Grundsätze

  1. Deklarativ: Beschrieben wird das Ergebnis, nicht der Weg dorthin. Ein Manifest sagt „drei Instanzen dieser Anwendung“, nicht „führe dreimal diesen Start-Befehl aus“.
  2. Versioniert und unveränderlich: Der Zustand liegt in Git. Jede Änderung ist ein Commit mit Autor, Zeitpunkt und Begründung – und lässt sich zurücknehmen.
  3. Automatisch ausgerollt: Ein Agent beobachtet das Repository und zieht Änderungen selbstständig ins Zielsystem. git push ist damit der Deployment-Vorgang.
  4. Ständiger Abgleich: Der Agent vergleicht laufend Soll und Ist und korrigiert Abweichungen. Löscht jemand von Hand eine Ressource, wird sie wiederhergestellt.

Push gegen Pull

Klassische CI/CD arbeitet push-basiert: Die Pipeline hat Zugangsdaten für das Zielsystem und schiebt Änderungen aktiv hinein. GitOps dreht das um: Ein Agent im Cluster holt sich den gewünschten Zustand selbst. Sicherheitstechnisch ist das der wichtigere Unterschied – die Build-Umgebung braucht keine Schreibrechte in der Produktion mehr, und ein kompromittierter Build kann keine Infrastruktur umkonfigurieren.

Grenzen und Fallstricke

  • Geheimnisse gehören nicht ins Repository. Passwörter und Schlüssel dürfen nicht als Klartext in Git liegen. Lösungen sind ein externer Secret-Speicher (etwa HashiCorp Vault oder SOPS mit verschlüsselten Dateien).
  • Der Abgleich korrigiert auch gewollte Handarbeit. Wer im Notfall von Hand eingreift, muss die Änderung anschließend in Git nachziehen – sonst überschreibt der Agent sie wieder. Das ist kein Fehler, sondern das Prinzip; der Umgang damit gehört in den Bereitschaftsleitfaden.
  • Repository-Struktur will geplant sein. Ein Repository für alles wird unübersichtlich, ein Repository pro Umgebung erzeugt Duplikate. Gängig ist die Trennung nach Umgebungen in Verzeichnissen mit gemeinsamen Basiskomponenten (Kustomize-Overlays oder Helm-Values).
  • Datenbanken und Migrationen bleiben schwierig. Ein Schema lässt sich nicht deklarativ zurückrollen. Migrationen laufen deshalb meist als eigener Schritt mit Vorwärtsstrategie und gesicherter Kompatibilität.

Werkzeuge

Die verbreitetsten Umsetzungen sind Argo CD und Flux. Beide sind CNCF-Projekte, beobachten Git und halten ein Kubernetes-Cluster auf dem gewünschten Stand; Argo CD legt Wert auf eine grafische Oberfläche mit sichtbarem Abweichungsstand, Flux auf komponierbare Controller ohne eigene Oberfläche. Außerhalb von Kubernetes gilt dasselbe Muster für Server mit Ansible oder Terraform, deren Konfiguration ebenfalls in Git liegt.

Verwandte Grundlagen: CI/CD, Argo CD, Kubernetes, Helm.