Platform Engineering & DevOps
Was unterscheidet GitOps von klassischem CI/CD?
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.
Nextise Wissen · · 6 Minuten Lesezeit
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.
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, wenn …
- Es gibt mehrere Cluster oder Umgebungen, deren Zustand konsistent und nachvollziehbar sein soll
Ein anderer Ansatz ist nötig, wenn …
- Es gibt eine einzelne, sehr einfache Deployment-Umgebung ohne Bedarf an automatischer Konvergenzprüfung
Wissen allein reicht nicht — wir zeigen, wie es im Betrieb funktioniert.
Unsere Seminare verbinden die Konzepte aus dem Wissen-Hub mit konkreter Praxis. Ihr Team lernt direkt an eigenen Aufgaben — praxisnah, kompakt, sofort anwendbar.
Schulungen entdeckenLassen Sie uns über Ihr nächstes Training sprechen.
Unser Team steht Ihnen rund um die Uhr zur Verfügung und freut sich auf Ihre Anfrage. Einfach anrufen oder eine Nachricht hinterlassen – wir kümmern uns schnellstmöglich um Ihre Anfrage, ob es um eine Schulung, einen Vortrag oder eine Präsentation geht. Jetzt loslegen!
Selina Schmid
Leiterin Kodschul