Have you heard of GitOps?
The term “GitOps” was incepted in 2017 by Weaveworkrs and it’s a technique to implement CI/CD for Cloud Native applications.
It suggests that we separate deployment manifests from application code and use version control tools, such as Git to store the infrastructure descriptions.
In their words:
“GitOps is a way of implementing Continuous Deployment for cloud-native applications. It focuses on a developer-centric experience when operating infrastructure, by using tools developers are already familiar with, including Git and Continuous Deployment tools.”
But what does it mean? Let’s break these concepts down.
“A way of implementing Continuous Deployment for cloud-native applications”
If it’s a way of implementing, it means that we will not have a tool to install that will do everything for us.
It also means that it’s not a book of rules: you can adapt the technique in the way that it’s best for your project.
And it’s meant for cloud-native applications, so not for on-premises.
“It focuses on a developer-centric experience”
To implement GitOps you need a version control tool. With that, you will benefit from the history of changes, pull requests, code reviews and fast rollbacks if necessary.
That is the way we — developers — manage our source code for years and it works quite fine. So why don’t we apply the same idea to manage infrastructure descriptions?
What is needed to implement GitOps?
You will need Infrastructure as Code (IaC) with declarative infrastructure descriptions, and as previously mentioned a version control tool.
Let’s just remember that IaC can be done in an imperative or a declarative way.
An imperative way is when you have commands that need to be executed in a specific order.
The declarative way is when you have declarations of the desired state, which may be divided into modular components, and the IaC tool will take care of executing it for you.
How does it work?
In general lines, you will have two repositories: your application code repository and in addition to that an infrastructure repository with your declarative infrastructure descriptions.
Then you can follow one of the two GitOps strategies: push-based or pull-based.
Push-based
Push-based can be seen as your traditional CI/CD pipeline with the addition of an infrastructure repository.
The pipeline will apply the changes to your environment.
There is a potential problem here: to achieve that, the pipeline will need to store credentials for all the environments and that can turn into a security flaw.
Pull-based
The idea for the pull-based strategy is similar but we introduce operators.
In this scenario, the operator is the one triggering the changes instead of the pipeline.
Each environment (production, release, staging, etc.) will have its own operator and each operator knows only its own credentials.
The operator will constantly watch for changes in the repository and when it detects some, it performs the deployment.
An example of an operator is Argo CD.
Why adopt it?
With GitOps you can:
- Keep track of changes’ history
- Submit infrastructure changes to review the process
- Have one source of truth
- Recreate an environment with exactly the latest needed and approved configurations
- Perform rollbacks more easily and fast
Frequently Asked Questions
Can I do it without Git?
Yes, any version control tool can work. However, all available operators are made for Git repositories.
“Any infrastructure that can be observed described declaratively, and has Infrastructure as Code tools available can make use of GitOps”. (https://www.gitops.tech/)
Do I need Kubernetes?
No, BUT… operators are implemented for Kubernetes.
References and useful links
- GitOps Tech
Official GitOps website - GitOps Cloud-native Continuous Deployment
Free, short and useful book by Florian Beetz, Anja Kammer, Simon Harrer - GitOps Fundamentals — GitOps with ArgoCD and Argo Rollouts
Free course and GitOps certification
