Argo CD: A Complete Guide to Features, Configurations and Options

Do you want to know the full potential of Argo CD?

You are in the right place!

I have been exploring and working on ArgoCD for client implementations for a while and in this blog, we will explore Argo CD and its core features you should know.

Stay with me until the end.

What is Argo CD?

Argo CD is a declarative, GitOps CD tool for Kubernetes, which helps you to manage applications using the Kubernetes deployment YAML file stored in the Git repository.

Argo CD uses the GitOps principle which means Argo CD continuously monitors the repository, detects the changes, and deploys the changes.

Argo CD uses a pull-based deployment, which means whenever a change is made to the deployment YAML file in the Github repository, argo cd detects, pulls, and automatically deploys the latest changes.

Argo CD Workflow

The following image shows the high level ArgoCD workflow.

Argo CD continuously monitors your Git repository for any changes in the configuration file, it automatically detects and updates or deploys according to the configuration file.

If it detects any changes in the configuration file, first, it compares the configuration file with the cluster, like if this configuration is part of an old deployment that needs an update or a new deployment configuration file.

If the configuration is part of the old deployment, Argo CD makes sure to keep deployment in sync with the updated configuration file or if it’s a new deployment configuration file it deploys resources.

Note: We can also configure webhook to Argo CD which will trigger the syncing process as soon as a change is made to the Git repository.

In summary, Argo CD deploys a new deployment if a new configuration is pushed to the Git repository, syncs the deployment according to the configuration changes, and deletes the deployment if the configuration file is removed from the Git repository.

Features of Argo CD

Let’s see about the core concepts of Argo CD.

GitOps:

GitOps is the process of storing the configurations of the applications as code in GitHub and when you want to deploy the application use the code in the repository to deploy and maintain it.

Argo CD is built using this concept, it monitors the Git repository, and if any changes are made to the configuration file in the repository Argo CD automatically deploys or updates the changes done to the configuration file.

Sync Policy:

Sync policy is like a set of instructions that tell how Argo CD should respond to the changes made in the Git repository and it has various options that you can enable according to your requirement.

Let’s see about the option in sync policy.

Automatic – Whenever a change is made in the Git repository, Argo CD automatically triggers deployment.

Manual – You have to trigger the deployment manually.

Prune Resources – Automatically removes resources that are no longer configured in the configuration file in the Git repository.

This option is only available when you use automatic deployment.

For example, assume your configuration file in Git which contains configurations for Nginx and a Java application.

Argo CD will deploy both Nginx and a Java application, if you remove the configuration for Nginx from the configuration file in Git, Argo CD will delete Nginx from the cluster.

Retry – You can add configuration settings when the sync fails, you can select automatic retry or manual retry.

Interesting right?

Ok! Let’s talk about multi-cluster support.

Multi-Cluster Support:

Argo CD also supports multiple clusters at the same time. With Argo CD, we can deploy and manage applications not only in the cluster where argocd is installed but also in other available clusters.

Argo CD does not have a limit to adding the number of clusters to it, but Argo CD should have the required resources for the number of clusters you add and the application you are going to deploy using Argo CD.

Without the required resources to manage every cluster added to it and the application it’s managing, Argo CD may crash or the performance of Argo CD may decrease.

This is because Argo CD acts as a central hub for every cluster. It has to send API calls to every available cluster continuously to keep them in sync and check their health which puts a heavy workload on argocd.

To add Kubernetes clusters to Argo CD, first you need to save the cluster details on kubeconfig and use argocd-cli to add the cluster using the cluster name specified in the kubeconfig file

After adding the cluster to Argo CD you can see the cluster in your Argo CD UI as shown below

Once you added the cluster to Argo CD, you can select between clusters in which you want to deploy an application while adding a NEW APP as shown below

Rollbacks:

In Argo CD, rollback is the process of reverting your application to the previous stable version when your newly updated version is not compatible.

You can roll back by selecting the Git commit of the stable version, Argo CD will delete the newly created one and revert to the previous stable version of the application.

Note: To use rollback, you should disable Auto-Sync of your application.

To rollback to the previous version, go to the application you want to rollback and select HISTORY AND ROLLBACK as shown below

Then press the three-dot on the version you want to rollback and click Rollback

Configuration Types:

Argo CD has configuration types such as Helm, Kustomize, Directory, and Plugin, these are the configuration types available on Argo CD as default.

The default configuration types that are present on argocd are shown below, you can see this option at the bottom when you are adding a new app.

Helm – We can deploy an application using argocd with the help of helm charts.

You have to specify the repository URL and the path of the helm chart, argocd will automatically show the values.yaml file in the UI itself.

With the help of helm, we can deploy complex deployment in a consistency by just changing the values from UI.

You can also use helm on the different environments but you cannot change the values on UI you need to create a value.yaml file for every environment and push it to Git to make the changes.

For example, if you need to deploy a complex application on three different environments, you can use the same helm chart while adding an app, you just have to make changes to the values.yaml file.

Directory – In this type, you have to add all the manifest files for every resource you need to deploy in a single directory of your repository.

Then you have to specify the URL and path of the directory while adding a new app, argocd will deploy every manifest file alphabetically from the directory you specified.

For example, you have added three manifest files deploy, secret, and configmap to a directory in your repository.

You have to specify the URL and path, argocd will deploy all three manifest files and make sure everything is deployed properly.

Plugin – Argo CD uses Config Management Plugins (CMP) to integrate external configuration tools other than the default configuration types present in argocd.

For example, if you want to get the secrets from AWS Secrets Manager, you can configure AWS Secrets Manager as a plugin on argocd.

Kustomize – Kustomize is a configuration tool on argocd that is present on argocd as default.

Kustomize helps to deploy applications using overlay and patching, which means without changing the actual manifest file you can change the values of the manifest file while deploying.

Kustomize has a strict directory structure, your directory is shown below as given below to use the Kutomize option on argocd

.
├── base
│   ├── configmap.yml
│   ├── java.yml
│   └── secret.yml
└── kustomization.yaml

For example, if you have two environments A and B, in A you need to deploy a stable container image, and in B you need to deploy a new container image for testing.

With the help of Kustomize, you can use the same manifest file for both deployments by just changing the values of the container image while deploying without making any changes on the actual manifest file.

Ways To Interact With Argo CD:

We can interact with Argo CD in three ways, they are UI, CLI, and API.

1. UI – UI gives you a visualization of your configuration and the status of your deployment. It’s easy for beginners, they can do every task by clicking.
2. CLI – With CLI you can increase the speed of scripting and automation. Also, you can view the status of your deployment, technically you can do every task in a single terminal.
3. API – API provides a programmatic interaction through REST API calls which means through scripts and codes without human interaction. With API we can integrate Argo CD with other tools.

Benefits of Using Argo CD

Following are the benefits of using Argo CD for your deployment needs.

1. Argo CD uses the GitOps principle that allows you to deploy and manage applications using Git as the source.
2. Argo CD can automatically detect and deploy changes made on the Git repository.
3. If the newly deployed version is not compatible, we can use Git to track the changes and roll back to the previous version.
4. With the help of ArgoCD, we can deploy and manage applications on multiple clusters.
5. Argo CD has both CLI and UI to communicate with the application.
6. Argo CD always keeps the application in sync with the configuration file in the Git repository.
7. Argo CD can validate the configuration file for errors before deployment.

Conclusion

In summary, Argo CD deploys and manages applications using the GitOps concept.

Not only deployment it also has the rollback function and always keeps monitoring Git repositories and clusters to keep them in sync.

I believe this blog gives you an understanding of Argo CD and its concepts.

Do you have plans to use Argo CD in your environment?

Let me know in the comments.