While the features in ArgoCD are straightforward, some of the terminology gets muddied in the noise of git and services. This ArgoCD glossary will clear the haze surrounding these terms so you can use them correctly and consistently!
Quick Argo Overview
If you’re new to ArgoCD, a quick rundown looks like this:
- Create a Project representing a product
- Create Repositories so Argo can talk to your git instance
- Create Applications to deploy your services to Kubernetes
Seems straightforward enough, right? But there is more to unpack with each of these, and clearly there is collision with other things with the same name.
ArgoCD Resources
Project
The Project is a container for Applications. It configures what may be deployed, where resources can be deployed within the cluster, and the git sources available. See How to Configure an ArgoCD Project to learn more!
Repository
The Repository defines a git repository and credentials for reading from the repository. It is bound to a project so long as the project permits it. It is the pipeline between an Application and the source code.
Application
Applications refer to a Project in order to deploy resources. The Application monitors repositories for manifest changes, and applies changes to the Kubernetes cluster. It performs the “refresh” and “sync” activities, and captures and presents any errors found during these processes. ArgoCD also provides a nice visualization of the deployed resources for the application.
ApplicationSet
The ApplicationSet, aka AppSet, is a generator of applications. It monitors source code and identifies when it should create or modify Applications. There are several flavors of AppSets, including one for monitoring for merge requests and another watching the default branch of a GitLab repository.
The Merge Request generator, or Pull Request generator, monitors the git repository for PRs and supports deploying feature branch resources to the cluster. My preference is to leverage a label on the request so the deployment is on-demand.
ArgoCD Activities
Sync
When ArgoCD performs a sync, it applies the changes for the desired state (reflected in git) to the target, ie applying it to the Kubernetes cluster. Any issue or error occurring during the sync represents a failure to apply changes to the cluster.
Refresh
When ArgoCD performs a refresh, it compares the latest code in git with the current state deployed to a cluster. If there are changes, a sync is then performed to match the cluster to the desired state. Any issue or error occurring during the refresh represents a failure to read from the git repository.
Health Status
Applications have a status attributed to them. Here is a brief note for each:
Healthy– the resource is healthyProgressing– the resource is not healthy yet but still making progress and might be healthy soonDegraded– the resource is degradedSuspended– the resource is suspended and waiting for some external event to resume (e.g. suspended CronJob or paused Deployment)Unknown– the status for the resource is not known yetMissing– the resource is missing, likely not deployed
ArgoCD Glossary Summary
ArgoCD is continuing to grow, and the contributors are routinely adding new features. It is vital to understanding these basics as you delve deeper into utilizing ArgoCD to manage GitOps for you and your organization.