Hey Everyone 👋

What is GitOps ?

GitOps is a set of practices to manage applications and infrastructure using Git. It builds on the concept of Infrastructure as Code and uses Git repositories and CI/CD to ease the process of managing deployed applications and infrastructure.

GitOps basically comes into the picture when we are in the Continuous Deployment (CD) phase of the CI/CD pipeline. It synchronizes the live state of systems with the version-controlled state stored in Git repositories and promotes changes through Git while discouraging manual changes.

This lets us enjoy the features of version control, rollbacks, collaboration, etc. Git acts as the single source of truth and helps ensure teams can be consistent across environments, reduce human errors, and enforce security policies. This also helps in detecting manual changes, as any deviation from the Git state is automatically detected and corrected, creating a self-healing infrastructure.

CI/CD and GitOps workflow

Each project that follows the GitOps methodology requires a CI/CD pipeline to ensure smoother operation in large teams.

Step 1 → Define Infrastructure/Application State in Git

We store application code, helm charts, Kubernetes manifests, Terraform configurations, and other IaC tools' configurations in this repository, making it the single source of truth for the desired state.

Step 2 → Push Changes via Pull Requests (PRs)

A new CI/CD pipeline is triggered either automatically or manually by maintainers from this point.

Step 3 → CI initializes (Continuous Integration)

This is a crucial stage that tests whether your PR follows code guidelines and if tests are passing. This is helpful both to you and the maintainers who will be reviewing your PR.

There are popular tools for CI like Jenkins and GitHub Actions. CI basically checks if your PR is valid and performs tasks/tests in your git branch as set up by maintainers.

For example - Checking code formatting, building application artifacts, running tests (unit, integration, E2E, etc.), and pushing to a registry like Docker Hub, Harbor, etc. (Continuous Delivery)

Step 4 → PR merged with main branch

After CI validates your PR, it is merged into the repository. Every new commit means the deployed state is now older and needs to be synced with the latest repository state.

Step 5 → GitOps Operator Detects Changes

GitOps operators like ArgoCD and FluxCD continuously monitor the Git repository for changes and automatically deployed to the environment with the help of CD (Continuous Deployment) pipeline.

Step 6 → Synchronize Live State with Git

The GitOps operator compares the current state (git) with the live state of your environment (for example, Kubernetes cluster) and if there is a difference, the operator applies the git-defined changes to the environment.

ArgoCD Hands-On Demo

ArgoCD is configured directly into your Kubernetes cluster, and it extends the Kubernetes API with custom resource definitions. We define which Git repository should be synced with which Kubernetes cluster. We can do this with any Git repository and any Kubernetes cluster. It can be the cluster where ArgoCD is installed or any other cluster that ArgoCD is managing.

We usually deploy ArgoCD separately for each cluster environment, such as development, staging, and production. Each cluster can be configured with a single Git repository containing all the configurations.

Helm often plays a crucial role here for practicing GitOps for applications in Kubernetes, and we often provide its repository path as a configuration. Many open-source tools have their Helm charts repository available, which you can extend to use within your own environment.

For infrastructure, we use IaC tools and automate actions with ArgoCD.

Installing ArgoCD into a Kubernetes Cluster

I am using a KinD cluster in my local setup, but you can use anything such as Minikube or cloud providers like AWS, Azure, Civo, etc.

There are two primary methods for installing ArgoCD:

Using Manifest files →
ArgoCD provides its own official manifest files, which install all the necessary ArgoCD components, including the API server, controller, and UI. First, create a namespace and then apply the files in that namespace.

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

Using a Helm Chart →
This method providers more flexibility as you get to enjoy Helm features like upgrades, rollbacks etc

Firstly add the ArgoCD Helm repository:
```
  helm repo add argo https://argoproj.github.io/argo-helm
```
Then install it in your preferred namespace.
```
  helm install argocd-demo argo/argo-cd -n argo
```
After Installation, run
```
  kubectl get pods -n argo
```
The output should look something like this →

Access the ArgoCD UI:

Port-forwarding is the way you can connect to the API Server without exposing the service. Run the command :

kubectl port-forward svc/argocd-demo-server -n argo 8080:443

The UI can then be accessed using https://localhost:8080

To login in the UI, the initial password is set by argoCD and is placed as secret in your cluster with base64 encoding. Run the below command to get your decoded password.

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

You should get output like :

Create a new application

Click on + NEW APP button
You will see a menu. I am using argocd-example-apps provided by official argo project. I forked it to make changes in it for demonstration. Here are the values I have provided. Please change as per your choice

Sync the new application

After this, you will see the application in applications tab in the UI. Click on sync button and choose what to sync. I am syncing everything

After this, you will see the resources in your cluster. Check using kubectl.

Sync New Changes

Now ArgoCD constantly looks for changes in the provided git repository.
If I push some changes to that repository, I will again get an Out of sync status.

I can again click on the Sync button, review all changes using the diff button, and apply. The cluster will get updated again. You can see GitOps in action!

That's it from my side. Please leave comments if you have any doubts, and I will answer them. Subscribe to my newsletter !

Connect with me on LinkedIn | GitHub.

Thanks for reading :)

GitOps Explained: A Guide to Workflows and ArgoCD with Hands-on Demo

Table of contents