- The Wrong Way of Doing IAC
- Benefits of GitOps for IAC
In today's fast-paced tech world, efficiently handling infrastructure while maintaining stability and security can be a real challenge.
But what if I told you there's a way to make this process smoother and more collaborative?
GitOps a methodology that merges the power of version control, git workflows and automation with infra as code.
In this article, I will try to uncover how GitOps can revolutionize the way you handle infrastructure as a developer or operations professional.
Before we dive into gitops, we need to know the need behind it and why doing IAC in a way other than gitops is problematic!
Picture this : instead of the tedious and error-prone manual setup of a Kubernetes cluster, you are harnessing the power of Infrastructure as Code (IAC) to define the deployment environment as code with Terraform, Ansible configurations, and Kubernetes manifests as your tools of choice for example.
So you have a bunch of yaml files and other configuration files that describe your infrastructure, your plateform and it's configuration.
- Bad Practice n°1 :
Storing them on local machine and not in a git repo!
-> No team collaboration and code reviews!
- Bad Practice n°2 :
Storing the config files in a git repo where everyone on the team has access to it but no Review/Approval process!
-> No pull/merge requests -> Commiting directly to main branch
And by consequences no automated tests to test the code changes
-> Break something in the infrastructure or the app environment making it instable.
- Bad Practice n°3 :
Updating the infrastructure and the app environment manually!
-> Everyone on the team has access to infrastructure to apply changes from their local machines making it hard to trace who executed what and when.
-> Find mistakes only once applied.
So as you see even though we are taking advantage of describing infrastructure as code which already has alot of benefits, our process is still mostly manual and inefficient. And that's where the gitops concept comes into practice to treat Infrastructure As Code the same as Application Code
Let's start first by discussing why Git ?
First of all, Git provides robust version control capabilities, allowing you to track changes to your infrastructure code over time. This history is essential for collaboration and rollbacks.
Developers and operations professionals are already familiar with it, making it a convenient choice.
In a GitOps workflow, there is a dedicated Git repository for the Infrastructure as Code project, coupled with an associated DevOps pipeline. Let's break down the fundamental components of a typical GitOps workflow:
Establish a central Git repository that hold the Infrastructure as Code configuration files.
Create pull/merge requests to make changes and collaborate before pushing back to the main branch of the repository.
Trigger a CI pipeline to validate configuration files, and perform automated tests.
Review and approve the changes to ensure that the changes are well tested before being applied in an environment.
Trigger a CD pipeline for the continuous deployment of the infrastructure.
=> This approach will improve the quality of infrastructure and it's configuration where multiple people collaborate on the changes and things gets tested before applied.
Now we said that once the changes are merged into the main branch, they will be automatically applied to the infrastructure through the CD pipeline.
In gitops we have two ways to apply these changes :
- Pull Deployment
In this model there is an agent installed in the deployment environment like k8s cluster that is actively pulling the changes from the git repository itself.
The agent regulary monitors and compares desired state with actual state present in the environment where its running, if it sees that there is a difference it will pull and applies the changes to get the environment to the desired state defined in the repository.
Mostly applicable in the context of Kubernetes and containerized environments.
- Push Deployment
This is the traditional way that we know.
In this model we explicitly define jobs in the application CI/CD pipeline that will execute commands to update the infrastructure or deploy the new application version to the deployment environment
Now that we know that changes in the git repository are automatically synced with the deployment environment.
We can easily leverage the power of git in tracking the history of changes to rollback to any previous state by simply using git revert
In conclusion, Gitops is a powerful approach that brings together the principles of version control, git workflow and automation to make IAC or more generally xAC smoother, more stable and secure.