GitOps: ‘Git Push’ All the Things
While the idea of cloud-native computing promises to change how modern IT operations work, the idea remains vague for many who work in the profession. “GitOps,” an idea that generated some buzz at the KubeCon + CloudNativeCon EU conference in Copenhagen last week, could bring some much-needed focus to this area.
GitOps is all about “pushing code, not containers,” said Alexis Richardson, Weaveworks CEO and chair of the Cloud Native Computing Foundation‘s Technical Oversight Committee, in his KubeCon keynote. The idea is to “make git the center of control,” of cloud-native operations, for both the developer and the system administrator, Richardson said.
“The key point of the developer experience is ‘git-push,'” he said, alluding to the git command used to submit code as finished. He added that this approach is “entirely code-centric.”
At an initial glance, the open source git version control software makes perfect sense as a front-end for cloud native computing. Given its nearly widespread usage by developers, git commands are the Lingua Franca of the open source world. The basic idea is that all changes to a cloud-native system can be done through git. Once a commit is made, it sets off an automated pipeline, perhaps using a tool such as Jenkins X to containerize and test the code, and press it into production.
And this approach could work exactly the same for infrastructure management as well: Richardson calls this approach “declarative infrastructure.” Make changes in configuration through a YAML file, and Kubernetes can detect changes in the file and readjust the resources as necessary. Immutable infrastructure made easy! Weaveworks itself has released a number of tools for comparing the desired state with actual state in such cases, such as kubediff.
“The fundamental theorem of GitOps is that if you can describe it, you can automate it. And if you can automate it, you can control and accelerate it. The goal is to describe everything — policies, code, configuration and monitoring — and then version control everything,” wrote site reliability engineering architect Rob Scott, for The New Stack’s upcoming eBook on Kubernetes and continuous integration and deployment.
Weaveworks itself uses a GitOps pattern to support its own commercial Kubernetes managed service. It is git that holds the world state of the entire system, including previous versions, which are recoverable. This approach builds on “an atomic sequence of transactional commits,” Richardson said.
“The desired state of your entire system is in git, which means that the cluster and its observed state can be compared with [desired state configuration], at all times, for any layer of the stack,” he said. Richardson boasted that his company’s developers use kubectl, the Kubernetes’ command line, as little as possible. The company has been experimenting with managing the Istio service mesh through git, for instance, though this remains a work in progress:
Still, the idea of GitOps seems to be catching on outside of Weaveworks.
One early adopter of the GitOps approach has been the content platform team of the Financial Times, to judge by the KubeCon keynote talk from Sarah Wells, who was the tech lead for that team. The company’s content platform is built from 150 microservices. In 2015, the newspaper moved this platform over to Docker from virtual machines.
After migrating to containers, the Financial Times found the number of releases it did increased from 12 a year to 2,200, an increase that also came with a much lower failure rate. Agility! Instead of spinning up a new VM, all the changes are simply made to a YAML file. While she didn’t mention “GitOps” by name, Wells did say developers push all their changes through GitHub.
