Search for a command to run...
I am Kaiwalya Koparkar, founder of Geek Around Community, a GitHub Campus Expert, MLH Coach, Open-Source Advocate & DevRel. I work as a Program Manager/ Community Manager in several communities. I love to speak at sessions, workshops, meetups, and conferences. In the past year, I have won over 10+ hackathons and mentored/judged/participated in over 35+ global hackathons.
No comments yet. Be the first to comment.
You’ve faced mysterious slowdowns and downtime in your application. Logs are scattered, metrics are basic, and you’re still left guessing what parts of your code are failing. Observability solves this by bringing together traces, metrics, and logs in...
In this blog, I’ll take you through the complete journey of building a multi-container application that displays Kubernetes pod logs using a Go backend, a web frontend, and a dashboard built with Builder.io. The idea started small: fetch and display ...
Hello everyone! A while back I passed my first cloud certification in the first attempt. To be honest I was super nervous putting all my knowledge at an official test. But in the end, it played out well. In this blog, I will introduce you to the cert...
Hey everyone! Welcome back 👋. In this blog, we will see what is FluentD and why we actually need it. To start with simple information, Fluentd comes under the "Observability and Analysis" part of the cloud-native application cycle and is very helpfu...
📍 Presented at: DevRelCon Yokohama 2023
Hey everyone in this blog we will see what is ArgoCD and in what ways it helps to overcome the drawbacks of the regular CI/CD pipeline while working with Kubernetes deployment
ArgoCD is known as a declarative GitOps tool which is based on Kubernetes. Let's try to break this down. "GitOps" is a process where you take the code you have written and pushed to the Git registry (eg: GitHub, GitLab, Bitbucket) and take it to the deployment and this is mainly done and implemented as automation. The word "declarative" means that the deployment has exactly the same architecture that you want and have decided on. So if there was a case that something gets changed in the deployment then it will revert back to the previous state (the one which you have mentioned)
So whenever the application is pushed to the git repository, there are certain steps it goes through to reach the deployment. These steps are automated and known as CI/CD pipeline. So once the code changes are pushed they are tested, the image is built, pushed to the DockerHub or other registry, Manifest files are updated and finally through kubectl apply... it is applied to the Kubernetes cluster.
But in this case, we have to face and resolve challenges like:
Install and setup tools like kubectl
Configuring access to Kubernetes
Configuring access to could providers
Several security challenges
No visibility of deployment status
So in a general scenario the above-mentioned workflow is used, but while working with Kubernetes we might need to change this workflow. It is essential to know that according to the set best practice for the Git repository, we should have two separate repositories for Code files and application configuration (k8s manifests).
The main advantage is there can be a time we want to change only the config files but don't want the test -> to build etc workflow to run as the configs can be changed independently of the application built. Having this as a reference now ArgoCD (which is installed on your Kubernetes Cluster) keeps track of the state you mentioned in the configuration repositories.
So if were to use the earlier CI/CD pipeline then it would have been too complex to manage and configure. Once the application is built and up the changes are reflected in the configuration files. These changes are detected by ArgoCD and pulled into the cluster.
Note: ArgoCD works on the pull method and not like the usual push method
Git as a single source of truth:
This means that if any changes are to occur in the Kubernetes cluster then the git repository is a place to validate and check if everything is going as mentioned in the manifests and any instance that is out of instructions is rolled back.
Easy rollback:
This is a very essential feature of ArgoCD as it helps us to revert to the previous state if there was any problem or misconfiguration in the cluster.
Cluster disaster recovery:
This means if one of my servers were to go down then I can create another cluster with ArgoCD and point it to the same repository then the process for recovery becomes much more efficient and fast
K8s access control:
We can manage the cluster access directly through git so we don't have to worry about giving access to the cluster to an external tool.
ArgoCD is super easy to install and configure. We will be looking at it through an example. I will be using Minikube for my Kubernetes Cluster.
I will be using this repository for this demo purpose and you can use the same
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
application.yaml.apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: wmd-argo-application
namespace: argocd
spec:
project: default
source:
#Your repo link here
repoURL: https://github.com/kaiwalyakoparkar/practical-devops.git
targetRevision: HEAD
#Location where the manifests are stored
path: ArgoCD/dev
destination:
server: https://kubernetes.default.svc
namespace: wmd
syncPolicy:
syncOptions:
- CreateNamespace=true
automated:
selfHeal: true
prune: true
dev folder and place your deployment and service files into it like below. (Notice that it's the same path which I have mentioned in above application.yaml file.
deployment.yaml and service.yaml are already present on the repo so you can check them out there# You can give any name to your namespace and update respective files
kubectl create namespace wmd
application.yaml file to the cluster. We can do that using the kubectl apply command like belowkubectl apply -f application.yaml
kubectl port-forward svc/argocd-server 8080:443 -n argocd
and now you can go to http://localhost:8080 to access the ArgoCD dashboard
Username field enter admin and to generate a password run the following commands into the terminal kubectl get secret argocd-initial-admin-secret -n argocd -o yaml
and you will get output something like:
We are not done yet, copy the password in this case mine will be VktPYkNUZGZRcjlNVk1ibQ== now put this password into another command to decode it and obtain the real password. Run the following command to decode it
# Change after echo with your password
echo VktPYkNUZGZRcjlNVk1ibQ== | base64 --decode
Now copy the password that is obtained (Remember to omit % at the end of the password obtained) and put it into the ArgoCD dashboard
Click on the application name and you are able to see a beautiful map of your deployment
You can see every possible information about the cluster here including the health of the pod, cluster and service. ArgoCD pulls the changes every 3 minutes this can be changed using webhooks and other methods.
And done 🎉 you have successfully configured and implemented ArgoCD to your cluster now whenever you want to change anything in the deployment then you can directly change the manifest and push the code to git repository and changes will be reflected in ArgoCD automatically.
Like | Follow | Subscribe to the newsletter.
Catch me on my socials here: https://link.kaiwalyakoparkar.com