Grundlagen
Was ist GitOps?
Git als einzige Wahrheitsquelle – kein Deploy ohne Commit.
GitOps – die kurze Erklärung
GitOps ist ein Betriebsmodell, bei dem der gesamte gewünschte Zustand eines Systems – Code, Konfiguration, Infrastruktur – in Git-Repositories versioniert ist. Änderungen am System geschehen ausschließlich über Git: kein manuelles kubectl apply, kein SSH in Server.
Das Prinzip: Git ist die einzige Wahrheitsquelle (single source of truth). Was in Git steht, soll im System laufen. Ein automatisiertes System (der "GitOps Operator") sorgt dafür, dass der tatsächliche Zustand immer dem beschriebenen Zustand entspricht.
Analogie: Stell dir eine Wohnung vor, deren Grundriss als Zeichnung existiert. GitOps bedeutet: Die Wohnung sieht immer exakt so aus wie die Zeichnung. Wenn jemand eigenmächtig eine Wand einreißt, wird sie automatisch wieder aufgebaut – weil die Zeichnung es so sagt.
Wie funktioniert GitOps in der Praxis?
Das GitOps-Modell hat zwei zentrale Elemente:
1. Das Desired-State-Repository
Ein Git-Repository enthält alle Kubernetes-Manifeste, Helm-Charts oder Terraform-Konfigurationen. Das ist der gewünschte Zustand. Jede Änderung läuft über einen Pull Request – mit Code Review, Audit-Trail und der Möglichkeit, jederzeit zu einem früheren Zustand zu wechseln.
2. Der GitOps Operator
Ein Tool wie ArgoCD oder Flux läuft im Cluster und beobachtet das Repository. Sobald sich etwas in Git ändert, synchronisiert der Operator den Cluster-Zustand damit. Weicht der tatsächliche Zustand ab, wird er korrigiert (reconciliation).
GitOps vs. klassisches CI/CD – was ist der Unterschied?
Das ist die häufigste Frage. Der Unterschied liegt im Push vs. Pull Prinzip:
| Klassisches CI/CD (Push) | GitOps (Pull) | |
|---|---|---|
| Wer deployt? | Die Pipeline schreibt direkt in den Cluster | Der Operator im Cluster holt sich Änderungen aus Git |
| Credentials | Pipeline braucht Cluster-Zugriff (Security-Risiko) | Kein externer Zugriff auf den Cluster nötig |
| Drift-Erkennung | Nur bei nächstem Deployment bemerkt | Kontinuierlich, automatische Korrektur |
| Rollback | Pipeline neu triggern | git revert → automatisch eingespielt |
| Audit-Trail | In Pipeline-Logs (oft kurzlebig) | Git-History (unveränderlich, langlebig) |
Die 4 GitOps-Prinzipien (OpenGitOps)
Die OpenGitOps Working Group hat vier Kernprinzipien definiert:
- Declarative – Der Zustand des Systems wird deklarativ beschrieben (YAML, HCL), nicht imperativ (Skripte)
- Versioned and Immutable – Der gewünschte Zustand ist in Git versioniert. Vergangene Zustände bleiben erhalten
- Pulled Automatically – Software-Agenten holen Änderungen aktiv aus dem Repository, anstatt dass Änderungen eingespielt werden
- Continuously Reconciled – Software-Agenten prüfen kontinuierlich den Ist-Zustand und korrigieren Abweichungen
GitOps-Tools im Überblick
ArgoCD
ArgoCD ist der bekannteste GitOps-Operator für Kubernetes. Es hat ein visuelles Dashboard, das den Sync-Status aller Anwendungen anzeigt. Weit verbreitet in deutschen Enterprise-Umgebungen.
Flux
Flux ist schlanker und CLI-orientierter. Es ist ein CNCF-Graduated-Projekt und wird oft bevorzugt, wenn GitOps "weiter hinten" im Stack integriert werden soll (weniger UI, mehr Automatisierung).
Terraform + GitOps
GitOps gilt nicht nur für Kubernetes. Mit Terraform und Tools wie Atlantis oder Spacelift lässt sich dasselbe Prinzip auf Cloud-Infrastruktur anwenden: Infrastruktur als Code in Git, Changes über Pull Requests.
GitOps und Security
GitOps verbessert die Sicherheitslage erheblich:
- Kein direkter Cluster-Zugriff für CI/CD-Tools – Pipeline braucht keine Cluster-Credentials
- Jede Änderung ist in Git auditierbar – wer hat wann was gemergt?
- Policy-as-Code – Sicherheitsrichtlinien (z.B. via Kyverno) sind Teil des Repos
- Automatische Drift-Korrektur – Manuelle Änderungen ("wer hat das gemacht?") werden zurückgesetzt
Im DevSecOps-Kontext ist GitOps das operative Fundament: Alles ist versioniert, auditierbar und automatisiert. Das macht Security-Reviews einfacher und Compliance-Nachweise zuverlässig.
GitOps einführen – pragmatischer Einstieg
- Kubernetes-Manifeste in Git – falls noch nicht vorhanden, Konfigurationen versionieren
- ArgoCD im Cluster installieren –
kubectl create namespace argocd && kubectl apply -n argocd -f install.yaml - Erste App in ArgoCD anlegen – Repository verbinden, Pfad zum Manifest angeben
- CI trennen von CD – CI baut und pusht Images, CD (ArgoCD) deployt. Klare Trennung der Verantwortlichkeiten.
- Branch-Strategie definieren – welcher Branch entspricht welcher Umgebung (main → prod, develop → staging)?
Fazit: GitOps ist kein Tool, sondern ein Mindset
GitOps funktioniert nur, wenn das Team es lebt: keine manuellen Änderungen am Cluster, kein "kurz schnell was in Prod patchen". Wer das schafft, bekommt ein System, das reproduzierbar, auditierbar und sicher ist – und bei dem ein neues Teammitglied den kompletten Systemzustand aus einem Git-Repository verstehen kann.
GitOps in der Praxis einführen
Von ArgoCD-Setup über Branch-Strategie bis Policy-as-Code – wir begleiten euch durch die Einführung. Hands-on in eurer Umgebung.