Despite GitOps being a relatively new methodology for delivering software application deployments in cloud-native environments, organisations, large and small, have started to adopt GitOps as their preferred approach to application deployment on Kubernetes.
GitOps is a relatively new methodology for delivering software application deployments in cloud-native environments; that's both, installs and updates. The coining of the term has been attributed to Alexis Richardson, the CEO of the cloud-native company, Weaveworks. Back then in 2017, 'GitOps' had a very loose definition, but ultimately described a system of management that involved:
On the face of it, this approach to application deployments has a lot of synergy with the way that Kubernetes gets things done. Kubernetes requires developers to describe how their applications are going to run, using declarative configuration that defines the various API objects; Deployments, Services, Ingresses, NetworkPolicies, and so on. It also uses control loops to drive the system towards the desired state expressed by the API resources.
But back in 2016, this nascent approach had little rigour or formalism. Thankfully, the GitOps community has come a long way since those early days. Collaboration has enabled the community to coalesce around a formal meaning of the term GitOps, whilst competing open source projects have created tools that implement the principles associated with GitOps. Meanwhile, organisations, large and small, have started to adopt GitOps as their preferred approach to application deployment on Kubernetes.
The OpenGitOps project is an initiative that seeks to provide a reference for GitOps, in terms of its meaning, its promotion as a methodology, and as a source for education and best practices. It's vendor neutral, and is governed by the GitOps Working Group, a part of the Cloud Native Computing Foundation (CNCF).
So, what is GitOps, and what characterises a system that is managed the GitOps way? Helpfully, OpenGitOps defines a core set of principles that describes how GitOps should be applied to a system.
Adopting these principles provide a GitOps adopter with a number of potential benefits:
Sometimes in the software industry
it's difficult to say what came first; the tool that pioneered a methodology,
or a methodology that produced a pervasive tool(s). With GitOps, it's
definitely a mixture of both. The two main GitOps tools in the Kubernetes
domain are Argo CD and Flux, each of which has implemented the GitOps
principles, but also informed their definition.
Argo CD is part of a wider family of
open source tools that exist under the 'Argo'
umbrella, whose aim is to make it easier to run and manage workloads on
Kubernetes. The Argo projects are maintained by a number of different
companies, including Red Hat, but Argo was originally formulated by Intuit.
Argo CD was introduced in 2018 to fix a requirement to allow for the rapid, reliable deployment of hundreds of microservices across a fleet of Kubernetes clusters. Since its introduction, it has matured, adapted, and evolved into a mature GitOps solution. It has been adopted by literally hundreds of organisations, both large, and small. It consists of an API server for administering Argo CD, a repository server for fetching the desired state and 'hydrating' Kubernetes resource abstractions (e.g. Helm charts), and an application controller for reconciling state. Amongst a number of other features, Argo CD also supplies a web UI for visualising and controlling Argo CD in its management of applications.
Flux is the other popular GitOps
solution, and is a collection of
tools that interoperate to provide a GitOps solution. Perhaps as a
testament to the way that the GitOps discipline has evolved, Flux first
appeared in 2017, gained a sizeable following, but has subsequently been
rewritten from the ground up. Flux v2 has been implemented using a modular
approach, and incorporates many of the lessons learned from the early adopters
of Flux v1, and the general maturing of the GitOps discipline.
Each of the different toolkit components that Flux is comprised of, uses custom resources to describe the facet it manages. For example, the source controller works from GitRepository
resources in order to know where to fetch the desired state from. And, the kustomize controller works with Kustomization
resources in order to generate and apply the Kubernetes configuration to the cluster.
Whilst Flux has yet to reach the status of general availability, it already has a large number of commercial adopters.
When configured well, GitOps tools can
bring great benefits to organisations wanting to speed up application delivery
by automating deployments. But a word of caution; technology alone doesn't
solve a problem. To properly realise the benefits of GitOps, an organisation
must also have a mature CI/CD capability for application delivery, with the
internal processes and team responsibilities clearly mapped out. Without this,
you'll be pouring petrol on the fire with GitOps. However, once an organisation
has matured its workflow, and established clear lines of responsibility, GitOps
has the ability to turbocharge application delivery on Kubernetes.
If you found this article interesting you might be interested in our GitOps Training Course.