An Introduction to GitOps

GitOps is a modern approach to managing and deploying applications and infrastructure in a declarative and version-controlled manner using Git. It leverages the principles of DevOps, infrastructure as code (IaC), and continuous delivery (CD) to streamline and automate the deployment process. Being built on Git, engineers already know how to use it and they have the tools pre installed on their workstations.

The key concepts of GitOps are:

1. Declarative - A system managed by GitOps must have its desired state expressed declaratively e.g. Infrastructure as code.
2. Versioned and Immutable - Desired state is stored in a way that enforces immutability, versioning and retains a complete version history e.g. Git
3. Pulled Automatically - Software agents automatically pull the desired state declarations from the source.
4. Continuously Reconciled - Software agents continuously observe the actual state and attempt to apply the desired state.

But, is GitOps all about having a software agent that continuously observes and reconciles the current state with the desired state? No, GitOps is a methodology, a culture that promotes the separation of source code and infra configuration.

Interesting fact: GitOps does not have to use Git. Other source control repositories could be used. However, Git is the standard.

Let’s look at a simple example of GitOps in action for performing a routine task. A Kubernetes deployment requires a slight tweak to increase its CPU allocation.

1. The deployment is declared in a YAML file which is stored in a Git repository.
2. An engineer uses regular Git workflows to modify the file to make the required change.
3. When the change is pushed back into Git a new version of that file is created while the old version is still retained.
4. Before the new version is merged into the main branch it is peer reviewed and approved.
5. An audit trail of who submitted the change and who approved it is all part of the version history tracked in Git.
6. Once the change is approved and merged into the main branch, the GitOps agent running inside the Kubernetes cluster pulls the new version. It then analyses the difference between the current running state of the deployment and the new desired state declared in the new version. It then performs the required action to reconcile any differences.

Now, the change is live and the Kubernetes deployment has the extra CPU resource. This is a classic example of the traditional GitOps workflow. To adopt GitOps practices, does it always need to be an approval flow manually done from the git? No, the changes don’t always have to be pushed through git. Any system, that ensures the changes are committed to git in a separate repo from the source code does allow you to have GitOps practices right away.

Benefits of GitOps

• Ease of adoption by engineering staff, they already use Git in their day to day tasks. With GitOps nothing changes, they continue to use a tool they are already very familiar with.
• Version Control and Audit Trail - Because all changes are tracked in Git, there is a complete history of all modifications, who made them and who approved them. Since the full history is available, it is easy to roll back any changes to the last known good configuration if required.
• Consistency and Reliability - Git becomes the single source of truth which ensures that all environments are consistent therefore eliminating configuration drift and increasing reliability.
• Enhanced Collaboration - Multiple engineers across different teams and locations can collaborate effectively using Git issues, branches and pull requests together with code review and approval. This is what they are already doing for language source code.
• Improved Security - Because all changes made to any environment go through GitOps they are reviewed and approved with a full audit trail. The GitOps software agent actions the change therefore the number of engineers that require direct access to any environment is significantly reduced making user management simpler as well as decreasing the risk of access keys leaking.
• Scalability - GitOps can scale across multiple environments, cloud platforms and clusters, making it suitable for managing complex highly distributed systems.

GitOps vs CI/CD

GitOps is not an alternative to CI/CD, it enhances it by being the final step in a CI/CD pipeline. Using Kubernetes as an example, typically the final step in a CI/CD pipeline is calling kubectl to update a deployment then the pipeline is finished. With GitOps that final step is pushing the modified deployment into Git and letting GitOps agents modify Kubernetes. The benefit of GitOps is that it is continuous, the GitOps agent is continually reconciling the actual state with the desired state, unlike a CI/CD pipeline step which only fires once. Therefore if the configuration is manually updated, it will be immediately reverted back; configuration drift can not happen. Additionally, the chances of a manual change happening in the first place are significantly reduced because the number of people requiring direct access to the Kubernetes cluster is greatly curtailed. This has an added security benefit with fewer access keys there is less chance of them leaking.

Devtron builds GitOps into the heart of its platform fully integrating it with the built-in CI/CD. Giving you all the advantages of blazingly fast builds and secure delivery all in one integrated platform.