Empower developers to do operations.
While researching CI/CD workflows and DevOps practices for cloud native applications using Microservices, Docker and Kubernetes, I stumbled upon GitOps.
I'm using this repo to create an overview of all things I'm learning about this subject.
"GitOps is short for Git Ops. It is a name for a set of Ops practices using Git. The spirit of the name is to be like DevOps — something that anyone can do rather than being a product." - Alexis Richardson
GitOps is a name coined by Weaveworks which describes how developers use
tooling to drive operations. It builds on DevOps best practices, allowing developers to operate Kubernetes
via Git instead of tools like kubectl.
"kubectl is the new ssh." - Kelsey Hightower
This is possible because Git is used as the single source of truth for the desired state of your entire system.
The fundamental theorem of GitOps is:
Only what can be described and observed can be automated and operated.
When the desired state of a system is version controlled and used as the single source of truth, we get all the benefits of Git and Pull Request based workflows:
- history
- possibility to revert changes
- reviews
- comments
- possibility to link to issues, Pull Requests, stories, etc.
This makes the entire system more transparent, discoverable, easier to operate, recoverable and observable. These attributes help us to reliably deliver quality software at a high velocity in order to innovate, stand out in the market and be cost efficient.
"When we say high velocity we mean that every product team can safely ship updates many times a day — deploy instantly, observe the results in real time, and use this feedback to roll forward or back. The goal is for product teams to use continuous experimentation to improve the customer experience as fast as possible." - Alexis Richardson
TODO: security
TODO: testing in prod
By making Git the source of truth of the desired state of the system and making Obersvability the source of truth of the actual running state of the system, we can use the Operator Pattern to control the actual state so that it will reflect the desired state. This is achieved by listening for certain Git tags to be pushed and in turn orchestrate service deployments to the cluster. Tools like Weaveworks Flux do this.
“Ideally if I make a code change, all I want is a URL to tell me where it’s running. You get bonus points if you can give me metrics to tell me how well it’s running." - Kelsey Hightower
TODO: Push vs pull deployment
TODO: monitoring & observability
-
Immutable deployment artefacts
-
Git:
- Code & config version controlled
- Rollback functionality
- Operational changes must be made by Pull Request; don't let CI push updates into the Kubernetes cluster or use
kubectlby hand - Build each container image just once and 'promote' it through each test sequence / environment, do not rebuild each time. But you must still update your declarative config changes in Git.
- Monitorable & observable services & infrastructure
- Diff tools detect/alert divergence
- Sync tools enable convergence
- Completely automated delivery pipeline
- GitOps - Operations by Pull Request
- The GitOps Pipeline - Part 2
- GitOps Part 3 - Observability
- GitOps Part 4 - Application Delivery Compliance and Secure CICD
- GitOps: High velocity CICD for Kubernetes
- How secure is your CI/CD pipeline
- KubeCon 2017 Opening Keynote - Kelsey Hightower, Google
- KubeCon 2017 - GitOps - Operations by Pull Request - Alexis Richardson, Weaveworks & William Denniss, Google