GitOps in Softwaredevelopment
The speed of software development has increased immensely in recent years due to the new requirements of the digital transformation. And the potential for improvement has not been exhausted yet, as new approaches are continuously being pioneered to make processes more efficient as well as to accelerate them. GitOps is a new concept for the automation of as many IT operations as possible. An important core component is the fully declared and versioned target state that is defined in Git. Special software is used to continuously compare this target state with the actual state on the infrastructure, and it ensures that the target state is established.
GitOps vs. Continuous Delivery vs. DevOps
The term "GitOps" itself suggests a certain relationship to DevOps. However, the term DevOps describes a rather abstract mindset for cooperation between formerly separate professional groups, such as development and operations. GitOps, on the other hand, is much more specific and focuses on operations (Ops). Running your project with GitOps fits in well with a DevOps mentality. According to the inventor of the term GitOps, Alexis Richardson, GitOps can even be considered to be the right way to do DevOps (see the interview linked below). We believe that GitOps can in principle also be done without DevOps (for example for an operations team). Conversely, DevOps is also possible without GitOps. GitOps is constantly used to implement practices such as "Infrastructure as Code" (IaC), Configuration As Code, and configuration management. The basic ideas behind GitOps can be articulated most clearly when they are compared to the classic imperative Continuous Delivery (CD) using a CI server. This is now referred to as CIOps to differentiate it from GitOps.
The CIOps approach
Under the CIOps approach, developers save the source code in the source code management. The CI server fetches the data from there, creates the builds and performs the tests imperatively, and places the application that was created in the build (consisting of one or more "artifacts", for example, a Docker© image) on a server (artifact repository or registry).
The application is then deployed by the CI server (using the push principle). The configuration for the deployment can be performed on the CI server or stored and versioned in Git. It is also conceivable that the CI server can still change the state. Often it writes the version of the artifact that has just been built to the deployment description.
The GitOps Approach
Like the continuous delivery approach, GitOps also relies on a system to maintain all information in source code management. The difference, however, is that the operating environment synchronizes its state directly from Git (using the pull principle), and the CI server is not responsible for the deployment. It is only responsible for the builds and tests. The configuration must therefore be completely versioned in Git.
The deployment in the operating environment is triggered by a continuously executed "reconciliation loop", which detects all deviations from the target state and tries to compensate for them. The operating environment thereby always converges to the target state. Errors can also be corrected automatically. This is basically what is understood to be "continuous operations".
There are several advantages to this approach:
- The fully declarative description is enforced. There are no more imperative steps that the CI server can perform. This improves audits and reproducibility.
- More Security:
- The cluster obtains all required information from Git. This allows external access to this cluster to be further restricted.
- The CI server does not need access to the cluster. Therefore, no access credentials need to be stored there.
- Organizationally, it is often easier to obtain access to Git than access to an API server (keyword: firewall activation).
A more formal definition of GitOps is currently being worked out by the GitOps Working Group, which is a CNCF project. The GitOps principles, which are intended to enable a clear distinction between GitOps and CIOps, will be elaborated on the basis of this definition.
More details on the motivation and the story behind GitOps can be found in this interview with Alexis Richardson from Weaveworks, who coined the term GitOps there in 2017:
GitOps and Kubernetes
The idea for GitOps originally came from the Kubernetes environment. In the meantime, however, more and more opportunities to use GitOps with other operating environments have appeared. For Kubernetes, GitOps is implemented according to the operator pattern. An operator is a cloud-native application that supports the operation of other applications. A GitOps operator (often also called a "custom controller") continuously checks the target state described in Git against the actual state of the cluster. If there are changes, the GitOps operator adjusts the cluster accordingly. The best-known implementations are Flux and ArgoCD. Both are projects of the Cloud Native Computing Foundation, under whose patronage Kubernetes is also being developed.
GitOps for infrastructure
GitOps is a mature tool for deploying applications in Kubernetes, and it is already being used in production. However, GitOps is not limited to this use case. GitOps operators can also be used to roll out Kubernetes clusters. The advantages of using GitOps to operate the infrastructure are particularly evident when it comes to scaling: A single cluster can still be easily configured via a graphical user interface. As the number of clusters increases, however, sooner or later automation and programmatic approaches will be necessary. One such approach is GitOps.
One option for rolling out Kubernetes clusters is the Cluster API (CAPI). In addition to creating Kubernetes clusters, there is also an increasing number of opportunities to use various Infrastructure-as-Code (IaC) tools, such as Terraform, with GitOps. However, many of the existing tools are also implemented as operators for Kubernetes. If you want to implement GitOps without Kubernetes, there are not many choices. In general, it is still plainly evident that the maturity of GitOps decreases with the proximity to the infrastructure. Application deployments are mature, the rollout of clusters is already working quite well, but physical infrastructure cannot yet be operated via GitOps.
GitOps Tools
There is a growing number of GitOps tools that are available for deploying GitOps. Our blog article Automation assistants: GitOps tools in comparison provides an overview. It identifies tools from the following categories:
- Tools for Kubernetes (operators)
- Complementary tools (security management and deployment strategies)
- Infrastructure-related tools (CAPI, Terraform, Ansible, and VMs)
The categorization of such tools as "GitOps tools" is made more difficult by the fact that there is not yet any uniform definition of the term GitOps. Furthermore, things are complicated even more by the fact that there is a certain amount of hype surrounding the term, and developers like to add the name GitOps to their products simply for decorative purposes. In this respect, you need to pay careful attention when choosing the right tool for your own applications.
The linked article also offers a list of criteria that, in our experience, a GitOps tool should be able to satisfy in practice. The article offers the example of a comparison between the two well-known GitOps operators ArgoCD and Flux.
You can find additional overviews of GitOps tools at awesome-gitops and gitops.tech.
GitOps at Cloudogu
At Cloudogu, we have been using GitOps for some time for the productive operation of the backend of our EcoSystem. We have applied this experience to our open-source library GitOps-build-lib for Jenkins (see also our blog article on CIOps vs. GitOps with Jenkins). The GitOps-build-lib facilitates the transition from CIOps to GitOps by, for example, specifying a directory structure and automating steps such as validation (fail early), staging and the generation of pull requests, and the templating of Kubernetes manifests in the CI server. It also enables the entire code of an application to be kept in the application repository (app repo). The CI server automates transfers to the GitOps repository. Among other things, this facilitates local development because "everything is in one place" and no GitOps operator is required here.
GitOps (with Application Repository)
If you want to gain your first practical experience with GitOps and Kubernetes without having to perform any major configuration, our GitOps Playground is another open source project.
