There is a new kid on the block, and I am not talking about a collaboration with the Backstreet Boys here. DevOps has a new buzz word and that word is GitOps, but what is it and why should I care?
What is GitOps?
At its foundation, it is a method of embedding the implementation of Continuous Deployment into operational environments. It is the embodiment of the mantra You built it, you run it or to be more precise, it is a paradigm to allow the closing of the circle and allowing the developers to actually ship their code directly into production.
What?
This concept scares me at a base level, as somebody who has come from an operational position and moved left towards development, the thought of allowing developers free reign of a production environment is scary on the level of the zombie apocalypse, scary on the level of allowing the machines to become sentient. Something that can result in the world becoming barren and devoid of all life.
But as the saying goes life is change, and the only constant is that change is inevitable. So let’s delve a little deeper into the concept known as GitOps. And who better to give us a bit of insight than Kelsey Hightower of Kubernetes fame.
“GitOps: versioned CI/CD on top of declarative infrastructure. Stop scripting and start shipping”
The fact that this quote is from the godfather of Kubernetes, should give you an idea of where GitOps’ main focus is directed. GitOps is a way to manage Kubernetes cluster management and application delivery; it is an operating model for building and delivering cloud-native applications. It is not just a Kubernetes play though, as the concept can be expanded past container delivered applications into the Serverless world or anything that is deployed by using automated workflows.
The Principles of GitOps
There are four main principles of GitOps and these are:
The entire system is described declaratively
For those working with IaC products like Terraform and Ansible the concept declarative code should be known and understood. Tools like Kubernetes are another example of cloud-native tooling that are declarative in nature and that can be treated as code.
Declarative means that all configuration is guaranteed by a set of facts rather than a set of instructions. Having application declarations stored and versioned in Git means that there is a single source of truth. Applications can then be deployed and/or rolled back. And even more importantly, when a disaster strikes, the cluster’s infrastructure can also be dependably and quickly reproduced.
The canonical desired system state is versioned in Git
Declaring a system and storing it within a version control system serves as a canonical source of truth, there is a single place from which everything is derived and driven. This trivializes rollbacks; where a simple `Git revert` will allow the recovery from a failed code deploy by reverting to the previous application state. Coupled with Git’s excellent security guarantees, a personal SSH key can be used to sign commits that enforce the strong security guarantees about the authorship and provenance of code.
Changes that are approved can be automatically applied to the system
Once declared state is stored in Git, the next step is to allow any approved changes to that state to be automatically applied to production systems. Now surely any CI/CD system should do this but what is significant about this form the perspective of GitOps is that there is no requirement for cluster credentials to make a change to the system. One of the premises of GitOps is that there is a segregated environment where the state definition lives. This allows the separation of what is to be done from how it is to be done.
Software agents are or can be used to ensure compliance with desired state and report and react to divergence.
Once the state of your system is declared and kept under version control, software agents can be used to inform whenever reality doesn’t match the stated expectations. The use of agents also ensures that the entire system is self-healing. And by self-healing, we are not talking about node or pods failure—those are handled by Kubernetes—but a much broader sense, for example human error, where the software agents will act as the feedback and control loop for your operations.
Why should I care about GitOps?
Chances are if your environment is using DevOps as its deployment strategy, you are most likely already quite far down the GitOps path only you did not realize it. A large part of the DevOps journey is defining the strategy, defining the tools, the vast majority of environments has settled on a form of Git as their version control systems. By utilizing the benefits of Git’s inbuilt version control to manage the state of the application as Code deploy to Kubernetes becomes as simple as committing a Merge request, this empowers the developer of the application to deliver their code into production and because everything is being done through their version control system it is the single source of truth, both for code but also for audit of who did what when from the perspective of both development and operational deployment. There are the checks and balances associated with the VCS which can help alleviate the scare factor of having developers so close to the sharp end. However there are still limitations associated with day one and day two operations, but that is also an issue with DevOps generally too.
Summary
Currently GitOps is a subset of Devops, however there is a growing perception that it is the future of DevOps, because it is both a cloud-native approach to configuration-management and it is declarative, so it dovetails nicely into IaC practices as used by languages such as Terraform and Ansible etc. However, moving the operational part of DevOps even further towards the developer does worry me somewhat, the lack of operational rigor with the average developer means that there is often no consideration given to operational controls post-deployment, if it deploys it is successful, but what about any business resilience, or disaster recovery considerations. That said from the perspective of application deployment it makes sense, in a cloud-native world applications are stateless, there for BC/DR from the position of an application is covered with GitOps and IaC. Is this is another nail in the coffin of a traditional Operations department in the Cloud Native world, Yes it is, but then again many nails have already been driven into this coffin outside of legacy infrastructure operations as we know it is dead, there is only development.
