GitOps vs Infrastructure as Code

What is GitOps? Why it’s so popular? GitOps is nothing but doing “Infrastructure as Code” right. “Infrastructure as code” is creating infrastructure using code rather than creating it manually. As I mentioned in the previous article, IaC has been evolved over the period, as “Network as code”, “Security as Code”, “Policy as Code” etc. So now, we are calling it “Everything as Code” – “EaC” or “X as Code”. IaC has addressed some of the major pain areas, at the same time, it brings some new challenges. GitOps is born to address those challenges imposed by IaC.

Challenges on Infrastructure as Code:

Using the IaC process, we describe the complete infrastructure in code. This approach saves a lot of time for the deployment and re-deploying it in another environment. Most of these deployments will happen from the laptop or from the DevOps engineer’s user account on the jump servers. In some cases, these codes might be stored back in git repository for future use but there is no peer review or approval process involved.

Here are some of the example of the wrong way of doing “Infrastructure as Code”.

#1. Not using Git

#2. Using Git but not using in right way

1. No Collaboration
2. No pull requests / Merge requests
3. No code review
4. No automated Tests

#3 Accessing infrastructure directly to apply the changes #3

Most of the organization provides direct access to the engineers for creating and managing Kubernetes cluster, Azure, AWS and GCP cloud platforms. This makes it hard to trace who executed what.

GitOps – Doing “Infrastructure as Code” right

“GitOps” concept born in 2017 to treat “Infrastructure as code” the same way as “Application as Code”. GitOps eliminates the flaws of “IaC”. Here is the list of steps involved in GitOps.

Step: 1 – Store the code in dedicated “IaC” repository. This enables version control and improves collaboration.

Step:2 Use pull/merge request for collaboration and approval process. This brings an end to end automated process and more transparency on the deployment and management. Due to multiple reviews and testing, the quality of “IaC” improves a lot.

Step: 3 Continuous deployment model. In GitOps, there are two way to apply the changes to the infrastructure. This eliminates direct access to the infrastructure.

Push deployment

In push deployment, CI/CD servers trigger the job which applies the changes to the infrastructure. This can be done using git actions or manual triggers with the pipeline job.

Pull deployment

In Pull deployment mode, agents will be running on the source infrastructure which always looks for the desired state from the git repository. In Kubernetes, an agent will be installed on the Kubernetes cluster which regularly monitors the repository. This agent compares the desired state (Git repository) with the actual state (Kubernetes cluster environment) frequently. If there are any changes in the desired state, it pulls the configuration and applies it.

There are two major popular agents helps to do the pull deployment for kubernetes.

1. Argo CD
2. Flux CD

Summary:

• GitOps helps “Infrastructure as Code” quality by collaborating with multiple engineers, automated testing and approval process.
• It’s very easy to roll back the changes since the infrastructure is described in code and the source control system is in place. If any changes have broken your infrastructure, you can revert the changes to the previous commit which will restore your previous infrastructure state.
• In GitOps, Git repository becomes a single source of truth for everything.
• It brings consistency and standardization across the environment
• It improves stability and provides higher reliability since direct access to the platform will be revoked.
• It helps to increase productivity