The manifests directory contains Kubernetes manifests that we will apply to the Kubernetes cluster. As we’re setting up Argo CD first, it only contains the argocd directory at the moment; however, we will extend this to add further directories later in this chapter.
The manifests/argocd directory contains the following files:
• namespace.yaml: The manifest to create the argocd namespace where Argo CD will run.
• install.yaml: The manifest to create the Argo CD application. The manifest is downloaded from the official Argo CD release URL.
• apps.yaml: This contains an Argo CDApplicationSet configuration.
While the namespace.yaml and install.yaml files are self-explanatory, let’s discuss the apps.yaml file and the Argo CD ApplicationSet resource in more detail.
Argo CD Application and ApplicationSet
To manage applications declaratively, Argo CD uses the Application resource. An Application resource defines the configuration required for Argo CD to access Kubernetes deployment configuration stored in the Git repository using the source attribute and where it needs to apply them using the target attribute. An Application resource caters to one application. For example, to deploy our Blog App, we will need to create an Application resource like the following:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: blog-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com//mdo-environments.git
targetRevision: HEAD
path: manifests/nginx
destination:
server: https://kubernetes.default.svc
syncPolicy:
automated:
selfHeal: true
This manifest defines anArgo CD Application resource with the following sections:
• project: We can organize applications into distinct projects. In this case, we will stick to the default project.
• source: This section defines the configuration Argo CD requires to track and pull the application configuration from the Git repository. It typically contains repoURL, targetRevision, and the path value where the application manifests are located.
• destination: This section defines thetarget value to which we want to apply the manifest. It typically contains the server section and contains the Kubernetes cluster’s URL.
• syncPolicy: This section defines any policies Argo CD should apply while syncing the Blog App from the Git repository and what to do when it detects a drift. In the preceding configuration, it would try to correct any drift from the Git repository automatically as selfHeal is set to true.
We can very well go ahead and define multiple application manifests for each application. However, for larger projects, it might turn out to be an overhead. To manage this, Argo CD provides a generic way of creating and managing applications via the ApplicationSet resource.
The ApplicationSet resource provides us with a way to dynamically generate Application resources by using a defined pattern. In our case, we have the following structure:
manifests
└── argocd
│ ├── apps.yaml
│ ├── install.yaml
│ └── namespace.yaml └── blog-app
│ └── manifest.yaml └──
└── manifest.yaml
So, logically, for every subdirectory of the manifests directory, we would need to create a new application with the directory name. The respective application configuration should source all manifests from the subdirectory.
We’ve defined the following ApplicationSet within the apps.yaml file:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: argo-apps
namespace: argocd
spec:
generators:
- git:
repoURL: https://github.com//mdo-environments.git
revision: HEAD
directories: - path: manifests/*
- path: manifests/argocd
exclude: true
template:
metadata:
name: ‘{{path.basename}}’
spec:
project: default
source:
repoURL: https://github.com//mdo-environments.git
targetRevision: HEAD
path: ‘{{path}}’
destination:
server: https://kubernetes.default.svc
syncPolicy:
automated:
selfHeal: true
ApplicationSet has the following sections:
• generators: This section defines how Argo CD should generate Application resources. We’ve used the git generator, which contains the repoURL, revision, and directories sections. The directories section defines the directory from where we would want to source our applications. We’ve set that to manifests/*. So, it will look for every subdirectory within the manifests directory. We have also defined an exclude directory called manifests/ argocd. This is because we don’t want Argo CD to manage the configuration to deploy itself.
• templates: This sectiondefines the template for creating the application. As we can see, the contents are very similar to an Application resource definition. For metadata.name, we specified {{path.basename}}, which means it will create Application resources with the subdirectory name as we intended. The template.spec.source.path attribute contains the source path of the corresponding application manifests, so we’ve set that to {{path}} – that is, the subdirectory. So, we will have blog-app and applications based on the preceding directory structure. The rest of the attributes are the same as those for the Application resource we discussed previously.
Now that we’ve configured everything we need to install and set up Argo CD, let’s commit and push this configuration to the remote repository by using the following commands:
$ git add –all
$ git commit -m “Added argocd configuration”
$ git push
We will see that GitHub will run the Actions workflow on update and deploy Argo CD. Once the workflow is successful, we can go ahead and access the Argo CD Web UI.
