GitOps: Infrastruktur aus Git steuern

Kurz: Der gewünschte Zustand von Anwendungen und Infrastruktur steht in einem Git-Repository, und ein Werkzeug gleicht die laufenden Systeme automatisch damit ab.

Genauer: Bei GitOps ist Git die einzige Quelle der Wahrheit. Änderungen erfolgen nicht per Handbefehl am Server, sondern als Commit oder Pull Request. Ein Agent im Cluster (zum Beispiel Argo CD oder Flux) vergleicht ständig den Soll-Zustand im Repository mit dem Ist-Zustand und gleicht Abweichungen an.

Im Detail

Prinzipien

• Deklarativ: Die Dateien beschreiben, was laufen soll (YAML für Kubernetes), nicht die Schritte dorthin.
• Versioniert: Jede Änderung hat Autor, Zeitpunkt und Begründung, und ist rückgängig zu machen (git revert).
• Automatisch angewendet: Ein Agent übernimmt freigegebene Änderungen.
• Selbstheilend: Wird etwas von Hand verändert, setzt der Agent es zurück (Drift-Erkennung).

Pull statt Push

Klassische Pipelines schieben (Push) Änderungen mit eigenen Zugangsdaten in den Cluster. Bei GitOps zieht (Pull) der Agent im Cluster die Änderungen aus dem Repository. Der Cluster muss keine Zugangsdaten für die Pipeline herausgeben, das erhöht die Sicherheit, und der Stand ist jederzeit nachvollziehbar.

Typischer Ablauf

1. Entwickler ändern die Manifest-Datei (z. B. neues Image-Tag) in einem Branch.
2. Pull Request mit Review und automatischen Prüfungen.
3. Nach dem Merge erkennt der Agent die Änderung.
4. Der Agent wendet sie an und meldet den Status. Zurückrollen heißt: Commit rückgängig machen.

Stolpersteine

Geheimnisse (Passwörter) dürfen nicht im Klartext ins Repository, dafür gibt es Werkzeuge wie Sealed Secrets oder SOPS. Trenne Anwendungscode und Umgebungskonfiguration, sonst löst jede Codeänderung einen Konfigurationsbau aus. GitOps ist am wirkungsvollsten zusammen mit Infrastructure as Code.

Siehe auch: Infrastructure as Code, Kubernetes-Grundlagen, Git, CI/CD-Pipeline