Hello there, and welcome to the first rant on this blog. No, deploying infrastructure from Git doesn't mean you are doing "GitOps". It's called Infrastructure-as-Code on Git.
GitOps is IaC, but IaC is not necessarily GitOps.
So what is GitOps?
Well, there is a specification, a standard, named OpenGitOps that defines it the following way (the main focus of this post is on the 4th principle):
1. Declarative
A system managed by GitOps must have its desired state expressed declaratively.
Well, there is not much to add, it shouldn't be a for-loop in a bash script that uses an API, but just plain declarative configuration code.
2. Versioned and Immutable
Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.
That's the Git part of GitOps! Although it started with Git (and that's where the name comes from), now you can find another state store like OCI repositories.
3. Pulled Automatically
Software agents automatically pull the desired state declarations from the source.
The "software agents" are the tools like Flux, ArgoCD, etc. that will pull the desired state from the source (Git or OCI repository). It shouldn't be manual.
4. Continuously Reconciled
Software agents continuously observe actual system state and attempt to apply the desired state.
That's to me THE point where people get GitOps wrong (or on purpose wrong, to sell you more buzzwords).
If the state of the system changes, you should expect the software agent to reconcile the state to the desired state. In other words, what is in Git should be reflected in the Kubernetes Cluster all the time.
Adding a CI/CD pipeline to your repository that runs a kubectl apply is not GitOps. GitOps is to have a tool checking for drift detection and re-applying the desired state when needed.
Let's take an example: The new intern - let's name him Kevin - gets production access, and for debug purposes sets the replica number of a Kubernetes deployment to 0 instead of 3. Well, the GitOps software agent should see that the state of the cluster is different from the desired state and re-apply the desired state, causing the deployment to be back to the desired state: 3. it's a very powerful feature that brings production robustness to manual errors and drift detection!
Do you want to see a super powerful and strong GitOps agent? Here is mine:
➜ ~ while true; \
do kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/snapshot-initial-v1.31/content/en/examples/pods/simple-pod.yaml; \
sleep 15; \
done
pod/nginx created
pod/nginx unchanged
pod/nginx unchanged
pod/nginx unchanged
It's declarative, versioned and immutable in Git (Pod specs are in YAML here). It's pulled from Git, and it's continuously reconciled every 15 seconds. It's GitOps!
Final notes
This post is written by a "DevOps" engineer, so don't pay too much attention to buzzwords after all. I hope I shed some light on the GitOps principles at the cost of a clickbait title (and maybe a few Twitter dramas).
Sources
- OpenGitOps principles - https://opengitops.dev/
- 4 Core Principles of GitOps - The new stack - https://thenewstack.io/4-core-principles-of-gitops/
- How We Are Moving from GitOps to Kubernetes Resource Model in 5G Core - https://www.youtube.com/watch?v=crmTnB6Zwt8&t=302s
- Flux Beyond Git: Harnessing the Power of OCI - Stefan Prodan & Hidde Beydals, Weaveworks - https://www.youtube.com/watch?v=gKR95Kmc5ac&t=1215s (Using OCI repository instead of Git)
- and many others on the internet!
:wq
Top comments (0)