What is GitOps
The GitOps term was coined back in 2017 by people from Weaveworks, who are also the authors of a GitOps tool called Flux. Since then, I have seen how GitOps turned into a buzzword up to being named the next important thing after DevOps. If you search for definitions and explanations, you will find a lot of them: it has been defined as operations via Pull Requests (https://www.weave.works/blog/gitops-operations-by-pull-request) or taking the development practices (version control, collaboration, compliance, CI/CD) and apply them to infrastructure automation (https://about.gitlab.com/topics/gitops/).
Still, I think there is one that stands out. I am referring to the one created by the GitOps Workgroup (https://github.com/gitops-working-group/gitops-working-group), which is part of the Application Delivery TAG (Technical Advisory Group) from CNCF. The App Delivery TAG is specialized in building, deploying, managing, and operating cloud-native applications (https://github.com/cncf/tag-app-delivery). The workgroup is made by people from different companies with the purpose to build a vendor-neutral, principle-led definition for GitOps, so I think these are good reasons to take a closer look at their work.
It starts with declarative configuration, which means we want to express our intent, an end state, and not specific actions to execute. It is not an imperative style where you say let’s start three more containers, but instead, you declare that you want to have three containers for this application and an agent will take care of reaching that number, which might mean it needs to stop two running containers if there are five up right now.
Git is being stated here by version-controlled and immutable storage, which is fair because while it is the most used source control system right now, it is not the only one and we could implement GitOps with other source control systems.
Automated delivery means that we shouldn’t have any manual actions once the changes reach the version control system. After the configuration is updated, it comes to software agents to make sure that the necessary actions to reach the new declared configuration are being taken. Because we are expressing the desired state, the actions to reach it need to be calculated. They result from the difference between the actual state of the system and the desired state from the version control. And this is what the closed loop part is trying to say.
While GitOps originated in the Kubernetes world, this definition is trying to take that out of the picture and bring the preceding principles to the whole software world. In our case, it is still interesting to see what made GitOps possible and dive a little bit deeper into what those software agents are in Kubernetes or how the closed loop is working here.