Was ist das Besondere an GitOps?
GitOps macht Git zum alleinigen Steuerungsinstrument für Infrastruktur und Deployments. Statt Befehle auf Servern auszuführen, beschreibt man den gewünschten Zustand deklarativ in einem Git-Repository. Tools wie ArgoCD oder Flux sorgen dafür, dass die Realität diesem Zustand entspricht. Vorteil für regulierte Branchen: vollständiger Audit-Trail über die Git-Historie, automatische Reconciliation bei Drift, klar getrennte Verantwortlichkeiten zwischen CI (Build, Test) und CD (Sync).
GitOps mit ArgoCD-WorkshopGitOps macht ein Git-Repository zum alleinigen Steuerungsinstrument für Infrastruktur und Deployments. Der gewünschte Systemzustand wird deklarativ beschrieben — also als Soll-Zustand, nicht als Abfolge von Befehlen. Ein Agent wie ArgoCD oder Flux überwacht das Repository und gleicht den tatsächlichen Zustand des Systems kontinuierlich mit dem im Git hinterlegten Soll-Zustand ab.
Dieser Abgleich heißt Reconciliation. Weicht die Realität ab — etwa weil jemand manuell am Cluster geändert hat — erkennt der Agent diese Drift und stellt den im Git definierten Zustand automatisch wieder her. Deployment wird damit zu einem reinen Git-Vorgang: Ein Pull Request, der den Soll-Zustand ändert, löst nach dem Merge die Aktualisierung des Systems aus. Niemand führt mehr Befehle direkt auf Servern aus.
Für regulierte Branchen ist das ein erheblicher Compliance-Gewinn. Jede Änderung am Produktionszustand durchläuft den Git-Workflow mit Review und hinterlässt einen vollständigen Audit-Trail in der Historie. Die klare Trennung zwischen CI, das Build und Test verantwortet, und CD, das den Sync übernimmt, schafft saubere Verantwortlichkeiten. Drift-Erkennung verhindert zudem unkontrollierte manuelle Eingriffe, die in OT-Umgebungen besonders riskant sind.
GitOps ist eng mit Kubernetes verbunden, weil dessen deklaratives Modell ideal passt, aber das Prinzip ist nicht darauf beschränkt. Ein häufiger Stolperstein ist der Umgang mit Secrets, die nicht im Klartext ins Git gehören und über Lösungen wie Sealed Secrets oder externe Secret-Stores eingebunden werden müssen. Auch die Repository-Struktur — getrennt nach Umgebungen und Anwendungen — will durchdacht sein, etwa über Muster wie App-of-Apps.
Cluster-Bootstrapping per App-of-Apps
Ein Plattform-Team beschreibt einen kompletten Kubernetes-Cluster inklusive Ingress, Cert-Manager und Monitoring in einem Root-Repository. ArgoCD rollt über das App-of-Apps-Pattern den gesamten Stack deklarativ aus — reproduzierbar für jeden neuen Cluster.
Automatische Drift-Korrektur in der Produktion
Bei einem Fertigungsbetrieb ändert jemand manuell eine Konfiguration am Produktions-Cluster. ArgoCD erkennt die Abweichung vom Git-Soll-Zustand und stellt den definierten Zustand automatisch wieder her — die ungewollte Änderung wird zurückgesetzt und protokolliert.
- Was ist der Unterschied zwischen GitOps und klassischem CI/CD-Deployment?
- Bei klassischem CI/CD pusht eine Pipeline aktiv Änderungen auf die Zielumgebung. Bei GitOps zieht ein Agent den Soll-Zustand aus Git und gleicht ihn kontinuierlich ab. Der Push wird zum Pull, und das Git-Repository ist die einzige Quelle der Wahrheit.
- Wie verwalte ich Secrets in einem GitOps-Workflow?
- Secrets gehören nicht im Klartext ins Git-Repository. Üblich sind verschlüsselte Ansätze wie Sealed Secrets oder die Anbindung externer Secret-Stores über Operatoren, sodass im Repository nur verschlüsselte oder referenzierende Objekte liegen.
- Funktioniert GitOps auch außerhalb von Kubernetes?
- Das Prinzip — deklarativer Soll-Zustand in Git plus automatischer Abgleich — ist nicht an Kubernetes gebunden. In der Praxis ist die Tool-Landschaft mit ArgoCD und Flux jedoch stark auf Kubernetes ausgerichtet, weil dessen deklaratives Modell besonders gut passt.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance