GitOps and its workflow at a very high level
When I started working with Kubernetes, I used the ‘kubectl’ command line tool for all types of interaction with the Kubernetes cluster. Later, when I implemented CI/CD pipelines for Kubernetes deployment, again I used ‘kubectl’ tool from the CI/CD machine to access or apply changes in the cluster. But I was worried about the permissions provided to the CI runner machine in order to access the Kubernetes cluster. I was searching for a better method to deploy applications to the K8s cluster other than using kubectl from the CI/CD Runner machine. Then I came to know about GitOps practices and the usage of it using a GitOps tool called ArgoCD, and that was a lifesaver.
In this section, I’m just giving a high-level overview of GitOps and a sample workflow of how GitOps can be integrated with an existing workflow with CICD and Kubernetes cluster.
What is GitOps?
GitLab provides a good explanation of GitOps and that is:
GitOps is a branch of DevOps that focuses on using git repositories to manage infrastructure and application code deployments. The main difference between the two is that in GitOps, the git repository is the source of truth for the deployment state, while in DevOps, it is the application or server configuration files.
In other words, we can say “The entire code delivery process is controlled via the Git repository”.
The major use cases of GitOps are:
- Continuous Deployment of Applications
- Continuous Deployment of Cluster (Kubernetes) resources
- Continuous Deployment of Infrastructure
- Detecting or Avoiding configuration drift
- Multi-Cluster Deployment
DevOps vs GitOps
DevOps
One of the major components of DevOps practices/pipelines are Continuous Integration and Continuous Delivery/Deployment. In continuous integration, once the code is checked-in to the repository, the pipeline for continuous integration gets started. A sample Continuous Integration steps include:
- Unit testing and other Testing steps
- Building artifacts
- Build Container images
- Push the container image to a registry
Then comes the Continuous Delivery/Deployment part. In this part:
- CD pulls the image from the registry and updates the deployment
A pictorial representation of the workflow is given below:
GitOps
In the case of GitOps, apart from the DevOps workflow that we mentioned above, there are some additional components involved.
- Apart from the Application code repository, we require one more repository to store Kubernetes deployment manifest files (or Helm chart)
- A GitOps tool like ArgoCD needs to be implemented on the Kubernetes cluster. This tool is responsible for deploying the latest changes to the Kubernetes cluster.
So, in this workflow, instead of directly applying the deployment commands from the Continuous Deployment pipeline, we clone the repository that contains the Kubernetes deployment manifest files, then updates the manifest file with the latest application image and tag, and then push the changes back to the repository or create a Pull request. We can review the changes and then merge it. GitOps tools like ArgoCD will periodically check the repo and identifies the changes and then apply that in the Kubernetes cluster.
So, the overall steps are:
Continuous Integration
- Unit testing and other Testing steps
- Building artifacts
- Build Container images
- Push the container image to a registry
- Clone the repo that contains the Kubernetes manifest file
- Update the manifest files with the latest application image and tag
- Push to a feature branch and then create a Pull request
GitOps Deployment
- Approve the PR and merge the changes into the repository
- ArgoCD (GitOps tool) checks the repo and identifies the changes
- It then applies the changes to the Kubernetes cluster
A pictorial representation of the workflow is given below:
This way, we avoid the accessing the Kubernetes cluster directly from the CD pipeline.
Push vs Pull Approach
From these two types of workflow, we can see that the above DevOps workflow follows a “Push based approach” and GitOps workflow follows a “Pull based approach”. That is, in DevOps, we are “pushing” the changes from the continuous delivery pipeline to the Kubernetes Cluster. But in GitOps we only push the updated code in the Git repository and GitOps tools (like ArgoCD) are “pulling” those changes and updating the Kubernetes cluster.
GitOps tools
In order to implement GitOps practices, we need to use certain GitOps tools. Given below are some of the GitOps tools that we can use for these purposes.
For Kubernetes Deployment:
For Infrastructure/Terraform Deployment:
