Getting Started with ArgoCD

 

    In this article, we will learn how to use ArgoCD as continuous delivery tool in our workflow. It facilitates the adoption of GitOps, where teams leverage declarative configuration and infrastructure definitions from Git as the single source of truth.

What is ArgoCD?

ArgoCD is a Kubernetes-native continuous deployment (CD) tool. Unlike external CD tools that only enable push-based deployments, Argo CD can pull updated code from Git repositories and deploy it directly to Kubernetes resources. It enables developers to manage both infrastructure configuration and application updates in one system.

There are many features of ArgoCD :

1. Whole Kubernetes configuration defined as code in GIT Repository.

2. Web user interface and command-line interface (CLI).

3. It has easy rollback mechanism through which we can rollback our changes to any previous state.

4. It has cluster disaster recovery feature which helps to create the exact cluster if cluster dies because all codes are present in GIT.

5. It contains Kubernetes access control with GIT.

6. Single sign-on (SSO) with providers such as GitLab, GitHub, Microsoft, OAuth2, OIDC, LinkedIn, LDAP, and SAML 2.0

7. Support for webhooks triggering actions in GitLab, GitHub, and BitBucket.

8. Ability to visualize deployment issues, detect and remediate configuration drift.

What are the challenges which Jenkins have and ArgoCD solves ?

Challenges with this Approach ??

1. We need to install tools like kubectl on Jenkins.

2. Give access of Kubernetes cluster in Jenkins.

3. Configure access to cloud platform in Jenkins.

4. There is no visibility of deployment status in Jenkins.

CD Workflow using ArgoCD

1. A developer makes changes to an application, pushing a new version of Kubernetes resource definitions to a Git repo.

2. Continuous integration is triggered, resulting in a new container image saved to a registry.

3. A developer issues a pull request, changing Kubernetes manifests, which are created either manually or automatically.

4. The pull request is reviewed and changes are merged to the main branch. This triggers a webhook which tells Argo CD a change was made.

5. Argo CD clones the repo and compares the application state with the current state of the Kubernetes cluster. It applies the required changes to cluster configuration.

6. Kubernetes uses its controllers to reconcile the changes required to cluster resources, until it achieves the desired configuration.

7. Argo CD monitors progress and when the Kubernetes cluster is ready, reports that the application is in sync.

8. ArgoCD also works in the other direction, monitoring changes in the Kubernetes cluster and discarding them if they don’t match the current configuration in Git.

Installation of ArgoCD

$kubectl create namespace argocd

$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml 

We are using minikube for our short demo. Let’s check the pods and services which are created in argocd namespace.

To see the ArgoCD UI on our browser , we will do port forwarding of argocd-server service on 8080 port

$kubectl port-forward -n argocd svc/argocd-server 8080:446

Now, we can see the ArgoCD UI Page on localhost:8080

The initial password for the admin account is auto-generated and stored as clear text in the field password in a secret named argocd-initial-admin-secret in your Argo CD installation namespace. You can simply retrieve this password using

$ kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath=”{.data.password}” | base64 -d; echo

So the username is “admin” by default and password we retrieve it by the secret.

This is the UI page of ArgoCD after logging in

  Workflow of ArgoCD

This is the directory structure which we are following where a folder (dev) is containing all the manifest yaml files and an application.yaml file which is the Kubernetes resource object representing a deployed application instance in an environment. It has 2 fields where “source” references the desired state in Git and “destination” references to the target cluster and namespace. 

We have a simple Deployment file with “nginx” image and having 3 replicas, which we are going to use in our demo.

                     

This is the service yaml file for nginx .

This is the application CRD where kind is “Application” and namespace is “argocd” which tells that in the application that we are creating should be in argocd namespace where the argocd pods (controller , server ….etc) are running . The project field is “default”  Every application belong to a single project ( If not specified , it will assume it as default )

The source field references the Git Repository where all the manifest files will be uploaded , repoUrl  Put the url of the Git Repository and targetRevision = HEAD  It takes the last commit in the repository , path = Dev  which path in Git ,you want to sync your cluster with .

The destination field references the target cluster. In this we have a field as “server”  Specifies the endpoint of the Kubernetes API Server and “namespace”  Specifies which namespace you want your argocd to deploy your application to. 

The syncPolicy field  How to sync the desired state in the target cluster. Here , the field “CreateNamespace=True” ensures that the namespace specified exists in the destination and if not then it will create namespace

The automated “selfHeal=true” field  Cluster automatically sync with Git by ArgoCD which by default is set to off. “prune=true”  Automatically delete the component in Kubernetes cluster if your yaml files(CRD) are deleted from Git Repository.

After creating all manifest files, we will only one time run kubectl apply command . If in future as an example if we change “image” or “replica count” or add any configuration in our yaml files , we will directly do changes in Git and automatically the resources will create in your cluster.

$kubectl apply -f application.yaml

Let’s see the ArgoCD UI

We can see that in “myapp” namespace we have 1 service named “myapp-service” and 3 pods . The ArgoCD application is synced with the Git Repository.

If we click on the deployment “myapp” box we can see the manifest file and the summary details.

If we click on any of the pods, we can even see the logs of the pods, the events and even the summary.

We can even check the deployment and service resource in minikube cluster.

$kubectl get all -n myapp

Now, let’s manually change the deployment yaml file from the cluster configuration --> Changed replica count from 3 to 2.

It will discard the changes which we have done manually because ArgoCD follows Git as the single source of truth. So, what happens at the background is it checks the cluster desired with the actual state of Git and revert the changes.

Working with ArgoCD CLI

  Install the ArgoCD CLI by referencing the official doc : ArgoCD CLI Steps

  I have used package manager “brew” to install argocd cli

  $brew install argocd

 

First we need to login to the argocd cluster to run any of the commands.

Before login if we try any commands it will show error

For logging into cluster, run the below commands:

$argocd login <Url where argocd server is running> — insecure — username <put your username> — password <put your password>

After login you run many commands like :

$argocd cluster list  --> To check the cluster which ArgoCD is connected with

$argocd app list  --> To check all the running applications

$argocd repo list --> To check all Git or Helm repositories which ArgoCD is connected with

$argocd proj list  --> To list down all the projects created in ArgoCD

Let’s create an application by using ArgoCD CLI :

$argocd app create <application-name> — repo <repo-url> — path <path where yaml are present> — dest-namespace <namespace> — destination-server <Target Cluster Endpoint>

To sync with the Git Repository 

$argocd app sync <application-name>

We can see that the deployment and service resources are created in the cluster.

$argocd app get <application-name>

We can see that the application summary by this command.

To delete the application we will run the below command:

$argocd app delete <application-name> and then type “y”.

Using Kustomize to run ArgoCD

This is the directory structure we are following. To know more about kustomize refer my article on: Kustomize Fundamentals

In the application yaml we changed the namespace to “default” and path to “demo/overlays/dev” where environment specific kustomization yaml files are present.

This is the parent kustomization yaml file present in the bases folder

Where we have added a label “owner: Nandita” to use in our Kubernetes resources.

This is the environment specific kustomization yaml file where other fields are mentioned like namespace where the deployment pods and services will run and the nameprefix and nameSuffix properties

This is the basic nginx deployment yaml file

 

This is the basic nginx service yaml file

 

Next, we will deploy them and see all the resources are up and running in nginx-dev namespace

Let’s go to the ArgoCD UI and see the changes. We can see the nameprefix and namesuffix are added in name field.

Refer my Github Page if you want to refer my code : ArgoCD Application