Leistungen
GitOps erklärt: Deployments und Infrastruktur über Git steuern
GitOps ist ein Betriebs- und Delivery-Ansatz, bei dem Git das führende System für die gewünschte Konfiguration ist: Was in Git steht, soll in den Umgebungen laufen. Änderungen passieren über Pull Requests, sind reviewbar, versioniert und nachvollziehbar. Ein automatischer Abgleich sorgt dafür, dass die Realität wieder dem gewünschten Zustand entspricht.
Der Begriff taucht oft im Kubernetes-Umfeld auf, ist aber allgemeiner: GitOps kombiniert bekannte Praktiken aus Infrastructure as Code, CI/CD und Configuration Management zu einem klaren Operating Model.
Was bedeutet GitOps konkret?
In einem GitOps-Setup beschreibt ein Repository den Desired State einer Umgebung. Das kann zum Beispiel sein:
- Deployments, Services und Ingress-Konfiguration für Anwendungen
- Helm/Kustomize-Konfigurationen oder Manifeste pro Umgebung
- Policies und technische Standards, die eingehalten werden müssen
- Konfiguration für Infrastruktur-Komponenten (je nach Stack)
Ein sogenannter Reconciler (ein Agent/Controller) beobachtet das Repo und gleicht es gegen die Zielumgebung ab. Wenn sich etwas unterscheidet, wird nach dem definierten Zielzustand korrigiert.
Wichtig: GitOps ist nicht nur "wir speichern YAML in Git". Der Wert entsteht durch den automatischen Abgleich, klare Workflows und die konsequente Versionierung.
Der Kern: Pull statt Push
Viele klassische Deployment-Prozesse sind push-basiert: Ein CI-System baut Artefakte und "pusht" sie in eine Umgebung (zum Beispiel per SSH, per API oder per Deployment-Job). Das funktioniert, bringt aber typische Probleme mit:
- Credentials für den Zugriff auf Produktion liegen im CI-System.
- Deployments sind schwer reproduzierbar, wenn Schritte außerhalb von Git passieren.
- Manuelle Hotfixes führen schnell zu Drift (die Umgebung weicht vom Code ab).
GitOps setzt in der Regel auf einen Pull-Ansatz: Der Reconciler läuft in oder nahe der Zielumgebung und zieht die gewünschte Konfiguration aus Git. Dadurch bleiben Produktionszugriffe in der Umgebung, und Git wird zur verlässlichen Quelle für das, was laufen soll.
Was gehört in Git (und was nicht)?
In Git gehört der gewünschte Zustand, nicht zwingend jedes Detail:
- Ja: Deployment-Definitionen, Ressourcen, Routing, Feature Flags, Environment-spezifische Values
- Ja: Versionen (Image-Tags, Chart-Versionen), Rollout-Strategien, Abhängigkeiten
- Nein: Klartext-Secrets oder private Schlüssel
Für Secrets ist ein gängiger Weg, sie außerhalb von Git zu halten und nur Referenzen zu versionieren. Alternativ können Secrets verschlüsselt gespeichert werden, wenn das Team das bewusst so betreibt. Entscheidend ist die Regel: Der Git-Verlauf soll keine sensiblen Daten offenlegen.
Ein typischer GitOps-Workflow (Beispiel)
- Ein Team ändert eine Konfiguration, zum Beispiel die Ressourcenlimits oder die Version eines Container-Images.
- Die Änderung wird als Pull Request eingereicht, automatisch geprüft (Linting/Validation) und fachlich reviewed.
- Nach dem Merge erkennt der Reconciler die Änderung und rollt sie in der Zielumgebung aus.
- Bei Problemen kann sauber zurückgerollt werden, indem ein vorheriger Commit wiederhergestellt wird.
Der große Vorteil: Der Weg von "Wir wollen X" zu "X läuft" ist standardisiert und auditierbar. Es gibt weniger Spezialwissen und weniger "magische" Schritte.
Warum sich GitOps lohnt
GitOps ist kein Selbstzweck. Es löst wiederkehrende Schmerzpunkte in Betrieb und Delivery:
- Nachvollziehbarkeit: Jede Änderung ist versioniert, mit Kontext (PR, Review, Ticket).
- Reproduzierbarkeit: Umgebungen lassen sich aus Git heraus konsistent neu aufsetzen.
- Drift-Erkennung: Abweichungen werden sichtbar und können automatisch korrigiert werden.
- Saubere Rollbacks: Zurückrollen ist ein Git-Change, nicht "irgendein Skript".
In der Praxis führt das oft zu weniger Betriebsrisiko und kürzeren Feedback-Schleifen, weil die Grundlage stabiler wird.
GitOps im Zusammenspiel mit Platform Engineering
GitOps ist häufig ein Baustein einer internen Plattform: Teams sollen deployen können, ohne jedes Mal eine Sonderlösung zu bauen. Standards werden in Templates, Policies und Repos gegossen, die Teams wiederverwenden.
GitOps und Security/Compliance: Guardrails statt Blocker
Wenn Änderungen über PRs laufen, lassen sich Security und Compliance besser einbinden, ohne Delivery zu bremsen:
- Reviews und Freigaben sind im Prozess verankert.
- Checks können automatisiert werden (Policies, Validierungen, Scans).
- Der Audit-Trail entsteht "nebenbei" im normalen Workflow.
Das passt gut zu DevSecOps, weil Qualität und Security früh im Prozess stattfinden und nicht als spätes Gate auftauchen.
So starten Sie pragmatisch
Ein GitOps-Einstieg muss kein großes Programm sein. Häufig funktioniert ein schrittweises Vorgehen:
- Ein Service und eine Umgebung auswählen (zum Beispiel Staging).
- Repository-Struktur festlegen (App-Config getrennt von Plattform-Config, wenn sinnvoll).
- Reconcile aktivieren und minimale Regeln definieren (wer darf mergen, wie wird validiert).
- Promotion-Mechanik klären: Wie wandert eine Änderung von Staging nach Produktion?
- Observability ergänzen: Ist sichtbar, was gerade deployed wird und warum?
Wichtig ist, den Prozess für Teams bequem zu machen. Wenn GitOps als zusätzliche Hürde wirkt, wird es umgangen.
Häufige Stolpersteine (und wie man sie vermeidet)
Ein paar Muster tauchen in Projekten immer wieder auf:
- Zu viel auf einmal: Erst einen Golden Path für einen Service-Typ stabil machen, dann erweitern.
- Unklare Ownership: Wer ist zuständig, wenn eine Änderung "klemmt" oder ein Rollout hängen bleibt?
- Drift durch manuelle Eingriffe: Produktion sollte nicht "nebenbei" angepasst werden, sonst geht der Vorteil verloren.
- Secrets-Handling ohne klare Regeln: Hier früh ein sauberes Vorgehen festlegen.
GitOps funktioniert am besten, wenn es als Produkt gedacht wird: klarer Nutzen, klare Regeln, klare Verantwortlichkeiten.
Fazit
GitOps macht Deployments und Betrieb verlässlicher, weil Git zur zentralen Wahrheit wird und der Abgleich automatisiert passiert. Wer bereits CI/CD und Infrastructure as Code nutzt, kann GitOps oft mit überschaubarem Aufwand einführen und bekommt schnell messbare Vorteile: weniger Drift, bessere Nachvollziehbarkeit und reproduzierbare Deployments.