GitOps is a way of practicing DevOps. GitOps makes it possible to use versioned sets of declarative specifications to bring continuity to the entire development and commissioning process. This gives the whole development team a better view of the integration and rollout of your application(s).
Components from GitOps
At GitOps there are the following established components that you must understand before setting up a GitOps infrastructure:
-
Infrastructure-as-Code (IaC) GitOps uses Git Repositories as the only instance of truth claims,‘single source of truth’. That means that everything that is versioned via a Repository also corresponds to what is actually used. In reverse, it means that all relevant information and configurations must be stored in a Repository. Not only the source code of applications, but also of entire infrastructures and application environments should thus be fixed in a declarative way.
-
Merge Requests (MRs) GitOps makes great use of so-called Merge Requests. A Merge Request is a Git mechanism that merges development branches (Branches) (merged). Thus there is a control and administration instance which checks natively via Git when and how a development status may change. Every change to the components of an infrastructure can thus be tracked and accordingly managed more efficiently.
-
Continuous Integration & Continuous Delivery (CI/CD) Finally, GitOps uses the automation mechanisms of classic CI / CD. As soon as new declarative code has been accepted via Merge Request and was merged, an automated process can trigger the descriptive state of a pipeline that adapts the infrastructure accordingly. Manual adjustments are therefore always overwritten by the GitOps automatism and have the minimum possible effect.
Tools for the implementation of GitOps
GitOps makes particular sense with infrastructures in the cloud, since many machine-related operations are already abstracted or even automated in some way. So there is already a certain Awareness of CI / CD. Nevertheless, we would like to briefly show what is important for optimally lived GitOps.
Pipeline
In addition to the use of Git Repositories, a dedicated pipeline is required. This can be, for example, Jenkins, CircleCi or Tekton. The pipeline takes care of the gap between the Git-based Pull Request and the orchestration of the infrastructure. Via so-called Hooks, as soon as a Merge Request is accepted, the corresponding pipeline is immediately triggered, which builds the status and rolls it out directly to the infrastructure.
Best Practices
- Declarative description of the infrastructure (IaC)
- Immutable rollout
- Versioning and control of code and configuration
- Rollback functionality
- Operational change only through Pull Requests
- Each build artifact should only exist once, the update mechanism is best in a declarative and automated manner
- Monitoring of the whole process as well as the infrastructure
- Fully automated delivery pipeline
Conclusion
GitOps is not just a hype word of the last few years, but a solid concept of how DevOps can be lived in a company. As a developer, it is easily possible to push yaml files into a Git repository and attach them to a pipeline such as Jenkins or Tekton. This then makes any changes to a container cluster such as Kubernetes. The logic is that simple.
We at b-nova are convinced of the concept and will stay on the trail that leads to a tried and tested understanding of GitOps and hope to introduce the first GitOps-capable concepts to you as well.
This text was automatically translated with our golang markdown translator.