github.com/argoproj/argo-cd/v3@v3.2.1/docs/operator-manual/cluster-bootstrapping.md (about)

     1  # Cluster Bootstrapping
     2  
     3  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.
     4  
     5  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**.
     6  
     7  !!!warning "App of Apps is an admin-only tool"
     8      The ability to create Applications in arbitrary [Projects](./declarative-setup.md#projects) 
     9      is an admin-level capability. Only admins should have push access to the parent Application's source repository. 
    10      Admins should review pull requests to that repository, paying particular attention to the `project` field in each 
    11      Application. Projects with access to the namespace in which Argo CD is installed effectively have admin-level 
    12      privileges.
    13  
    14  ## App Of Apps Pattern
    15  
    16  [Declaratively](declarative-setup.md) specify one Argo CD app that consists only of other apps.
    17  
    18  ![Application of Applications](../assets/application-of-applications.png)
    19  
    20  ### Helm Example
    21  
    22  This example shows how to use Helm to achieve this. You can, of course, use another tool if you like.
    23  
    24  A typical layout of your Git repository for this might be:
    25  
    26  ```
    27  ├── Chart.yaml
    28  ├── templates
    29  │   ├── guestbook.yaml
    30  │   ├── helm-dependency.yaml
    31  │   ├── helm-guestbook.yaml
    32  │   └── kustomize-guestbook.yaml
    33  └── values.yaml
    34  ```
    35  
    36  `Chart.yaml` is boiler-plate.
    37  
    38  `templates` contains one file for each child app, roughly:
    39  
    40  ```yaml
    41  apiVersion: argoproj.io/v1alpha1
    42  kind: Application
    43  metadata:
    44    name: guestbook
    45    namespace: argocd
    46    finalizers:
    47    - resources-finalizer.argocd.argoproj.io
    48  spec:
    49    destination:
    50      namespace: argocd
    51      server: {{ .Values.spec.destination.server }}
    52    project: default
    53    source:
    54      path: guestbook
    55      repoURL: https://github.com/argoproj/argocd-example-apps
    56      targetRevision: HEAD
    57  ``` 
    58  
    59  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.
    60  
    61  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.
    62  
    63  As you probably want to override the cluster server, this is a templated values.
    64  
    65  `values.yaml` contains the default values:
    66  
    67  ```yaml
    68  spec:
    69    destination:
    70      server: https://kubernetes.default.svc
    71  ```
    72  
    73  Next, you need to create and sync your parent app, e.g. via the CLI:
    74  
    75  ```bash
    76  argocd app create apps \
    77      --dest-namespace argocd \
    78      --dest-server https://kubernetes.default.svc \
    79      --repo https://github.com/argoproj/argocd-example-apps.git \
    80      --path apps  
    81  argocd app sync apps  
    82  ```
    83  
    84  The parent app will appear as in-sync but the child apps will be out of sync:
    85  
    86  ![New App Of Apps](../assets/new-app-of-apps.png)
    87  
    88  > NOTE: You may want to modify this behavior to bootstrap your cluster in waves; see [v1.8 upgrade notes](upgrading/1.7-1.8.md) for information on changing this.
    89  
    90  You can either sync via the UI, firstly filter by the correct label:
    91  
    92  ![Filter Apps](../assets/filter-apps.png)
    93  
    94  Then select the "out of sync" apps and sync: 
    95  
    96  ![Sync Apps](../assets/sync-apps.png)
    97  
    98  Or, via the CLI: 
    99  
   100  ```bash
   101  argocd app sync -l app.kubernetes.io/instance=apps
   102  ```
   103  
   104  View [the example on GitHub](https://github.com/argoproj/argocd-example-apps/tree/master/apps).
   105  
   106  
   107  
   108  ### Cascading deletion
   109  
   110  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](../user-guide/app_deletion.md#about-the-deletion-finalizer) to your `Application` definition
   111  
   112  ```yaml
   113  apiVersion: argoproj.io/v1alpha1
   114  kind: Application
   115  metadata:
   116    name: guestbook
   117    namespace: argocd
   118    finalizers:
   119    - resources-finalizer.argocd.argoproj.io
   120  spec:
   121   ...
   122  ```
   123  
   124  ### Deleting child applications
   125  
   126  When working with the App of Apps pattern, you may need to delete individual child applications. Starting in 3.2, Argo CD provides consistent deletion behaviour whether you delete from the Applications List or from the parent application's Resource Tree.
   127  
   128  For detailed information about deletion options and behaviour, including:
   129  - Consistent deletion across UI views
   130  - Non-cascading (orphan) deletion to preserve managed resources
   131  - Child application detection and improved dialog messages
   132  - Best practices and example scenarios
   133  
   134  See [Deleting Applications in the UI](../user-guide/app_deletion.md#deleting-applications-in-the-ui).
   135  
   136  ### Ignoring differences in child applications
   137  
   138  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](../user-guide/diffing/). The example below shows how to ignore changes to syncPolicy and other common values.
   139  
   140  ```yaml
   141  spec:
   142    ...
   143    syncPolicy:
   144      ...
   145      syncOptions:
   146        - RespectIgnoreDifferences=true
   147      ...
   148    ignoreDifferences:
   149      - group: "*"
   150        kind: "Application"
   151        jsonPointers:
   152          # Allow manually disabling auto sync for apps, useful for debugging.
   153          - /spec/syncPolicy/automated
   154          # These are automatically updated on a regular basis. Not ignoring last applied configuration since it's used for computing diffs after normalization.
   155          - /metadata/annotations/argocd.argoproj.io~1refresh
   156          - /operation
   157    ...
   158  ```