Get the highlights in your inbox every week.
Get started with Argo CD | Opensource.com
Get started with Argo CD
Argo CD is a simple pull-based GitOps deployment tool that syncs Kubernetes manifest files with a cluster for easy, no-nonsense deployments.
In a typical push-based deployment, tools like Ansible and Jenkins connect directly to the server or cluster and execute the provisioning commands. This approach works well when the cluster is accessible on the network and there is direct connectivity between your deployment server and the destination server. For compliance or security reasons, connectivity between the deployment tool and the cluster may not be possible.
Argo CD is a pull-based deployment tool. It watches a remote Git repository for new or updated manifest files and synchronizes those changes with the cluster. By managing manifests in Git and syncing them with the cluster, you get all the advantages of a Git-based workflow (version control, pull-request reviews, transparency in collaboration, etc.) and a one-to-one mapping between what is in the Git repo and what is deployed in the cluster. This method is called GitOps.
In this tutorial, you will:
- Install Argo CD on a Minikube installation
- Create a sample Argo CD application called
ayush-test-applicationand link it with my repo
- Create an Nginx deployment with three replicas
- Ensure the new application shows up on the Argo CD dashboard and verify it using
Install Argo CD
This tutorial uses Minikube version v1.21.0. If you don't have it, download and install Minikube.
With Minikube up and running, you can install Argo CD. The Argo CD documentation contains detailed steps on how to install and configure it for any cluster. Once you've executed those steps, run
minikube tunnel in a separate terminal window to ensure Minikube exposes the Argo CD server's load balancer endpoint on your local system. To verify this, run
kubectl get po -n argocd and check if the
argo-server service has an
user@system ~ kubectl get svc -n argocd
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
argocd-dex-server ClusterIP 10.110.2.52 <none> 5556/TCP,5557/TCP,5558/TCP 3h32m
argocd-metrics ClusterIP 10.100.73.57 <none> 8082/TCP 3h32m
argocd-redis ClusterIP 10.104.11.24 <none> 6379/TCP 3h32m
argocd-repo-server ClusterIP 10.100.132.53 <none> 8081/TCP,8084/TCP 3h32m
argocd-server LoadBalancer 10.98.182.198 10.98.182.198 80:32746/TCP,443:31353/TCP 3h32m
argocd-server-metrics ClusterIP 10.105.182.52 <none> 8083/TCP 3h32m
Once the installation is complete and the load balancer is working, the Argo CD user interface (UI) will be accessible at the
Create your first application
Before talking about Argo CD deployments, you need a Git repo with a Kubernetes (k8s) manifest file ready to deploy. I'm using my public repo
example-assets with an Nginx deployment manifest file in
The goal is to get Argo CD to listen to the k8s manifest file for changes and then sync them with the cluster it is deployed in (in this case, Minikube). You do this by creating an application containing information about the manifest files' source repo, destination cluster details, and synchronization policies.
New App on the top left to configure a new application. Since my destination Kubernetes server is the one Argo CD is installed on (Minikube), I left the server defaults as-is. These are the values I configured:
- Application name:
- Sync policy:
- Sync options:
prune: true; selfHeal: true
- Source repository URL:
- Source revision:
- Source path:
- Destination cluster URL:
- Destination namespace:
To make things easier, you can click
EDIT AS YAML on the top right and paste in:
Your configuration should look like this:
After saving the configuration, your application should show up as a card on the home page. Since you specified the sync policy as
Automated, your new application will begin syncing with the repo immediately.
Create the Nginx deployment
In this tutorial, the manifest file is a standard Nginx deployment with three replicas. Once
ayush-test-application completes syncing, Argo CD will display a nice graphical view of the deployment.
Verify the deployment using
kubectl get po:
NAME READY STATUS RESTARTS AGE
nginx-deployment-585449566-584cj 1/1 Running 0 5m
nginx-deployment-585449566-6qn2z 1/1 Running 0 5m
nginx-deployment-585449566-d9fm2 1/1 Running 0 5m
Argo CD's advantages
Argo CD is a relatively lightweight approach to k8s deployments. I'm especially fond of the one-to-one relationship between what's in the repo and what's in the cluster, making incident management a lot simpler.
Another big advantage is that since the Git repo contains everything Argo CD requires, you could delete the entire Argo CD installation and set things up from scratch. This means bringing up a second identical cluster with your entire workload deployed is now more feasible and practical in the event of a catastrophic outage.
A third big advantage is fewer open ports. Argo CD pulls changes from a remote Git repo, so there's no need to define firewall rules and virtual private cloud (VPC) peering connections to get your deployment servers to connect with your cluster, which is one less point of entry. This reduces the attack surface area for your development, quality assurance (QA), and production servers significantly.
Since the Git repo and branch name are configurable, you can get creative with deployment models. For example, you could have two different Argo CDs running on two different QA and production clusters listening to the same repo's branch. This guarantees that the same manifest file is deployed on both clusters, ensuring QA and production environments contain the same codebase. Also, a single Argo CD is capable of targeting multiple servers, meaning a hub-and-spoke deployment model is possible, where one master Argo CD orchestrates deployments across multiple development, QA, and production clusters in different regions or environments.
Get creative with Argo CD, and don't forget to share your experiments with others.