Argo CD ist ein Werkzeug für kontinuierliche Auslieferung nach dem GitOps-Prinzip auf Kubernetes. Es läuft als Controller im Cluster, beobachtet ein oder mehrere Git-Repositories und sorgt dafür, dass der tatsächliche Zustand des Clusters dem dort beschriebenen entspricht. Das Projekt gehört zur Cloud Native Computing Foundation und hat den Status Graduated.
Aufbau
- Application: eine eigene Kubernetes-Ressource, die beschreibt, welches Repository, welcher Pfad und welches Zielcluster plus Namespace zusammengehören.
- Repo Server: rendert die Manifeste. Dafür nutzt er Helm, Kustomize, Jsonnet oder reines YAML.
- Application Controller: vergleicht Soll und Ist und korrigiert Abweichungen.
- API-Server und Oberfläche: Web-UI, CLI (
argocd) und REST-API für Bedienung und Automatisierung.
Sync-Status und automatische Korrektur
Argo CD zeigt pro Anwendung zwei Bewertungen: Sync Status (entspricht das Cluster dem Repository?) und Health Status (laufen die Ressourcen?). Ist eine Abweichung erkannt, kann man sie in der Oberfläche sehen und manuell synchronisieren – oder den Auto-Sync aktivieren, der selbstständig korrigiert. Wichtige Begleitoptionen:
- Prune: Ressourcen, die im Repository entfernt wurden, werden auch im Cluster gelöscht.
- Self-Heal: manuelle Änderungen im Cluster werden zurückgesetzt.
- Sync Windows: Zeitfenster, in denen synchronisiert werden darf – sehr nützlich, um Produktionsänderungen außerhalb der Bereitschaft zu verhindern.
Sync Waves und Hooks
Reihenfolge lässt sich steuern: Die Annotation argocd.argoproj.io/sync-wave ordnet Ressourcen in Wellen ein – kleinere Zahlen zuerst. Typische Nutzung: Namespaces und CustomResourceDefinitions in Welle -1, Datenbankmigrationen in Welle 0, Anwendungen danach. Zusätzlich gibt es Hooks für Zeitpunkte im Ablauf:
apiVersion: batch/v1
kind: Job
metadata:
name: db-migrate
annotations:
argocd.argoproj.io/hook: PreSync # PreSync, Sync, PostSync, SyncFail
argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
template:
spec:
restartPolicy: Never
containers:
- name: migrate
image: registry.example.org/team/app:1.4.0
command: ["./migrate", "up"]Ein PreSync-Hook führt die Migration aus, bevor die neuen Pods ausgerollt werden; schlägt er fehl, bricht die Synchronisation ab – die alte Version läuft weiter. Das ist ein sehr wirksames Muster für risikoarme Datenbankänderungen.
App-of-Apps statt Einzelpflege
Bei vielen Anwendungen legt man eine übergeordnete Application an, die auf ein Verzeichnis mit weiteren Application-Manifesten zeigt. Damit verwaltet eine einzige Ressource den gesamten Bestand – ein neues Verzeichnis im Repository genügt, um eine neue Anwendung zu registrieren. Ebenso üblich ist ein Satz von ApplicationSets, die Anwendungen aus einer Vorlage für mehrere Cluster oder Umgebungen erzeugen.