App of Apps

App of Apps Pattern in ArgoCD

The App of Apps pattern in ArgoCD is a powerful method for managing multiple applications within a Kubernetes cluster. This pattern allows you to define a parent application (the "App of Apps") that references other child applications. This hierarchical structure simplifies the deployment and management of complex environments by organizing related applications together.

Creating an App of Apps Helm Chart

To create an App of Apps in Kuberise.io, a Helm chart is created that includes a set of applications to be deployed. This chart uses a templates to iterate over the applications specified in the values files.

Template Implementation

app-of-apps/templates/ArgocdApplications.yaml is the main template that defines the structure of the App of Apps Helm chart. This template is used to generate the ArgoCD applications that will be deployed on the Kubernetes cluster. There are three types of applications that can be defined in the App of Apps: helm, kustomize, and raw yaml and it is defined by the parameter type and the default value is helm.

Iterating Over ArgoCD Applications

The template iterates over the ArgoCD applications defined in all values files in app-of-apps and app-of-apps/tools folders using the range function. For each application, it checks if the application is enabled and then generates the necessary configuration based on the type of the application.

Helm charts

ArgocdApplications:
  kube-prometheus-stack:
    enabled: false
    repoURL: https://prometheus-community.github.io/helm-charts
    namespace: monitoring
    targetRevision: 56.7.0
    chart: kube-prometheus-stack
    syncWave: 0
    type: helm

The name of the application is used as the key, and the configuration is defined as a nested object:

• kube-prometheus-stack is the name of the application.
• enabled specifies whether the application is enabled or not. You can disable all applications and helm charts at the definition yaml file then enable the ones you want to deploy for each platform values file to override the default values.
• repoURL is the URL of the Helm repository. The default value is .Values.global.spec.source.repoURL
• namespace is the namespace where the application will be deployed. The default value is the name of the application. In this example, the application will be deployed in the monitoring namespace. If you don't specify a namespace, the application will be deployed in kube-prometheus-stack namespace.
• targetRevision is the version of the Helm chart to deploy. The default value is .Values.global.spec.source.targetRevision. It can be a specific branch name or a tag of your repository as well.
• chart is the name of the Helm chart to deploy. You should use this key if you are deploying from a helm chart repository. Otherwise you have to use path key.
• path is the path of a Helm chart source code in a repository. You should use this key if you are deploying from a Helm chart source code. If you don't specify a path or chart key, the Helm chart will be deployed from the repoURL repository and from the template/{name} path.
• syncWave is the wave number of the application. The default value is 0. You can use this key to deploy applications in a specific order. You can read more details in ArgoCD documentation.
• type is the type of the application. The default value is helm. You can use this key to specify the type of the application. The possible values are helm, kustomize, and raw.

Kustomize and Raw yaml files

The name of the application is used as the key, and the configuration is defined as a nested object:

ArgocdApplications:
  cnpg-database:
    enabled: false
    namespace: cloudnative-pg
    path: values/onprem/platform/database
    type: raw

ArgocdApplications:
  hello:
    enabled: false
    type: kustomize

The name of the application is used as the key, and the configuration is defined as a nested object:

• cnpg-database and hello are the name of the application.
• enabled specifies whether the application is enabled or not. You can disable all applications in defining values file then enable the ones you want to deploy for each platform values file to override the default values.
• namespace is the namespace where the application will be deployed. The default value is the name of the application. In this example, the application will be deployed in the cloudnative-pg namespace. If you don't specify a namespace, the application will be deployed in cnpg-database namespace.
• repoURL is the URL of the repository. The default value is .Values.global.spec.source.repoURL
• path is the path of the Kustomize application or raw yaml source code in the repository. If you don't specify a path key, the Kustomize application or raw yamls will be deployed from the template/{name} path.
• type is the type of the application. The default value is helm. You can use this key to specify the type of the application. The possible values are helm, kustomize, and raw.

Global Values

Global values are the values that are shared between all applications. You can define the global values in the app-of-apps/tools/main.yaml file and override them in the platform-specific values files.

global:
  platformName: x
  domain: x
  automated: true
  spec:
    destination:
      server: https://kubernetes.default.svc
    source:
      repoURL: x
      targetRevision: x
    values:
      repoURL: x
      targetRevision: x

Most of the values are filled by the install.sh script. You can override the values in the platform-specific values files.

• platformName is the name of the platform. You should use this key to define the platform name. a app-of-apps/values-platformName.yaml file should be created for each platform. Also a values/platformName folder should be created for all configurations.
• domain is the domain for the cluster. All platform services and applications will be subdomains of this domain (e.g., keycloak.[DOMAIN]).
• automated is a boolean value that specifies whether the installation is automated or not. The default value is true. If you set this value to false, the installation will be paused after the ArgoCD application is created. You can resume the installation by clicking the Sync button in the ArgoCD UI.
• spec is the specification of the ArgoCD application. You can define the destination server, source repository, and values repository in this key. The default values are filled by the install.sh script. You can override the values in the platform-specific values files.
• destination.server is the destination server that ArgoCD deploys all application to. The default value is https://kubernetes.default.svc which means the same cluster that ArgoCD has been deployed. You can change it if you want to deploy an application to another cluster.
• source.repoURL is the URL of the repository that contains the applications to be deployed. The default value is the repository URL that you provide in the install.sh script. This is used as the default value for all applications. Each application can override this value by specifying its own repoURL.
• source.targetRevision is the branch, commit SHA, or tag you want to use for this installation. The default value is the revision that you provide in the install.sh script. This is used as the default value for all applications. Each application can override this value by specifying its own targetRevision.
• values.repoURL is the URL of the repository that contains the values files for the applications. The default value is the repository URL that you provide in the install.sh script. This is used as the default value for all applications. Each application can override this value by specifying its own repoURL. In most cases, the values are in the same repository as the templates, but in some use cases, you might want to separate the values from the templates repository.
• values.targetRevision is the branch, commit SHA, or tag you want to use for the values repository. The default value is the revision that you provide in the install.sh script. This is used as the default value for all applications. Each application can override this value by specifying its own targetRevision.

App-of-Apps Values Files

The default list of platform tools are defined in different value files in app-of-apps/tools folder and the default list of applications are defined in app-of-apps/values.yaml file and all of them will merge together. This list can be overridden by a platform-specific values file, such as values-platformName.yaml. This allows for customization and flexibility in different environments.

For example you can add ingress-nginx to the platform by adding the following code to the app-of-apps/tools/network.yaml file:

ArgocdApplications:
  ingress-nginx:
    enabled: false
    repoURL: https://kubernetes.github.io/ingress-nginx
    targetRevision: 4.10.1
    chart: ingress-nginx

Then you can enable the ingress-nginx for the onprem platform by adding the following code to the values-onprem.yaml file:

ArgocdApplications:
  ingress-nginx:
    enabled: true

By following this structure, you can efficiently manage and deploy multiple applications using the App of Apps pattern in ArgoCD.