GitOps — Git Push All the Things

In today’s competitive environment you need to deliver features quickly without compromising on quality. But it can be difficult for most organizations to keep up and balance current release management practices with traditional operations procedures. And now with developers taking an end-to-end "you build, you own it" approach to development processes, they need tools and methods they know best in order to quickly adapt.

At the most recent Continuous Lifecycle conference in London, Alexis Richardson delivered the keynote address entitled, “GitOps: Git Push All the Things” where he discussed the industry challenges, including current CI/CD trends and how all of these tools and processes are converging with operations and monitoring. In addition to this, Alexis explained how by applying GitOps best practices, developers can take control of both the development and operations pipelines using the tools with which they are most familiar.

Three Principles of GitOps

GitOps can be summarized by these principles:

1. Everything that can be described must be stored in git

By using Git as the source of truth, it is possible to observe your cluster and compare it with the desired state. The goal is to describe everything: policies, code, configuration, and even monitored events and version control it all. Keeping everything under version control enforces convergence where changes can be reapplied if at first they didn’t succeed.

2. Kubectl should not be used directly

As a general rule, it's not a good idea to deploy directly to the cluster using the command line utility `kubectl`. Many people let their CI tool drive deployment, but by doing that you’re potentially giving a notoriously hackable thing access to production.

3. Use a Kubernetes controller that follows an operator pattern

With a Kubernetes controller that follows the operator pattern, your cluster always stays in sync with ‘the source of truth’ via its configuration files that have been checked into Git. And since the desired state of your cluster is kept in Git, it can be observed for differences against the running cluster.

This third point was expanded upon by Alexis where he described how by comparing the desired state in Git with your running cluster state, it is possible to observe differences and then alert your team on those cases when the two states are out of sync. By installing a Kubernetes operator to your cluster, not only are deployments safer from a credentials point of view, but it also allows for an effective control and feedback loop. Your team can use this data to iterate and to improve upon both product features as well as updates to your cluster’s infrastructure.

“What can be described can be both validated and automated if you describe everything and keep it in version control. This gives you a mechanism for keeping the correct description of a system in version control and using that to automate the whole system. “ - Alexis Richardson

Watch the talk in its entirety: