GitOps serves to make the process of development and operations more developer-centric. It applies DevOps practices with Git as a single source of truth for infrastructure automation and deployment, hence the name “Git Ops.”
But before getting deeper into what is GitOps, let us understand why there is a need for it in the first place.
Infrastructure as Code
Infrastructure as Code (IaC) is the process of defining your infrastructure as a code instead of creating it manually. It has now evolved into XaC, where X can be Network, Configurations, Policy, and even Security which can be defined in a Terraform, Ansible, or Kubernetes Manifest files
In simple words, IaC is the process of replacing the manual effort required for IT resource management and provisioning it with simple lines of code, saving a lot of time for the deployment and re-deployment of code in another environment.
But there are some problems we can face if IaC isn’t managed properly. Let’s see.
How is IaC done wrong?
Most deployments will happen from the laptop or the DevOps engineer’s user account on the jump servers. To manage our IaC files, we have to create and test our files on a local machine and execute them on a local computer. These codes can be stored in a Git repository for future use.
By creating a Git repository, we can make our IaC accessible to other team members for collaboration. Here we can encounter some problems like-
No pull requests. Any changes in the file are committed directly into the main branch. That means the committed have undergone no code reviews or automated testing.
Accessing infrastructure directly to make changes. Most of the organization provides direct access to the engineers for creating and managing Kubernetes cluster, Azure, AWS, and GCP cloud platforms. This makes the traceability for the execution really hard and compromises the security of the environment.
Untested config changes can get into the development environment where we have to test the errors manually and can apply the same changes for the staging and production environment.
So even though IaC with all of its advantages, the majority of the process is still manual and inefficient. And herein lies the power of GitOps.
What is GitOps?
GitOps treats IaC the same way as an application code. It allows us to store our IaC file in a Git repository with CI and CD pipelines for it. The core idea is that the repository essentially contains the declarative code of the production environment and an automated process to sync the state of the production environment with the desired state in the repository.
Let us understand how this works.
Complete GitOps Workflow
We can create a pull request the same way we do in an application code to make changes.
For these changes, we will have a CI pipeline that will validate the config changes.
The changes are then peer-reviewed and discussed after which they are approved.
After the changes are approved they will be merged in the main branch and through the CD pipeline deployed in the environment.
Thus the process becomes automated and transparent. The changes proposed and committed are much easier to trace back.
Deployments: Push vs Pull
The two strategies for deployment in GitOps are Push-based and Pull-based deployments. The type of deployment we select should actually resemble the desired infrastructure. Let’s get into what are the differences between these methods and the tools used for each.
The Push-based deployment strategy is implemented by popular CI/CD tools we know from the application pipeline such as Jenkins, CircleCI, or Travis CI. The application repository contains the application’s source code and the Kubernetes YAML files needed to deploy the app.
When the application code is changed or updated, the build pipeline gets triggered, which builds the container images and finally, the environment configuration repository is updated with a new deployment description.
Pull based Deployments
Here we have an agent installed in the environment (like a K8s cluster), which actively monitors and compares the state of the Infrastructure code from the repository with the state of the code in the environment.
If the agent notices any difference, it will pull those changes from the repository into the environment so that the current state of the environment converges towards the desired state in the repository.
Some of the tools that work with the pull-based model are ArgoCD which is a GitOps operator for Kubernetes with a web interface and Flux which is the GitOps Kubernetes operator made by the creators of GitOps — Weaveworks.
Continuous deployment automation with an integrated feedback control loop speeds up Mean Time to Deployment (MTTD). Changes are shipped faster by the team thereby increasing the development output by a considerable factor.
Version Control (Rollback/Rollforward)
When we use our IaC as an application repository, rollback/rollforward becomes simple. If the code of our environment is not in sync with the repository or if there are some misconfigurations, we can simply rollback to the previous state. We can undo any changes just by using git revert.
Thus using these DevOps best with Git as a single source of truth enables us to reduce the Mean Time to Recovery (MTTR).
This feature of GitOps brings a lot of value to big organizations. With everything stored on the Git version control, we can allow permission to specific people to authorship and key to the definition of the desired state There is no need to give direct access of the environment to the team members for the deployment because the CD pipeline does it for us.
Git’s strong correctness and security guarantees, backed by its strong cryptography enable us to track and manage changes.
So with GitOps, we can increase the process of development and deployment without actually compromising with security and compliance.
Having the knowledge of all these amazing benefits of GitOps, let us understand the technologies required to work with it!
Tools and Technologies for GitOps
The technologies to get started are-
A Git repository for version control.
A Git management tool with the ability to do a pull request or merge request like GitLab.
Container Orchestration tools like Kubernetes
Infrastructure provisioning tools like Terraform.
Configuration managers like Ansible.
Continuous Integration Tools like Jenkins.
With all its benefits GitOps is not devoid of challenges.
Adaptability is a big issue. Companies prefer working in a culture they are used to. Operation engineers may need to adopt a developer-centric approach to their work, which is a tough change. The technology is still new and needs to mature. GitOps is constantly evolving.
The net benefits industries have observed by working with GitOps are significant and the future that lies ahead is exciting!
Read more from us here: