Argo CD has emerged as a leading tool for declarative GitOps continuous delivery on Kubernetes. Among its powerful features, the Git Generator stands out as a versatile mechanism within ApplicationSets. This article dives deep into the Git Generator, exploring its functionalities and how to leverage it for streamlined Kubernetes deployments.
Before we delve into the specifics of the Git Generator, let's briefly recap Argo CD and the GitOps methodology. Argo CD automates the deployment of applications to Kubernetes clusters based on the desired state defined in Git repositories. This GitOps approach ensures that the cluster state always matches the configurations stored in Git, providing auditability, version control, and simplified rollbacks.
The Git Generator is a core component of Argo CD's ApplicationSet controller. It dynamically generates Argo CD Applications based on the structure and content of a Git repository. This eliminates the need to manually define each application, especially when dealing with numerous microservices or environments. The Git Generator comes in two flavors:
The Git Directory Generator is particularly useful when your Git repository is organized with directories representing different applications, environments, or components.
How it Works:
repoURL and a path that specifies the directory to scan within the repository.Example:
Consider a repository with the following structure:
├── argo-workflows
│ ├── kustomization.yaml
│ └── namespace-install.yaml
└── prometheus-operator
├── Chart.yaml
├── README.md
├── requirements.yaml
└── values.yaml
To deploy the Argo Workflow controller and Prometheus Operator, you can define an ApplicationSet like this:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: cluster-addons
namespace: argocd
spec:
goTemplate: true
goTemplateOptions: ["missingkey=error"]
generators:
- git:
repoURL: https://github.com/argoproj/argo-cd.git
revision: HEAD
directories:
- path: applicationset/examples/git-generator-directory/cluster-addons/*
template:
metadata:
name: '{{.path.basename}}'
spec:
project: "my-project"
source:
repoURL: https://github.com/argoproj/argo-cd.git
targetRevision: HEAD
path: '{{.path.path}}'
destination:
server: https://kubernetes.default.svc
namespace: '{{.path.basename}}'
syncPolicy:
syncOptions:
- CreateNamespace=true
In this example, the directories field tells Argo CD to scan the applicationset/examples/git-generator-directory/cluster-addons/ directory for subdirectories. The template then uses the {{.path.basename}} parameter to name the Application and set the destination namespace based on the subdirectory name.
Key Parameters:
{{.path.path}}: The full path to the directory within the Git repository.{{index .path.segments n}}: Accesses individual segments of the directory path as an array.{{.path.basename}}: Extracts the rightmost path name (e.g., "prometheus-operator").{{.path.basenameNormalized}}: Similar to basename, but replaces unsupported characters with hyphens.The Git Directory Generator automatically excludes directories starting with a dot (e.g., .git). You can also explicitly exclude directories using the exclude option:
directories:
- path: applicationset/examples/git-generator-directory/excludes/cluster-addons/*
- path: applicationset/examples/git-generator-directory/excludes/cluster-addons/exclude-helm-guestbook
exclude: true
To deploy from the root of the Git repository, set the path to '*':
directories:
- path: '*'
- path: donotdeploy
exclude: true
This configuration deploys everything in the repository except the donotdeploy directory.
You can pass custom key-value pairs to the template using the values field:
directories:
- path: '*'
values:
cluster: '{{.path.basename}}'
template:
spec:
destination:
namespace: '{{.values.cluster}}'
In this case, the cluster value is dynamically set to the directory's basename and used to define the destination namespace.
The Git File Generator offers another approach, generating parameters based on the content of JSON or YAML files within the Git repository.
Example Scenario: Imagine you have a repository holding cluster configurations:
├── cluster-config
│ └── engineering
│ ├── dev
│ │ └── config.json
│ └── prod
│ └── config.json
Each config.json file contains specific settings for a respective environment. You can utilize the Git File Generator to create Argo CD Applications based on these configurations.
Webhook Configuration
To automatically trigger ApplicationSet updates on Git changes, configure a webhook in your Git provider. You may optionally configure ApplicationSet with a webhook secret for added security.
Repository Credentials for ApplicationSets
Properly configuring repository credentials is crucial for ApplicationSets to access private Git repositories. Refer to the Argo CD documentation for detailed instructions.
The Argo CD documentation emphasizes security best practices, especially when using templated project fields in ApplicationSets. Ensure that the source of truth is controlled by administrators and that pull requests require admin approval.
The choice between the Git Directory Generator and the Git File Generator depends on your repository structure and how you want to manage application definitions. If your repository is organized by directories, the Git Directory Generator is a natural fit. If you prefer defining configurations in files, the Git File Generator provides a more structured approach.
The Git Generator in Argo CD's ApplicationSet is a powerful tool for automating application deployments in Kubernetes. By leveraging the directory structure or file content of Git repositories, you can dynamically generate Argo CD Applications, simplifying management and promoting a true GitOps workflow. Understanding the nuances of each generator type and following security best practices will enable you to fully harness the power of Argo CD for your Kubernetes deployments.
