Argo-CD -- Overview Installation and configutation

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

All credits creator of this youtube video
https://www.youtube.com/watch?v=MeU5_k9ssrs&t=1450s

Nana

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

A gitops tool gaining popularity in the GitOps world.

Common CD setup

In most project the K8 Kubernetes manifestation tool is a continuation of the CI / CD tool jenkins. In most project jenkins manages the complete CI/CD .

However there is a couple of challenges to this approach. You may have to install those Build automation tools such as

1. kubectl
2. helm
3. Access credentials to kubernetes cluster.
on the jenkins server.
4. You also need to provide access to these tools
5. And if you are hosting your kubernetes cluster of EKS or AKS on AWS or Azure you may also have to configure the credentials of AWS to the jenkins.

And this is not only a configuration effort but also a security challenge . Because you need to give your cluster credentials to external services and tools . especially when we have 50 projects that deploy applications . Each project needs its own kubernetes credentials . So that it can only access that specific application cluster , same way and if we have 50 cluster we need to deploy it on all 50 cluster.

further more when jenkins deploys the deployment file it has no further visibility on the deployment status.

Once jenkins deploys the application into the kubernetes cluster it is unsure if the application is in a failing status or not. or if it running successfully or not.

Therefore the CD part of it while working with Kubernetes can be made more efficient .

And ArgoCD was build for this specific use case . To make continuous delivery to Kubernetes cluster more efficient . ArgoCD was purpose build for kubernetes with GitIOps principles.

ArgoCD reverses the workflow instead of using a push workflow , it used a pull workflow
where the an agent in the cluster which is the Argo CD pulls those changes and applies them there,

With ArgoCD : Argo CD reverese the flow instead of accessing the cluster from CI/CD tool

But generally in GitOps the Jenkins must be doing the CI testing and making the docker image available on the docker registry of any Organization registry.

Benefits of ArgoCD :

1. Full cluster transparency
2. Git being the single source of truth
3. unlike using kubectl or helm install used from a laptop which makes things untrackable>
4. Git allows you to track the change to the kubernetes cluster.
5. Gives history of changes
6.This gives teams to collaborate in the cluster

Another benefit of using Git for

7. gives us history of changes
8. Audit trail who changed what in the cluster
9. Easy Roll back

How do we configure ArgoCD

Basically we deploy argoCD in the same way as we do with Prometheus

It extends K8s APIs with Custom Resource Definitions
Main component of an Argo CD is an Application. And we can define this application CRD in kubernetes native yaml files.

Different pipelines for different environments.

We may still need the CI pipeline.

Argo CD is a replacement or CD tools for Kubernetes but for others you may still need other tools. ArgoCD is not the only CD tools for Kubernetes , there are many alternatives already there .

fluxCD uses the same GitOps principles. Now you understand all the concepts around ArgoCD

Demo Argo CD - Simple but realistic demo.

-- we will setup a fully automated CD pipeline for Kubernetes configuration changes

We have created three image version for this app

configuring the argo cd and telling that it is this Git repository that you need to use to sync the kubernetes cluster.

test our setup by updating the config files such as deplpoyment.yaml into the git repository and check how this works. And ArgoCD will pull and apply changes to the Kubernetes cluster .

We have an empty mini kube cluster nothing running on it.

Plus we have an application gitlab repository only the kubernetes manifest files for that application are hosted and inside that we have one dev folder

And we have out deployment and service file inside this.

Ignore the % at the last and use the rest of it as password.

Configure the Argo CD .

Let's write a configuation file for Argo CD to connect it to the Git Repository where the configuration files are hosted. And we are going to put that ArgoCD configuration to the configuration repository.

if the myapp -- namespace isnt present we want the argocd to create the namespace for us for that we use the

syncPolicy:

We want Argocd to sync any changes to the Git repository . By default it is turned off. if you change and update the Git Repository Argo doesnt automatically fetch that

Automate the reversal if some one manually updates the k8s cluster. If someone used kubectl to push

We can configure ArgoCD to undo or overright any manual changed to the cluster . So if i do

kubectl apply , Argocd will overright it an sync it with the cluster.

by default , automatic sync will not delete resources.

therefore if you

rename a component for example deployment.yaml or if we delete a service.yaml file , we also want ArgoCD to delete that component in the cluster as well.

there is going to "prune"

ArgoCD will check everything 3 minutes and pull and apply if it finds any changes made to the git repo.

alternatively

if you want your workflow to always synchronize and apply to your cluster as soon as something changes in the git repository . You can actually configure a webhook integration. Between you to Git repository and ArgoCD .

it is protection mechanism so that something doesn't get accidentally deleted.

In the same cluster you may have multiple such applications for different namespaces or different environments that you can create in Argo CD.

Now lets apply this configuration to configure ArgoCD with this logic . Lets goahead an do this with "kubectl apply"

This is ideally the only kubectl apply that i will have to do in this Project after this everything will be auto synchronized.

git add .

git commit

git push

Now argo cd does not know that the application file is there .

for that we need to apply this application

$ kubectl apply -f application.yaml

This can be viewed in the UI of ArgoCD.

Now we can test , by updating something in the git repo to check if they are syncing automatically .

We are going to deployment.yaml and update the image version.