The companies Weaveworks and Codefresh, which specialize in GitOps, have started the GitOps Working Group together with the cloud providers Amazon and Microsoft and the operators of the version management platform GitHub. The working group is an open community project at the Cloud Native Computing Foundation (CNCF).

GitOps: Cluster configuration in the repository Weaveworks has the term GitOps 2017 coined under the heading “Operations by Pull Requests”. The GitOps paradigm combines continuous delivery with the approach of defining infrastructure via code (Infrastructure as Code, IaC). The version management software Git plays a key role here: All information for configuration and distribution is in a Git repository. The latter is the single point of truth (SPoT).

GitOps plays a role especially in the cloud-native environment in interaction with Kubernetes. With Weaveworks and Codefresh, two founding members of the GitOps Working Group are important providers in this field. Also worth mentioning is CloudBees with Jenkins X.

Flux compensator as the basis As the basis of the working group serves the Flux Community from the Flux project, which is subordinate to the CNCF. The name is the Latin word for river, and at the heart of the project is a tool to ensure that the state of a Kubernetes cluster matches the description in a Git repository. A separate operator in the cluster takes care of distributing the software and configurations within Kubernetes.

The How Flux works with an operator who synchronizes the content from the Git repository with the Kubernetes cluster is a prime example of the GitOps paradigm.

(Image: Fluxcd on GitHub)

As part of its Technology Radar on Continuous Delivery in June, the Cloud Native Computing Foundation classified Flux next to Helm in the “Adopt” category, which corresponds to a recommendation for applying the technology.

Where there is a will, there is a manifest One of the short-term goals of the working group creating a “GitOps Manifesto”. Since the legendary Agile Manifesto, corresponding manifestos have been part of good form: 2020 include the Low Code and the BizOps Manifesto

With the GitOps Manifesto, the group wants to write down clear principles and the technical aspects of the approach. It should be manufacturer-neutral and should be based on generally shared principles rather than individual views. On the technical side, it is not intended to prescribe individual code, tools or tests, but to explain the results to be achieved.

Five basic principles The blog post about the start of the GitOps Working Group defines five principles for the paradigm:

Declarative configuration: All resources must be fully declared. Version control and unchangeable storage: The descriptions are stored in a repository that offers unchangeable storage and versioning. Automated distribution: The implementation of the descriptions from the repository into the runtime environment must be fully automated. Software agents: They compare the status of the system and provide the resources described in the declaration .Closed circle : As soon as there are deviations between the declarative configuration and the actual state of the system, appropriate actions are triggered. Further details on the newly formed working group can be found in the blog post by Weaveworks. The catchphrase GitOps 2.0, which Codefresh brought into play in mid-November, is initially not mentioned.

(rme)