Was ist das App-of-Apps-Pattern in ArgoCD?
App-of-Apps ist eine ArgoCD-Application, die selbst weitere ArgoCD-Applications verwaltet. Damit lassen sich ganze Cluster (inklusive Plattform-Komponenten wie Ingress, Cert-Manager, Monitoring und Workloads) deklarativ über ein einziges Root-Repository ausrollen. Das eignet sich besonders für Cluster-Bootstrapping und Multi-Cluster-Setups. Sync-Waves steuern dabei die Reihenfolge: zuerst CRDs, dann Operatoren, dann Custom Resources.
Auch bekannt als: App of Apps · Argo CD App-of-Apps · App-of-Apps
Ist App-of-Apps Pattern bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Die Root-Application zeigt auf ein Verzeichnis im Git-Repository, das ausschließlich Application-Manifeste enthält. ArgoCD synchronisiert dieses Verzeichnis wie jedes andere und legt dabei die Kind-Applications im Cluster an. Jede Kind-Application zeigt wiederum auf ihr eigenes Verzeichnis und rollt dort die eigentlichen Workloads aus. Eine neue Anwendung kommt also als weitere Manifest-Datei in das Root-Verzeichnis, und nach dem nächsten Sync existiert sie.
Den größten Nutzen bringt das Muster beim Cluster-Bootstrapping, also der Erstbestückung eines leeren Clusters. Eine einzige Root-Application installiert Ingress-Controller, Cert-Manager, Monitoring und die Geschäftsanwendungen. Was früher eine Woche Einrichtungsarbeit pro Standort bedeutete, ist dann ein einziger Commit, und der neue Werks-Cluster steht. Bei mehreren Werken entstehen so Umgebungen, die nachweislich aus demselben Repository-Stand stammen.
Die Reihenfolge steuern Sync-Waves. Plattform-Komponenten müssen existieren, bevor Workloads sie brauchen, also zuerst die Custom Resource Definitions (CRDs), dann die Operatoren, dann die Custom Resources, die diese Operatoren verarbeiten. Die Annotation argocd.argoproj.io/sync-wave legt die Abfolge als Ganzzahl fest, niedrigere Werte laufen zuerst. Zwischen Applications greifen die Waves allerdings nur, wenn ArgoCD deren Health-Status auswertet. Diese Prüfung ist für den Ressourcentyp Application seit ArgoCD 1.8 abgeschaltet und muss per Lua-Health-Check in der ConfigMap argocd-cm wieder eingeschaltet werden. Fehlt dieser Schritt, startet die nächste Wave, bevor die vorige wirklich bereit ist.
Zwei Stolpersteine betreffen große Setups. Bei mehreren Verschachtelungsebenen verliert man leicht den Überblick, welche Application woher gesteuert wird. Für viele gleichartige Applications ist ApplicationSet deshalb meist wartungsärmer. Der zweite betrifft Rechte. Wer in das Repository der Root-Application schreiben darf, kann Applications in beliebigen ArgoCD-Projekten anlegen. Die ArgoCD-Dokumentation behandelt das als Admin-Recht, entsprechend eng gehört der Push-Zugriff auf dieses Repository begrenzt.
Neuer Produktions-Cluster mit einem Commit
Ein weiterer Produktions-Cluster soll so aussehen wie die bestehenden, bisher arbeitete das Team dafür eine Checkliste ab. Jetzt legt es eine einzige Root-Application an. Ingress, Cert-Manager, Prometheus und alle Workloads entstehen automatisch in der per Sync-Waves festgelegten Reihenfolge, und der Cluster gleicht seinen Vorgängern bis auf die standortspezifischen Werte.
Plattform-Team und Produkt-Teams blockieren sich nicht mehr
Plattform-Team und Produkt-Teams pflegten ihre Manifeste bisher im selben Repository und warteten gegenseitig auf Reviews. Eine Root-Application verwaltet jetzt eine Plattform-Application mit Operatoren und CRDs sowie mehrere Team-Applications, die auf getrennte Repositories zeigen. Jedes Team merged in seinem eigenen Takt.
Wie skalieren Sie ArgoCD am besten?
App-of-Apps und ApplicationSet lösen dasselbe Grundproblem — viele Apps verwalten — auf unterschiedliche Weise. Zwei Klicks zeigen, welches Muster zu Ihrer Struktur passt.
Wie sind Ihre Deployments strukturiert?
- App-of-Apps oder ApplicationSet: Was ist der Unterschied?
- App-of-Apps verwaltet explizit definierte Kind-Applications über eine Root-Application, ApplicationSet generiert Applications dynamisch aus einem Generator. App-of-Apps passt zu statischen, bewusst gepflegten Setups wie dem Cluster-Bootstrapping, bei dem jede Kind-Application ihre eigene Konfiguration hat. ApplicationSet ist die bessere Wahl, sobald viele gleichartige Applications automatisch entstehen sollen, etwa pro Cluster, pro Verzeichnis oder pro Pull Request.
- Was passiert, wenn ich eine Kind-Application aus dem Root-Verzeichnis entferne?
- Ist für die Root-Application Pruning aktiv, löscht ArgoCD beim nächsten Sync auch die Kind-Application. Ob deren Workloads mitgelöscht werden, entscheidet der Finalizer resources-finalizer.argocd.argoproj.io an der Kind-Application. Mit Finalizer räumt ArgoCD Deployments, Services und alle übrigen Ressourcen ab, ohne ihn laufen sie im Cluster weiter. Prüfen Sie das vor dem ersten Aufräumen, nicht danach.
- Kann eine Kind-Application wiederum App-of-Apps sein?
- Ja, Verschachtelung ist möglich und in großen Organisationen üblich, um Verantwortlichkeiten zu trennen. Mit jeder Ebene wird aber schwerer nachvollziehbar, welche Application woher kommt. Zwei Ebenen reichen in den meisten Setups.
Wo steht Ihr Team bei App-of-Apps Pattern?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu App-of-Apps Pattern: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01Argo ProjectCluster Bootstrapping(externe Seite, öffnet in neuem Tab)
Die Referenz zum App-of-Apps-Muster: eine Root-Application, die alle weiteren Applications erzeugt.
- /02Argo ProjectSync Waves und Sync Phases(externe Seite, öffnet in neuem Tab)
Steuert die Reihenfolge beim Ausrollen, also erst CRDs, dann Operatoren, dann Custom Resources.
- /03Argo ProjectDeclarative Setup(externe Seite, öffnet in neuem Tab)
Applications, Projects und Repositories vollständig als YAML im Git-Repository verwalten.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance