Originally published on mccricardo.com.
The day was the 7th, the month was August, the year was 2017 and Weaveworks came out with a post entitled GitOps - Operations by Pull Request. Since that day GitOps has been increasing it's popularity and gaining traction in the DevOps world.
What is GitOps?
Imagine the following scenario: we make a change to the infrastructure and a Kubernetes cluster is deleted. Fortunately the infrastructure is described in Terraform and (maybe) we get the cluster back quickly. Now we need to figure out what needs to be deployed. We trigger deploy pipelines and quickly realize some pipelines were deactivated, some worked but the application fails to start while others fail altogether. Recovery is not as smooth as we'd hoped.
In it's simplest definition, GitOps is the practice of using Git as the source of truth from which almost everything can be operated. By using Git (or another version control system) as the source of truth we gain things like version control, history, peer reviews and rollbacks. By having a declarative description of our operations we can, with more confidence, make and rollout changes as well as recover from failure because everything that needs to be operated is in version control.
GitOps principles
- The entire system described declarative - instead of having a set of actions to be performed (e.g. spin up this server, place this file at that location, install X service) we describe state (e.g. 1 server, this file at that location, X service running). A tool can look at this definition and reconciliate. Kubernetes is system that employs such practice;
- System state is versioned in Git - single source of truth from where everything can be derived and driven. Rollbacks can be done by using Git. Security guarantees with commit signing and authorship of changes;
- Changes can be approved and automatically rolled out and applied to the system - changes can be be automatically applied to the system. No need for cluster credentials to make a change to your system. This allows for separation between what needs to be done how it's done;
- Software agents alert on divergence and correctness - software agents can look at a system definition, alert on divergence and take the next step of reconciling. This also ensures the system is self-healing.
What can GitOps do for me?
- Increased Productivity - increased Mean Time to Deployment with automated, continuous reconciliation and integrated feedback loop;
- Enhanced Developer Experience - use of familiar tools (e.g. Git) to manage updates without needing to know the internals of the system (e.g. Kubernetes). Newly on-board team members can get up to speed and start making changes faster
- Improved Stability - audit log of changes outside of the system itself. Audit trail of who did what which can be used to meet compliance requirements and ensure stability;
- Higher Reliability - use of Git to revert/rollback and fork, gaining stable and reproducible changes. Allows for reduced Mean Time To Recovery (MTTR);
- Consistency and Standardization - consistent end-to-end workflows using the same tools and practices across the entire organization;
- Stronger Security Guarantees - authorship and origin of changes. Audit trail can be used for compliance. Divergence and reconciliation can be performed in a secure way.
GitOps CD Software Agents
With a declarative source of truth in Git, tools can be built to alert on divergence and reconcile state. Below are a few examples of what already exists out there.
- Flux - "Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories), and automating updates to configuration when there is new code to deploy";
- Argo CD - “Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes”
- Jenkins X - “Jenkins X provides pipeline automation, built-in GitOps, and preview environments to help teams collaborate and accelerate their software delivery at any scale”.
Is GitOps a silver bullet? Definitely not. It's just another practice to have in our arsenal to manage day-to-day operations. Take a look at GitOps Decisions by Ian Miell.
Top comments (0)