GitOps-Lab mit ArgoCD App-of-Apps

Ein lokales Kubernetes-Lab nach dem App-of-Apps-Pattern, das end-to-end läuft: ArgoCD gleicht den Cluster gegen das Git-Repo ab – Ingress, cert-manager, Monitoring und eine Demo-App inklusive, die CI baut die Images nach GHCR.

Kubernetes ArgoCD Helm Go kind GitHub Actions Docker GHCR ingress-nginx cert-manager Grafana

Auf GitHub ansehen

Worum geht’s

Ich will das App-of-Apps-Pattern von ArgoCD nicht nur in der Theorie verstehen, sondern wirklich anwenden, auf einem realistischen Setup, das so auch in Produktion laufen könnte. Das Lab besteht aus zwei Repositories: demo-app für den Anwendungscode (Go-API + nginx-Frontend) und platform-gitops als GitOps Source of Truth, die ArgoCD überwacht.

Was läuft

Der Stack läuft end-to-end: kind create cluster → ArgoCD installieren → Root-App anwenden, den Rest zieht ArgoCD selbst aus dem Repo. Danach sind Demo-App, ArgoCD-UI und Grafana per Ingress im Browser erreichbar.

App-of-Apps: eine Root-Application unter clusters/local/bootstrap/ zieht je eine Application pro Infra-Komponente (ingress-nginx, cert-manager, sealed-secrets, Monitoring/Grafana) und pro Workload
In-Repo Helm-Chart für die Demo-App – Deployments, Services, Ingress und NetworkPolicy, mit Security-Context (non-root, verifizierbar)
CI in demo-app baut die Container-Images (Frontend + Go-API) nach GHCR, getaggt mit latest und Commit-SHA; das GitOps-Repo referenziert sie über values.yaml
Die Architektur ist in der ARCHITECTURE.md dokumentiert

Nächste Schritte

Automatischer Image-Bump: Die CI baut und pusht bereits, der Versions-Bump im GitOps-Repo passiert noch per Hand – der letzte Schritt zur geschlossenen Pipeline
Sealed Secrets und Monitoring-Dashboards in der Praxis nutzen, nicht nur deployen

Warum dieses Projekt

GitOps verspricht: Drift ist sofort sichtbar, Rollbacks sind ein git revert, und am Cluster wird nichts per Hand geändert. Ob diese Disziplin im Alltag trägt, findet man nur heraus, wenn man das Setup einmal komplett selbst aufbaut.