1.1 What is GitOps?
- Modern container orchestration platforms like Kubernetes, OpenShift, and Rancher require a lot of configuration to define and manage clusters, application deployments, and environments. GitOps is the practice of using Git to version control these configurations.
- Developers have been using Git to version control their code. GitOps extends the same principles and benefits to infrastructure management.
- Before GitOps: DevOps users will use tools like kubectl to apply changes to a container cluster. This is called the imperative style.
- With GitOps: Cluster configurations are committed to a Git repo. A GitOps tool like Flux or Argo CD picks up these changes and applies them to the cluster. This is called the declarative style.
1.2 Benefits of GitOps
- At any point in time, the Git repo provides an accurate picture of all the settings applied to a cluster. There’s no need to guess or check emails to find out who applied what changes and when.
- Git keeps a log of every change made to any file. With this, you can track down who made what change and when. This increases accountability. If a change has introduced new problems you can go back and history and locate which change may have caused it. These benefits are already enjoyed by the developers and with GitOps we are extending them to the DevOps people.
- With GitOps very few users need admin access to the container cluster to directly apply changes. Instead, they commit the required changes to Git. These changes are reviewed and approved by their peers. Only then the changes are applied to the cluster by a GitOps tool like Flux.
1.3 Common GitOps Tools
- Argo CD (https://argoproj.github.io/cd/).
- Flux (https://fluxcd.io/).
- Werf (https://github.com/werf/werf).
- In addition container service providers like Amazon AWS, Microsoft Azure and Google compute provide tools around Flux and Argo CD.
1.4 A Typical GitOps Workflow
- While the details will vary based on the GitOps tool and your preferences, a basic workflow will be like this.
- Developers make changes to application code and submit a pull request (PR). Container configuration changes, if any, are also committed to the repo.
- The PR is approved by the peers and approved. This causes code changes to be merged to the main branch.
- This triggers the CI pipeline tasks such as:
◊ Run tests.
◊ Build a new container image and push it to an image registry.
- An agent of the GitOps tool (Flux etc.) detects a new container image and container configuration changes. These changes are then applied to the container service provider.
- GitOps applies Git’s version management principles to infrastructure administration.
- Instead of applying changes directly to a container orchestration environment, these changes are committed to a Git repo. A GitOps tool such as Flux picks up these changes and applies them to the environment.