Pure GitOps: How to Create ArgoCD Applications without the UI
What are Declarative Deployments, and why use them?
Most people deploy ArgoCD applications using the UI. They click a few buttons, add details and press sync. While ArgoCD is a GitOps tool, this is a rather clickopsy approach to bootstrapping your GitOps.
To clarify, the YAML files you are deploying with Argo CD are always stored in Git. But the configuration file telling ArgoCD where to find those files can be defined in the UI (imperatively) or in Git itself (declaratively). In this tutorial, we will see the latter approach. We will deploy an ArgoCD Application Declaratively, using the pure GitOps approach.
When doing declarative ArgoCD Deployments, your Argo CD projects and applications will be defined as Kubernetes manifest files. Nothing will be defined in the ArgoCD UI.
We will have to get those configuration files into the cluster. Once they are in your cluster, the Argo CD controller will recognize them and begin the synchronization process.
Setting up Declarative Deployments with Argo CD
Let’s create an application in Argo CD that deploys a meme-generator application. It is a simple web app containing a Kubernetes Deployment and Service resource.
First, we will create an Argo CD Project. Then an Argo CD App inside that project. Finally, we will verify that our meme-generator web app was created.
Every Argo CD application must be deployed inside a project. Before creating our application, we’ll define the project itself using the AppProject Custom Resource Definition (CRD).
This is how the AppProject would look if you created it in the ArgoCD UI. (But obviously, we won’t use the UI. We will create an equivalent AppProject with declarative YAML.)
description: Example project used to demonstrate Declarative deployments in ArgoCD
- namespace: robustaargo
To deploy the project, run:
kubectl apply -f argoproject.yaml
Here is a detailed explanation of what each line in this file does
apiVersion - Source of the Argo CD CRD’s
kind - Type of Kubernetes object, in this case an Argo CD AppProject
metadata.name - Name of the project - used to filter apps in the UI
metadata.namespace - Namespace where ArgoCD itself is installed (not necessarily the namespace that applications will be installed to)
metadata.finalizers - Include this if you want apps and resources created under this project to be deleted when the project is deleted. Read more about finalizers here.
spec.description - Details about the project - can be used to document what this project is for.
sourceRepos - Can be useful for compliance purposes. Restrict deployment of manifests to specific repositories to ensure that only applications from this source are deployed into this project. In this case, '*', allows all repositories.
destination.namespace - Helps you organize your applications by only allowing manifests in this project to deploy to the robustaargo namespace.
destination.server - Cluster where the application needs to be deployed
Step 2: Creating an Argo CD Application YAML
Now we can create the actual Application in Argo CD.
This is how the Application would look if you created it in the Argo CD UI. (But again, we’re not doing that. We’re creating an equivalent Application with declarative YAML.)
All options in the Application YAMLfile are similar to what you would see in the UI.
Settings to configure Argo CD's behavior when your YAML files are out of sync. This is useful for automation of application deployment.
automated: # Automated sync with 5 retries each one with a 5sec delay.
prune: true # Specifies if resources should be pruned during auto-syncing (false by default).
selfHeal: true # Automatically try to fix any differences between the cluster's current state and the desired state defined in the Git repository (false by default).
allowEmpty: false # Allows deleting all application resources during automatic syncing (false by default).
More options to manage how your manifests are deployed during a sync.
- Validate=false # disables re source validation
- CreateNamespace=true # Ensures that namespace specified as the application destination exists
- PrunePropagationPolicy=foreground # Supported policies are background, foreground, and orphan.
- PruneLast=true # Prunes all the resources at once in the end
Useful to perform rollbacks to older versions. Higher numbers increase the storage used (not advised).
In this blog post we explored why Declarative deployments are needed. We learned how to create a project and application in Argo CD using Kubernetes manifest YAML files.