Kostenlose DevOps-Analyse
Zurück zum Glossar
DevOps Glossar·CI/CD

App-of-Apps Pattern

// Direkte Antwort

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 — ideal für Cluster-Bootstrapping und Multi-Cluster-Setups. Sync-Waves steuern dabei die Reihenfolge: zuerst CRDs, dann Operatoren, dann Custom Resources.

App-of-Apps im Workshop
// Im DetailApp-of-Apps Pattern

Das App-of-Apps-Pattern ist ein ArgoCD-Entwurfsmuster, bei dem eine einzige Root-Application weitere ArgoCD-Applications verwaltet, statt jede einzeln anzulegen. Die Root-Application zeigt nur auf ein Verzeichnis mit Application-Manifesten; ArgoCD erstellt daraus die Kind-Applications automatisch, und jede verwaltet wiederum ihre eigenen Workloads. So lässt sich ein ganzer Cluster über einen einzigen Einstiegspunkt deklarativ aus Git bestücken.

Der Sinn dahinter ist gelöste Skalierung: Sobald ein Cluster aus Dutzenden Applications besteht, wird deren manuelle Einrichtung mühsam und fehleranfällig. Das App-of-Apps-Pattern bündelt diese Verwaltung in einer Hierarchie und macht das Cluster-Bootstrapping reproduzierbar — ein zentrales GitOps-Prinzip im ArgoCD-Umfeld.

Der zentrale Vorteil liegt im Cluster-Bootstrapping. Ein frischer Cluster wird durch das Anlegen einer einzigen Root-Application komplett bestückt — von Ingress-Controller und Cert-Manager über Monitoring bis zu den eigentlichen Geschäftsanwendungen. Bei Multi-Cluster-Setups, etwa über mehrere Werksstandorte, ist das die Grundlage für reproduzierbare, identische Umgebungen.

Sync-Waves steuern dabei die kritische Reihenfolge. Plattform-Komponenten müssen vor den Workloads existieren, die sie benötigen — zuerst die Custom Resource Definitions, dann die Operatoren, dann die Custom Resources, die diese Operatoren verarbeiten. Über die Annotation argocd.argoproj.io/sync-wave wird diese Abfolge deklarativ festgelegt, statt sich auf Glück beim Parallel-Deployment zu verlassen.

Stolperstein in der Praxis ist die wachsende Komplexität bei sehr großen Setups. Wenn die Verschachtelung mehrere Ebenen tief wird, verliert man leicht den Überblick, welche Application woher gesteuert wird. Hier ist ApplicationSet oft die wartungsärmere Alternative, weil es Applications generiert statt sie einzeln zu pflegen.

// Beispiele aus der Praxis2 Szenarien
/01

Cluster-Bootstrapping mit einem Commit

Ein neuer Produktions-Cluster wird durch das Anlegen einer einzigen Root-Application vollständig eingerichtet: Ingress, Cert-Manager, Prometheus und alle Workloads entstehen automatisch in der per Sync-Waves definierten Reihenfolge.

/02

Plattform-Komponenten getrennt von Workloads

Eine Root-Application verwaltet eine Plattform-Application (Operatoren, CRDs) und mehrere Team-Applications. Plattform-Team und Produkt-Teams arbeiten in getrennten Repositories, ohne sich gegenseitig zu blockieren.

// Häufige FragenFAQ
Wann sollte ich App-of-Apps statt ApplicationSet verwenden?
App-of-Apps eignet sich, wenn die Kind-Applications explizit und individuell definiert sind und sich selten ändern — etwa beim Cluster-Bootstrapping. ApplicationSet ist die bessere Wahl, sobald viele gleichartige Applications dynamisch aus einer Datenquelle generiert werden sollen, etwa pro Cluster oder pro Branch.
Wie steuere ich die Reihenfolge beim App-of-Apps-Deployment?
Über Sync-Waves, gesetzt per Annotation argocd.argoproj.io/sync-wave mit einer Ganzzahl. ArgoCD verarbeitet niedrigere Wave-Nummern zuerst. Typisch ist: CRDs in Wave 0, Operatoren in Wave 1, Custom Resources in Wave 2.
Kann eine Kind-Application wiederum App-of-Apps sein?
Ja, Verschachtelung ist möglich und in großen Organisationen üblich, um Verantwortlichkeiten zu trennen. Allerdings steigt mit jeder Ebene die Komplexität, weshalb man die Verschachtelungstiefe bewusst begrenzen sollte.
App-of-Apps vs. ApplicationSet — was ist der Unterschied?
App-of-Apps verwaltet explizit definierte Kind-Applications über eine Root-Application und eignet sich für statische, bewusst gepflegte Setups wie das Cluster-Bootstrapping. ApplicationSet generiert Applications dynamisch aus einem Generator — etwa pro Cluster, pro Verzeichnis oder pro Pull Request. Faustregel: App-of-Apps für wenige, individuelle Applications; ApplicationSet, sobald viele gleichartige Applications automatisch entstehen sollen.
// Nächster Schritt

Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.

Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.

Erstgespräch buchen
Seit 2006 · 47+ Projekte
Industrie · Automotive · Finance