GitOps mit Argo CD in OpenShift

1 Git ist das Soll, der Cluster das Ist

Argo CD vergleicht dauernd, was in Git steht, mit dem, was im Cluster läuft – und gleicht ab.

Anders als beim Push-Modell aus der Build-Kette läuft Argo CD im Ziel-Cluster und zieht – kein Deploy-Token, das nach aussen gegeben werden muss. automated.selfHeal schliesst genau die Drift-Lücke, die helm upgrade offen lässt: eine manuelle Cluster-Änderung wird zurückgedreht.

2 Den GitOps-Operator installieren

OpenShift GitOps ist Argo CD als Operator – Argo, Dex und eine fertige openshift-gitops-Instanz.

oc get csv -A | grep -i gitops   # schon installiert?

cat <<'EOF' | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-gitops-operator
  namespace: openshift-operators
spec:
  channel: latest
  name: openshift-gitops-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

oc get csv -n openshift-operators -w
oc get route -n openshift-gitops   # die Argo-UI, sobald bereit
oc get pods -n openshift-gitops

Der Operator legt sofort den Namespace openshift-gitops mit einer lauffähigen Argo-CD-Instanz an – kein separates Bootstrapping nötig, wie es Community-Argo-CD bräuchte.

3 Eine Application anlegen

Eine Application zeigt auf {Repo, Pfad} und {Cluster, Namespace} – das eine Objekt, das alles verbindet.

cat <<'EOF' | oc apply -f -
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-gitops
  namespace: openshift-gitops
spec:
  project: default
  source:
    repoURL: https://github.com/openshift/origin.git
    targetRevision: HEAD
    path: examples/hello-openshift
  destination:
    server: https://kubernetes.default.svc
    namespace: library
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=false
EOF

oc get application demo-gitops -n openshift-gitops
oc get application demo-gitops -n openshift-gitops -o jsonpath='{.status.sync.status} {.status.health.status}{"\n"}'

Das Beispiel-Repo dient nur der Demonstration – für ein echtes Projekt zeigt source.path auf den eigenen Helm-Chart-Ordner (helm-am-bibliothek-chart.html). syncPolicy.automated ohne weitere Angabe reicht für prune und selfHeal – ohne sie bleibt der Sync manuell, per argocd app sync demo-gitops oder Klick in der UI.

4 Drift erzeugen und selfHeal zusehen

Eine manuelle Cluster-Änderung, die Argo zurückdreht – live beobachtet.

# den von Argo verwalteten Deployment manuell veraendern:
oc scale deployment/hello-openshift -n library --replicas=0

# sofort danach: Argo sieht die Abweichung
oc get application demo-gitops -n openshift-gitops -w
# Status kurz OutOfSync, dann durch selfHeal wieder Synced

# der Beweis: die Replica-Zahl ist zurueckgedreht, nicht bei 0 geblieben
oc get deployment/hello-openshift -n library

Wer die andere Richtung sehen will: eine Zeile im Git-Repo ändern und pushen – Argo zieht sie innerhalb des Poll-Intervalls (Standard 3 Minuten, oder sofort per Webhook) automatisch in den Cluster.

5 Ein Secret nicht im Klartext versionieren

Ein Klartext-Secret-YAML in Git ist base64, also lesbar. Sealed Secrets verschlüsselt mit dem Public Key eines in-cluster Controllers.

# Sealed-Secrets-Controller installieren (Community-Operator oder manuell):
oc apply -f https://github.com/bitnami-labs/sealed-secrets/releases/latest/download/controller.yaml

# ein normales Secret NUR lokal erzeugen, nie committen:
oc create secret generic demo-api-key -n library \
  --dry-run=client --from-literal=key=ein-echtes-geheimnis -o yaml > secret-lokal.yaml

# mit kubeseal in ein committierbares SealedSecret umwandeln:
kubeseal --format=yaml < secret-lokal.yaml > sealed-secret.yaml
rm secret-lokal.yaml   # die Klartextdatei nie behalten

cat sealed-secret.yaml   # das hier ist sicher zu committen - verschluesselt
oc apply -f sealed-secret.yaml

# der Controller im Cluster entschluesselt automatisch:
oc get secret demo-api-key -n library

sealed-secret.yaml ist nur für diesen einen Cluster entschlüsselbar – der Public Key des Controllers ist clusterspezifisch. Deshalb gehört der private Sealing-Key auf die Backup-Liste, sonst sind alle SealedSecrets nach einem Rebuild (Schritt 6) unlesbar.

6 Der Rebuild-Ablauf als Checkliste

Wenn alles in Git steht, ist ein Cluster wegwerfbar – hier nur durchgegangen, nicht ausgeführt.

1. sno.ps1 destroy – Server, Snapshot, IP, Firewall weg
2. sno.ps1 install – frischer OKD-Single-Node, ~35 Minuten
3. GitOps-Operator installieren (Schritt 2) und die Wurzel-Application anwenden (oc apply -f bootstrap/)
4. Argo zieht Namespaces, RBAC, Workloads, Operator-Subscriptions und die Argo-Application-Objekte selbst aus Git zurück
5. warten bis alles Synced und Healthy ist – Argo-Sync grob 10 Minuten, Operatoren-Reconcile grob 10 Minuten

„Wiederhergestellt“ heißt ehrlich: Workloads ja, Daten nur bei separatem Backup – GitOps rettet die Struktur, nicht den Inhalt. Der zurückgestellte --rebuild-Flag im cloud-host-Skript wäre genau diese fünf Schritte in einem Kommando.

7 Typische Fallen

8 Wie das Projekt es macht

Aktuell kein Argo CD im Einsatz – die Bibliothek deployt per helm upgrade --install aus Jenkins (build-kette-openshift.html), Secrets werden von Hand mit oc create secret angelegt (secrets-in-openshift.html). Diese Anleitung zeigt das Alternativmuster, das der Atlas als nächsten Ausbau nennt: eine Wurzel-App, je Dienst eine Application auf das Helm-Chart – Jenkins baut dann nur noch das Image, den Rest zieht Argo. Die SNO-API ist nur übers Tailnet erreichbar, das gilt für Argo CD (im Cluster) nicht – nur für den Zugriff auf den Cluster von aussen.

+ Die Kurzfassung