GitOps: Warum Git der Wahrheits-Zustand ist, nicht der Cluster
Der Unterschied zwischen "mach das" und "so soll es aussehen"
Ein klassisches Deployment ist eine Abfolge von Befehlen: kubectl apply, kubectl set image, vielleicht noch ein manueller Patch, wenn etwas nicht passt. Jeder Befehl verändert den Cluster, aber nirgendwo steht geschrieben, wie der Cluster eigentlich aussehen soll, nur wie er zuletzt verändert wurde. GitOps dreht diese Logik um: ein Git-Repository beschreibt den gewünschten Zustand, nicht die Schritte dahin. Ein Controller im Cluster vergleicht diesen Soll-Zustand laufend mit dem, was tatsächlich läuft, und gleicht Abweichungen selbstständig aus.
Was ein Reconciliation-Controller tatsächlich tut
Tools wie ArgoCD oder Flux, beide Projekte der Cloud Native Computing Foundation, arbeiten nach demselben Prinzip: lesen, vergleichen, angleichen. Ändert sich eine YAML-Datei im Repository, zum Beispiel weil eine neue Version ausgerollt werden soll, erkennt der Controller die Differenz zum Live-Zustand und wendet die nötigen Schritte an, bis beide wieder übereinstimmen. Ändert sich dagegen der Cluster selbst, etwa weil jemand eine Einstellung manuell per kubectl edit anpasst, erkennt derselbe Controller auch diese Abweichung und dreht sie zurück, sofern Self-Healing aktiv ist. Der Cluster hat damit keine eigene Meinung mehr darüber, wie er aussehen soll. Die hat ausschließlich das Repository.
Warum das mehr ist als eine andere Werkzeugwahl
Der praktische Effekt zeigt sich nicht im Deployment selbst, sondern danach. Jede Änderung an der Infrastruktur ist ein Commit, mit Autor, Zeitstempel und, sofern Pull Requests Pflicht sind, mit Review vor der Anwendung. Wer wissen will, warum ein Dienst seit Dienstag auf einer anderen Version läuft, muss nicht in einem Audit-Log suchen, sondern liest die Commit-Historie. Und ein Rollback ist kein eigener Vorgang mehr, sondern derselbe Mechanismus rückwärts: der vorherige Commit beschreibt einen bereits einmal erfolgreich abgeglichenen Zustand, ein git revert genügt, der Controller erledigt den Rest.
Wo die Grenze verläuft
Deklarativer Zustand heißt nicht, dass alles im Repository steht. Secrets gehören typischerweise nicht hinein, sondern werden über einen eigenen Mechanismus referenziert, nicht im Klartext versioniert. Und GitOps ersetzt kein Monitoring: der Controller merkt, wenn der Cluster vom Soll-Zustand abweicht, nicht, wenn der Soll-Zustand selbst fehlerhaft war. Ein fehlerhafter Commit wird genauso zuverlässig ausgerollt wie ein korrekter, nur eben nachvollziehbar und rückrollbar.
Was das für TYPO3-Updates bedeutet
Bei TYPO3-Updates zeigt sich das Prinzip konkret: ein Versions-Sprung landet als Commit im Repository, nicht als Einzelklick im Backend, und lässt sich im Nachhinein genauso nachvollziehen wie jede andere Code-Änderung. Wie ein solcher Versions-Sprung im Detail abläuft, beschreiben wir auf der Seite TYPO3 Update, Upgrade und LTS.
Quellen: OpenGitOps (CNCF), ArgoCD-Dokumentation, Flux-Dokumentation.
