GitOps - Git Push all the Things - Alexis Richardson keynote address
Read a recap and then watch Alexis Richardson deliver the keynote at the Continuous Lifecycle London conference. Alexis discusses industry standards, current trends in CI/CD and then shows how developers can take control of development pipelines and operations tasks using familiar tools and workflows.
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:
Need help?
We can help you accelerate your Kubernetes journey with our subscription service that supports installing production-grade Kubernetes on-premise, in AWS and GCP from dev to production. For the past 3 years, Kubernetes has been powering Weave Cloud, our operations as a service offering, so we’re taking our knowledge and helping teams embrace the benefits of cloud native tooling. We've focused on creating GitOps workflows - our approach uses developer-centric tooling (e.g. git) and a tested approach to help you install, set-up, operate and upgrade Kubernetes. Contact us for more details.
Learn more about our Production Grade Kubernetes support packages.
