GitOps upholds the principle that Git is the one and only source of truth. GitOps requires the desired state of the system to be stored in version control such that anyone can view the entire audit trail of changes. All changes to the desired state are fully traceable commits associated with committer information, commit IDs and time stamps. This means that both the application and the infrastructure are now versioned artifacts and can be audited using the gold standards of software development and delivery.

GitOps is based off a Git-based source code management system and hence GitHub, GitLab and Bitbucket are natural choices. [1] Note that Bitbucket has floated a GitOps-y approach by the name of BDDA, pronounced like ‘Buddha’, for “Build-Diff, Deploy-Apply”.

Figure 1: GitOps Deployment Workflow

GitOps requires us to describe the desired state of the whole system using a declarative specification for each environment. [2] This becomes the system of record. You can describe your environments such as test, staging and production in a code repo, along with the application version that resides in that environment.

For example, we can describe everything in the Kubernetes model as a declaration. The Kubernetes API server accepts a declaration as an input, and then continually tries to drive (or converge) the cluster to the desired state described in the declaration.

GitOps is not a single product, plugin, or platform. GitOps workflows help teams manage IT infrastructure through processes they already use in application development as shown in figure 1.

GitOps requires three core components:

GitOps = IaC + MRs + CI/CD

IaC: GitOps uses a Git repository as the single source of truth for infrastructure definitions. Git is an open source version control system that tracks code management changes, and a Git repository is a. git folder in a project that tracks all changes made to files in a project over time. Infrastructure as code (IaC) is the practice of keeping all infrastructure configuration stored as code. The actual desired state may or may not be not stored as code (e.g., number of replicas or pods).

MRs: GitOps uses merge requests (MRs) as the change mechanism for all infrastructure updates. The MR is where teams can collaborate via reviews and comments and where formal approvals take place. A merge commits to your main (or trunk) branch and serves as an audit log.

CI/CD: GitOps automates infrastructure updates using a Git workflow with continuous integration and continuous delivery (CI/CD). [3] When new code is merged, the CI/CD pipeline enacts the change in the environment. Any configuration drift, such as manual changes or errors, is overwritten by GitOps automation so the environment converges on the desired state defined in Git. GitLab uses CI/CD pipelines to manage and implement GitOps automation, but other forms of automation, such as definitions operators, can be used as well.

Changes are made via pull requests

With GitOps, troubleshooting becomes easier and faster, since we fix a production issue via a pull request rather than tinkering directly with a running system. [4] If we limit cluster access to a handful of privileged admins, we can apply the same Git workflow to both operations and development. Changes to the application and cluster can then be contained to the following activities:

• Updates to container images
• Updates to the declarative specification, or in other words, the desired state
• Errors in the environment, like container malfunctions

Operating via pull requests reduces the number of variables which transform deployments into crime scenes! Fortunately (or, unfortunately for people who revel in heroics and theatrics), code deployers are no longer awarded “war hero” status for manually moving bits from point A to point B.

The benefits of applying [5] GitOps best practices are far reaching and provide:

1. Increased Productivity: Continuous deployment automation with an integrated feedback control loop speeds up Mean Time to Deployment. Your team can ship 30-100 times more changes per day, increasing overall development output 2-3 times.
2. Enhanced Developer Experience: Push code and not containers. Developers can use familiar tools like Git to manage updates and features to Kubernetes more rapidly without having to know the internal of Kubernetes. Newly on-boarded developers can get quickly up to speed and be productive within days instead of months.
3. Improved Stability: When you use Git workflows to manage your cluster, you automatically gain a convenient audit log of all cluster changes outside of Kubernetes. An audit trail of who did what, and when to your cluster can be used to meet SOC 2 compliance and ensure stability.
4. Higher Reliability: With Git’s capability to revert/rollback and fork, you gain stable and reproducible rollbacks. Because your entire system is described in Git, you also have a single source of truth from which to recover after a meltdown, reducing your meantime to recovery (MTTR) from hours to minutes.
5. Consistency and Standardization: Because GitOps provides one model for making infrastructure, apps and Kubernetes add-on changes, you have consistent end-to-end workflows across your entire organization. Not only are your continuous integration and continuous deployment pipelines all driven by pull request, but your operations tasks are also fully reproducible through Git.
6. Stronger Security Guarantees: Git’s strong correctness and security guarantees, backed by the strong cryptography used to track and manage changes, as well as the ability to sign changes to prove authorship and origin is key to a secure definition of the desired state of the cluster.

References:

1. https://www.cloudbees.com/gitops/what-is-gitops
2. https://www.weave.works/technologies/gitops/
3. https://about.gitlab.com/topics/gitops/
4. https://www.gitops.tech/
5. https://www.redhat.com/en/topics/devops/what-is-gitops

Cite this article:

D. Vinotha (2021), GitOps, AnaTechmaz, pp. 4