What is ArgoCD
ArgoCD is a Continuous Delivery (CD) tool for Kubernetes, which applies manifests stored in Git repositories or Helm charts to Kubernetes clusters. Built on the GitOps model, ArgoCD uses the source repositories as the source of truth; this means that manifests and charts pulled from source repositories represent the true intended state. The GitOps model also means that the source control platform tracks changes to the desired state.
ArgoCD ensures configuration consistency through detection and remediation of drift between the clusters current state and the desired state. Maintaining configuration consistency helps to reduce operational effort and improve security across the environment.
Installing ArgoCD is well described in the documentation and straightforward. The documentation uses a command which applies the installation manifest directly from a GitHub link; this is ok in a lab environment but not a good practice in a real Kubernetes environment.
You can configure ArgoCD before deployment by editing the install manifest, or for post-deployment configuration changes, edit ArgoCD Kubernetes objects.
ArgoCD Kubernetes Objects
ArgoCD configuration settings are stored in several Kubernetes objects within the namespace that ArgoCD is deployed.
|File Name||Resource Name||Kind||Description|
||argocd-cm||ConfigMap||General Argo CD configuration|
||argocd-secret||Secret||Password, Certificates, Signing Key|
||argocd-tls-certs-cm||ConfigMap||Custom TLS certificates for connecting Git repositories via HTTPS (v1.2 and later)|
||argocd-ssh-known-hosts-cm||ConfigMap||SSH known hosts data for connecting Git repositories via SSH (v1.2 and later)|
||-||Application||Example application spec|
||-||AppProject||Example project spec|
The ArgoCD web UI is very clean and provides some good information status information and limited configuration options. The
argocd-util command-line interfaces are far more powerful than the web UI for managing ArgoCD. You can also manage ArgoCD using the Kubernetes resources listed in the table above.
ArgoCDs' ability to manage multiple Kubernetes clusters and revision targetting provides topology and multi-cluster management flexibility. You might choose to deploy ArgoCD on a single cluster, perhaps a dedicated management cluster, to provide a centralized cluster management service. ArgoCD automatically registers the cluster it’s deployed on during the installation process.
Or you could deploy an instance of ArgoCD on each cluster, managing only the cluster that it’s running on, creating a decentralized management solution.
Clusters are added to ArgoCD using the command line utility; there is no option in the web UI. The below example uses credentials from ~/.kube/config for initial authentication. ArgoCD adds a service account to the cluster for future authentication.
Projects are a logical construct to control application deployment and permissions to the resources of the application.
- Restrict source repositories
- Deployment destinations, clusters and namespaces
- What objects can be deployed
- Configuration application RBAC
Configuration of projects can be done in several ways:
- The ArgoCD web UI
- Configuring the
- Using the ArgoCD command-line utility
Applications contain the source repository to pull manifests or charts from, the target cluster and namespace and synchronization policies. Configuring applications is how you provide ArgoCD with the required information to apply the desired configuration and detect and remediate drift.
You can manage applications using several different methods:
- The ArgoCD web UI
applications.argoproj.ioKubernetes custom resource
- The ArgoCD command-line utility
An application can only use one source repository, one project and one deployment target.
Deploying an Application
I had trouble with synchronization failures while writing this post because ArgoCD was trying to create resources such as deployments and services accounts before namespaces and CRDS. I found that I needed to update the manifests by adding resource hooks to control the order in which ArgoCD created the resources.
Make sure you read the documentation on resource hooks when learning ArgoCD. Resource Hooks.
The first application deploys the Operator Lifecycle Manager, and the second application deploys the OpenShift Compliance Operator.
prune option means that ArgoCD will remove resources from the cluster if they no longer exist in the manifests.
selfHeal option tells ArgoCD to remediate configuration drift back to the desired state automatically.
Operator LifeCycle Manager
OpenShift Compliance Operator
The web interface provides a nice topology of our application’s resources.
In my opinion, removing the ability for operators to make changes directly is a crucial step to increasing configuration consistency (in any sized environment). Using CD tools such as ArgoCD ensures that all changes have passed through a validation process before implementation. The CI/CD process reduces the need for operators to make changes manually to a cluster.
ArgoCD appears to have all the features required to simplify multi-cluster management and a low barrier to entry. Other than getting caught out by resource hooks, I found ArgoCD easy to get running, and overall, the operational process of the platform makes sense.
Future posts will go into further detail about using ArgoCD and other solutions from Argo.