4 Core Principles of GitOps

It’s at the point where GitOps is getting enough notice that a brief on its principles is appropriate.

Last year, the OpenGitOps community released GitOps Principles 1.0. There’s general support for GitOps and many competing interests in developing GitOps engines, such as with Argo and Flux, two graduate projects from the Cloud Native Computing Foundation. But focusing on principles lets everyone know what GitOps is and, even more so, helps define what it is not.

OpenGitOps defines GitOps as a set of principles for operating and managing software systems, wrote open source software engineer Scott Rigby. “When using GitOps, the Desired State of a system or subsystem is defined declaratively as versioned, immutable data, and the running system’s configuration is continuously derived from this data. These principles were derived from modern software operations but are rooted in pre-existing and widely adopted best practices.”

With DevOps, operations and development teams collaborate on their own chosen tools. GitOps provides a declarative approach and complements DevOps. It allows for application delivery and cluster management. GitOps shares the same concepts as Kubernetes, making it easier for teams already working with it to adapt.

The cdCON + GitOpsCon conference, held this week in Vancouver, BC,  featured a presentation about the GitOps principles by Rigby, and Christian Hernandez, a senior principal product manager with Red Hat.

Here are a few takeaways, from this talk and others at the conference:

Principle #1: GitOps Is Declarative.

A system managed by GitOps must have a desired state expressed declaratively.

GitOps allows for automating security practices, said Eve Ben Ezra, a software engineer with The New York Times, who spoke at the cdCON + GitOps Con event. DevOps encourages collaboration, which means incorporating security into every stage of the software development lifecycle.

The comparison to security practices dovetails with the second principle of GitOps:

Principle #2: GitOps Apps Are Versioned and Immutable

The desired state is stored in a way that enforces immutability, versioning, and complete version history.

The general viewpoint: rollbacks should be simple.

“You go a step further with GitOps providing an auditable trail of all changes to infrastructure and applications,” Ezra said.

Versioning allows organizations to find gaps in their security and also allows for testing and declarative infrastructure, Ben Ezra said. Using tools like the Open Policy Agent, an open source project for establishing authorization policies across cloud native environments, allows for more productivity because once it’s automated, teams spend less time agonizing over whether or not their infrastructure is compliant, which gives them more time for innovation and feature development.

“While automation is an important part of DevOps, it’s by no means the only methodology also calls for cross-functional collaboration and the breaking down the silos and knowledge sharing across an org,” Ben Ezra said. “GitOps builds on these principles of leveraging automation and infrastructures as code to reduce configuration drift, and providing a single source of truth for an entire team or org.

By writing it down, all team members can contribute to the infrastructure code, which promotes shared responsibility across the entire software development lifecycle. Just as importantly, everyone is aware of these changes, so they can speak up if they see something you missed.”

“For example, at the New York Times, we’ve leveraged utilities from OPA to improve feedback and developer productivity within GitOps operational framework,” Ben Ezra said.

Principle #3: GitOps Apps Are Pulled Automatically

Software automation automatically pulls the declared state declaration from the source.

Take Flux, for example. Flux is a set of continuous and progressive delivery solutions for Kubernetes that are open and extensible, enabling GitOps and progressive delivery for developers and infrastructure teams.

“So Flux is a set of continuous delivery tools that are focused on security, velocity and reliability,” said Priyanka Pinky Ravi, a developer experience engineer with Weaveworks, in a keynote with other engineers from Cloud Native Computing Foundation graduated projects.

“And they are focused on automation. So the idea is that you have this setup Kubernetes controllers that you install onto your cluster, and they’re running on a reconciliation loop which is just an interval that you set. And every time that runs, the source controller will go in and pull from whatever source you said, such as a git repository, home or repo Image, Image registry, OCI registry. And the idea is that it pulls the manifests that it finds there and then actually applies them onto your cluster.”

Principal #4: GitOps Apps Are Continuously Reconciled

“Software agents continually observe the actual system state and attempt to apply the desired state.”

Of note are the different views that reflect the GitOps community. But with a set of principles, the community can build approaches that reflect the core focus of what GitOps is and what it is not; at least, that’s the concept.

Start reading the discussions on GitHub; there are still issues to clarify, even when explaining the meaning of pull.

And there’s more on the Twitter threads. Enjoy.

When
1. An operator pushes a button on GUI to change the running system state directly without updating the desired state
2. Failures leading to drift from the desired state

Now either
A) an agent changes the system back to correct state
Or B) system is in an unknowable state

— Alexis Richardson (@monadic) May 11, 2023

1) Any pipeline not stored in git (just setup in a ui for example)
2) A pipeline that doesn’t deal with desired state at all, (just running a build, testing an image, gathering metrics, doing a data transformation, updating a database etc)
3) Any pipeline operating without…

— Dan Garfield (@todaywasawesome) May 11, 2023