GitOps in Softwaredevelopment
The speed of software development has increased immensely in recent years due to the new requirements originating from the digital transformation. This development is not over yet, as new approaches are continuously being found to make processes more efficient and to accelerate them. GitOps is a new concept in which the operation of software is made possible directly by the development team by configuring cloud servers in the Git version management.
GitOps vs. Continuous Delivery vs. DevOps
As the name GitOps suggests, there is a certain relationship to DevOps. In short, GitOps can be understood as a part of DevOps. The aim of DevOps is to bring the operation of software close to development through automation and Continuous Delivery (CD), Configuration Management, containerization, orchestration, monitoring and more.
GitOps is another tool in the DevOps toolbox for Configuration Management and Infrastructure as Code (IaC). The basic idea of GitOps is most obvious when compared to Continuous Delivery.
In classic Continuous Delivery, the source code is saved by the developers in the sourcecode-management tool. The CI server fetches the data from there, performs the build and tests and stores the built application (consisting of one or several artifacts, e.g. a Docker image) on a server (artifact repository or registry).
After that, the CI server deploys the application. The configuration für the deployment can be done within the CI server or stored and versioned in Git.
Just like the Continuous-Delivery approach, GitOps wants to store all information in the sourcecode management. The difference is that the deployment environment synchronizes its state directly with Git without the CI server being involved in the deployment. Therefore, the configuration has to be versioned in Git. Since it is treated as code, it is also called Infrastructure as Code. (IaC)
This approach creates several advantages:
- Configurations are written as code (Configuration as Code – CaC and IaC). This improves audits and reproducibility.
- More Security:
- Clusters get all the necessary information from Git. This means that less write access to the clusters is required.
- The CI server does not need access to the cluster. Therefore no login data need to be stored there.
- Organizationally, access to Git is often easier to get than access to an API server (like firewall activation).
GitOps and Kubernetes
The idea for GitOps originated from the Kubernetes environment. By now, it is already possible to use GitOps for other environments (e.g. virtual machines).
With Kubernetes, GitOps uses the operator pattern. An operator is a cloud-native application that supports the opertaion of other applications. A GitOps operator compares regularly or "on push" the in Git defined state with the actual state of the cluster. If there are changes, the GitOps operator adjusts the cluster accordingly. The best known examples are Flux and ArgoCD. Both are projects by the Cloud Native Computing Foundation, under whose patronage Kubernetes is being developed.
GitOps at Cloudogu
At Cloudogu we have been using GitOps for some time to map internal processes and as part of the infrastructure of the backend of our EcoSystem. Based on these experiences we created our GitOps playground, where clients can hustle free make their first experiences before they implement their own infrastructure. We made this project open source, so that also you can easily and quickly try out how simple it is to set up a GitOps infrastructure consisting of several tools. If you have any questions, feel free to contact us.