Was unterscheidet GitOps von klassischem CI/CD?
Direkte Antwort
Klassisches CI/CD verwendet eine Pipeline, die aktiv (push-basiert) Änderungen in eine Zielumgebung deployt. GitOps macht ein Git-Repository zur alleinigen Wahrheitsquelle für den gewünschten Systemzustand, während ein im Zielcluster laufender Operator (etwa Argo CD oder Flux) kontinuierlich prüft und den tatsächlichen Zustand automatisch an den im Git-Repository beschriebenen Soll-Zustand angleicht (pull-basiert).
"Bei klassischem CI/CD sagt die Pipeline dem Cluster, was zu tun ist. Bei GitOps beobachtet der Cluster das Repository und gleicht sich selbst an.
Der Unterschied zwischen GitOps und klassischem CI/CD wird oft auf "Deployment über Git" verkürzt, obwohl der eigentliche architektonische Unterschied in der Push-vs.-Pull-Richtung der Synchronisation liegt.
Push-basiertes klassisches CI/CD
In einer klassischen Pipeline löst eine Änderung im Code-Repository einen Job aus, der aktiv Zugriff auf die Zielumgebung braucht, um dort Änderungen anzuwenden — die Pipeline muss also Credentials und Netzwerkzugriff auf jede Zielumgebung haben.
Dieser Ansatz konzentriert weitreichende Zugriffsrechte in der CI/CD-Pipeline selbst, die damit zu einem attraktiven Angriffsziel wird, wenn sie kompromittiert werden sollte.
Pull-basiertes GitOps mit kontinuierlicher Konvergenz
Bei GitOps liest ein im Zielcluster laufender Operator kontinuierlich den gewünschten Zustand aus dem Git-Repository und wendet Abweichungen selbstständig an, ohne dass eine externe Pipeline aktiven Schreibzugriff auf den Cluster braucht.
Dieses Modell reduziert die Angriffsfläche (kein externer Zugriff mit Schreibrechten von außen nötig) und erkennt zusätzlich automatisch, wenn der tatsächliche Zustand vom im Git beschriebenen Soll-Zustand abweicht — etwa durch eine manuelle, nicht dokumentierte Änderung — und korrigiert diese Abweichung automatisch.
Praktische Vorteile bei Rollback und Auditierbarkeit
Weil der gesamte gewünschte Zustand im Git-Repository versioniert ist, ist ein Rollback auf einen früheren Zustand technisch identisch mit einem Git-Revert, was den Rollback-Prozess erheblich vereinfacht gegenüber dem erneuten Ausführen einer alten Pipeline-Version.
Gleichzeitig liefert die Git-Historie automatisch ein vollständiges Audit-Log aller Zustandsänderungen, was bei regulatorischen Anforderungen an Nachvollziehbarkeit einen direkten Zusatznutzen bietet.
Wann passt es — wann nicht?
Passt gut
- ✓Es gibt mehrere Cluster oder Umgebungen, deren Zustand konsistent und nachvollziehbar sein soll
Passt nicht
- ✗Es gibt eine einzelne, sehr einfache Deployment-Umgebung ohne Bedarf an automatischer Konvergenzprüfung