instruction: How do you implement GitOps workflows with ArgoCD and Kustomize?
output: Cluster Bootstrapping - Argo CD - Declarative GitOps CD for Kubernetes Skip to content Argo CD - Declarative GitOps CD for Kubernetes Cluster Bootstrapping Initializing search GitHub Argo CD - Declarative GitOps CD for Kubernetes GitHub Overview Understand The Basics Core Concepts Getting Started Operator Manual Operator Manual Overview Architectural Overview Installation Feature Maturity Argo CD Core Declarative Setup Applications in any namespace Ingress Configuration High Availability High Availability Overview Dynamic Cluster Distribution User Management User Management Overview Auth0 Microsoft Okta OneLogin Keycloak OpenUnison Google Zitadel Identity Center (AWS SSO) RBAC Configuration Security Security Overview Snyk Scans Verification of Argo CD Artifacts TLS configuration Cluster Management Cluster Bootstrapping Cluster Bootstrapping Table of contents App Of Apps Pattern Helm Example Cascading deletion Ignoring differences in child applications Secret Management Disaster Recovery Reconcile Optimization Git Webhook Configuration Resource Health Resource Actions Custom Tooling Custom Styles UI Customization Metrics Web-based Terminal Config Management Plugins Deep Links Notifications Notifications Overview Triggers Templates Functions Triggers and Templates Catalog Monitoring Subscriptions Troubleshooting Troubleshooting commands Troubleshooting errors Examples Notification Services Notification Services Alertmanager AWS SQS Email GitHub Google Chat Grafana Mattermost NewRelic Opsgenie Overview PagerDuty PagerDuty V2 Pushover Rocket.Chat Slack Teams Telegram Webex Teams Webhook Troubleshooting Tools ApplicationSet ApplicationSet Introduction Installations Use Cases Security How ApplicationSet controller interacts with Argo CD Generators Generators Generators List Generator Cluster Generator Git Generator Matrix Generator Merge Generator SCM Provider Generator Cluster Decision Resource Generator Pull Request Generator Post Selector all generators Plugin Generator Template fields Template fields Templates Go Template Controlling Resource Modification Application Pruning & Resource Deletion Progressive Syncs Git File Generator Globbing ApplicationSet Specification Reference ApplicationSet in any namespace Server Configuration Parameters Server Configuration Parameters argocd-server Command Reference argocd-application-controller Command Reference argocd-repo-server Command Reference argocd-dex Command Reference Additional configuration method Upgrading Upgrading Overview v2.14 to 3.0 v2.13 to 2.14 v2.12 to 2.13 v2.11 to 2.12 v2.10 to 2.11 v2.9 to 2.10 v2.8 to 2.9 v2.7 to 2.8 v2.6 to 2.7 v2.5 to 2.6 v2.4 to 2.5 v2.3 to 2.4 v2.2 to 2.3 v2.1 to 2.2 v2.0 to 2.1 v1.8 to 2.0 v1.7 to 1.8 v1.6 to 1.7 v1.5 to 1.6 v1.4 to 1.5 v1.3 to 1.4 v1.2 to 1.3 v1.1 to 1.2 v1.0 to 1.1 Project Specification Reference User Guide User Guide Overview Tools Kustomize Helm OCI Importing Argo CD go packages Jsonnet Directory Tool Detection Projects Private Repositories Plugins Multiple Sources for an Application GnuPG verification Automated Sync Policy Diffing Diffing Diff Strategies Diff Customization Orphaned Resources Monitoring Compare Options Sync Options Parameter Overrides Environment Variables Build Environment Tracking and Deployment Strategies Resource Tracking Resource hooks Selective Sync Sync Phases and Waves Sync Windows Sync Applications with Kubectl Skip Application Reconcile Generating Applications with ApplicationSet Automation from CI Pipelines App Deletion Best Practices Status Badge Add external URL Add extra Application info Notification subscriptions Annotations and Labels used by Argo CD Command Reference Application Specification Reference Developer Guide Developer Guide Overview Development Environment Development Cycle Submit Your PR Architecture Architecture Authentication and Authorization Component Architecture Code Contribution Guide Toolchain Guide MacOS users Release Process And Cadence Running Argo CD locally Debugging a local Argo CD instance Debugging a Remote ArgoCD Environment API Docs E2E Tests Managing Dependencies Continuous Integration (CI) Releasing Documentation Site Static Code Analysis Extensions Extensions UI Extensions Proxy Extensions Contribution FAQ Tilt Development FAQ Security Considerations Support Roadmap Releases ⧉ Blog ⧉ Table of contents App Of Apps Pattern Helm Example Cascading deletion Ignoring differences in child applications Cluster Bootstrapping &para; This guide is for operators who have already installed Argo CD, and have a new cluster and are looking to install many apps in that cluster. There's no one particular pattern to solve this problem, e.g. you could write a script to create your apps, or you could even manually create them. However, users of Argo CD tend to use the app of apps pattern . App of Apps is an admin-only tool The ability to create Applications in arbitrary Projects is an admin-level capability. Only admins should have push access to the parent Application's source repository. Admins should review pull requests to that repository, paying particular attention to the project field in each Application. Projects with access to the namespace in which Argo CD is installed effectively have admin-level privileges. App Of Apps Pattern &para; Declaratively specify one Argo CD app that consists only of other apps. Helm Example &para; This example shows how to use Helm to achieve this. You can, of course, use another tool if you like. A typical layout of your Git repository for this might be: ├── Chart.yaml ├── templates │ ├── guestbook.yaml │ ├── helm-dependency.yaml │ ├── helm-guestbook.yaml │ └── kustomize-guestbook.yaml └── values.yaml Chart.yaml is boiler-plate. templates contains one file for each child app, roughly: apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : guestbook namespace : argocd finalizers : - resources-finalizer.argocd.argoproj.io spec : destination : namespace : argocd server : {{ .Values.spec.destination.server }} project : default source : path : guestbook repoURL : https://github.com/argoproj/argocd-example-apps targetRevision : HEAD The sync policy to automated + prune, so that child apps are automatically created, synced, and deleted when the manifest is changed, but you may wish to disable this. I've also added the finalizer, which will ensure that your apps are deleted correctly. Fix the revision to a specific Git commit SHA to make sure that, even if the child apps repo changes, the app will only change when the parent app change that revision. Alternatively, you can set it to HEAD or a branch name. As you probably want to override the cluster server, this is a templated values. values.yaml contains the default values: spec : destination : server : https://kubernetes.default.svc Next, you need to create and sync your parent app, e.g. via the CLI: argocd app create apps \ --dest-namespace argocd \ --dest-server https://kubernetes.default.svc \ --repo https://github.com/argoproj/argocd-example-apps.git \ --path apps argocd app sync apps The parent app will appear as in-sync but the child apps will be out of sync: NOTE: You may want to modify this behavior to bootstrap your cluster in waves; see v1.8 upgrade notes for information on changing this. You can either sync via the UI, firstly filter by the correct label: Then select the "out of sync" apps and sync: Or, via the CLI: argocd app sync -l app.kubernetes.io/instance = apps View the example on GitHub . Cascading deletion &para; If you want to ensure that child-apps and all of their resources are deleted when the parent-app is deleted make sure to add the appropriate finalizer to your Application definition apiVersion : argoproj.io/v1alpha1 kind : Application metadata : name : guestbook namespace : argocd finalizers : - resources-finalizer.argocd.argoproj.io spec : ... Ignoring differences in child applications &para; To allow changes in child apps without triggering an out-of-sync status, or modification for debugging etc, the app of apps pattern works with diff customization . The example below shows how to ignore changes to syncPolicy and other common values. spec : ... syncPolicy : ... syncOptions : - RespectIgnoreDifferences=true ... ignoreDifferences : - group : &quot;*&quot; kind : &quot;Application&quot; namespace : &quot;*&quot; jsonPointers : # Allow manually disabling auto sync for apps, useful for debugging. - /spec/syncPolicy/automated # These are automatically updated on a regular basis. Not ignoring last applied configuration since it&#39;s used for computing diffs after normalization. - /metadata/annotations/argocd.argoproj.io~1refresh - /operation ... Previous Cluster Management Next Secret Management Made with Material for MkDocs