The concept of GitOps was popularised by Weaveworks with the introduction of their open-source tool, Flux. Flux is a GitOps tool that automatically synchronises the desired state of an application with the current state of the infrastructure. It does this by watching for changes in a designated Git repository and then making the necessary changes to the infrastructure to match the desired state. This ensures that the infrastructure and application are always in sync and eliminates the need for manual intervention.
Where it started
Weaveworks introduced the GitOps concept and the Flux tool in 2017, as a way to help organisations manage their cloud-native infrastructure and applications more effectively. Since then, the concept and the tool have gained widespread adoption and have been used to manage a wide range of workloads, from simple container deployments to complex multi-cluster environments.
Flux is now an open-source project, and the company offers a commercial version of the tool, called Flux Enterprise. This version includes additional features and support for enterprise-grade features such as role-based access control and audit logging.
Weaveworks also offers a product called "Flux CD" which is a GitOps tool that automates the deployment of containerised applications across multiple clusters and namespaces. It uses Git as the single source of truth for the desired state of the application and automates the delivery of the application to the clusters.
GitOps is used in different types of infrastructure but mainly it is used with Kubernetes because it is not really convenient to deploy services on Kubernetes directly with Terraform or Ansible since it has its own configuration system based on YAML and HELM as a package manager.
Weaveworks listed the following properties of GitOps:
- Continuous deployment
- Declarative configuration
- Feature branching
- Continuous Delivery
These are not new concepts but they have been described by Dave Farley and Jez Humble in their book, Continuous Delivery. The DevOps Handbook by Gene Kim et al in 2016 included the 2014 State Of DevOps Report comment that ‘the use of version control by operation engineers was the highest predictor of both IT and organisational performance and it recommended a single source of truth for the entire system. In the same year, Kief Morris established infrastructure definition practices in Infrastructure as Code.
You don’t need to buy a product either, for instance, if you deploy with Terraform or another tool to AWS ECS or Google Cloud Run, using GIT, and a CI/CD system, you have basically achieved GitOps. But you could do something similar using Kubernetes and a simple command lines tool like helmfile, GIT, and a CI/CD tool. I heard that real GitOps applies changes continuously. GitHub actions, GitLab CI/CD, or Jenkins can do that too.
GitLab in their article ‘What is GitOps?’ are explaining what it means and that it can be accomplished using their tools, GIT, Docker Registry, and CI/CD. This is another proof that GitOps is just a set of good practices.
ArgoCD
ArgoCD is another GitOps tool that helps developers and operators to manage their applications and configurations in a declarative and automated manner. It is an open-source project that provides a seamless and efficient way to continuously deploy and manage cloud-native applications.
The main goal of ArgoCD is to provide a consistent and reliable way to keep the desired state of an application in sync with the actual state. With ArgoCD, developers and operators can define the desired state of their applications in Git, and the tool will ensure that the running environment matches the defined state. In this way, ArgoCD helps to minimise the risk of configuration drift, ensure that deployments are consistent, and improve the overall reliability of applications.
Summing Up
There is nothing wrong with GitOps but it is a buzzword that is using good practices that had already been established before. What is important is that you won’t adopt it automatically, you need to understand what your company needs, and at what stage you are.
When I hear: ‘we have Kubernetes and now we need GitOps’ I see a red alert.
You do not need to adopt what is new and cool or what everybody is using, but you should analyse all the requirements you need, if you have automated tests, or do automated deployments, what Git workflow you are using, and whether GitOps will benefit you.
Further Reading
- Continuous Delivery [2010] by Dave Farley and Jez Humble
- The DevOps Handbook [2016] by Gene Kim et al
- Infrastructure as Code: Managing Servers in the Cloud [2016] by Kief Morris
- Helmfile [2023]
- What Is GitOps [2022]
