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




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 fieldHow 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 








Location: India

Comments

Post a Comment

Popular posts from this blog

Overview of Ansible and Ansible Playbooks

Image
In this article, you will get a brief idea about ansible, ansible playbooks, roles and how to use include module in your playbooks and we will be showing how to automate the process of creating a small application using database – mysql and webserver – flask by using ansible playbooks.   Why Do We Need Ansible? Ansible is an open source IT Configuration Management, Deployment & Orchestration tool. It aims to provide large productivity gains to a wide variety of automation challenges. This tool is very simple to use yet powerful enough to automate complex multi-tier IT application environments. It models your IT infrastructure by describing how all of your systems inter-relate, rather than just managing one system at a time.   For an example : Assume that if you want to install some software in a large number of servers , you will not install those softwares one by one into the server right ….. It will take a hell lot of time !! .     Advantages of using Ansible     1.   Execute tas
Read more

Integration of InfluxDB2 with Grafana

Image
  Integration of InfluxDB2 with Grafana What is InfluxDB? InfluxDB is an open-source schema-less Time-series database that specializes in the storage of time-series data for operations monitoring, application metrics, IoT sensors, and real-time analytics. InfluxQL i s an SQL-like query language for interacting with data in InfluxDB. It is a push-based database which means it can’t collect your data and you need to push to it. Telegraf  : It is a plugin-driven server agent for collecting and sending metrics and events from databases, systems, and IoT sensors. Its purpose is to collect data from the given data sources and push it to InfluxDB. It has a lot of plugins which helps in collecting data from multiple sources and write to multiple targets. InfluxDB2 Installation Manual Download (Ubuntu): (Method 1) Step 1: Prerequisites a) You should have a running Ubuntu 20.04 LTS Server. b) You should have sudo or root access to run privileged commands. c) You should have apt or apt-get utilit
Read more