The Official GitOps FAQ
The GitOps FAQ is a list of the most frequently asked questions and their answers around the practice of deploying and updating cloud native applications.
We’ve recently updated “The Kubernetes Library” with a brand new page called “The GitOps FAQ”. This is a living document that we intend to add to as we all learn more about this methodology for deploying and managing applications on Kubernetes.
There’s been a lot of discussion around GitOps in the community and out of this came many excellent questions -- particularly around the differences and similarities between GitOps, Continuous Delivery and Infrastructure as Code. This FAQ addresses some of those questions.
Here are a few of the questions that we’ve answered in the FAQ:
How does GitOps differ from Infrastructure as Code?
Infrastructure as code is a pattern, rather than a specific workflow. Today Infrastructure as Code (IaC), no matter how it was originally intended, has a lot of different meanings that have been implemented in a variety of ways.
GitOps is a prescriptive style of Infrastructure as Code for the cloud native era and it builds on and combines:
- Orchestration
- Observability
- Declarative Infrastructure as Code
- Containers and Immutable Infrastructure
- DevOps best practices
One of the main differences between IaC and GitOps is the use of immutable containers as deployable artefacts that can be converged on by a suitable orchestration tool, for example Kubernetes. Your desired state is kept in source control. This isn’t always the case with some of the infrastructure as code tools. IaC implementations vary, and sometimes the source of truth is split between a git repo, and a database, and sometimes spread between a weakly-linked union of multiple git repos.
For example, some configurations of Puppet do provide the same overall workflow as GitOps does, where changes are pushed and are converged on automatically. Some even use Puppet Master to alert when the infrastructure varies from what is defined, but that wasn’t widely done back when these tools were first implemented.
While Infrastructure as Code tools provide a way to manage infrastructure, they don’t manage the entire Cloud Native stack. GitOps on the other hand, allows you to manage the whole platform.
With GitOps you can use Infrastructure as Code tools to perform any infrastructure updates through Git. In our experience, Terraform works well with GitOps, but still requires some human oversight. So in this sense, GitOps extends the tradition of Infrastructure as Code tools.
Others have said that GitOps is an extension of infrastructure as Code like this article in the ACM journal: GitOps: A Path to More Self-service IT.
“GitOps is to Infrastructure as Code as Microservices are to SOA or XP is to Agile.”
-- Alexis Richardson, CEO of Weaveworks
What is the “convergence mechanism”?
When configuration updates are made through Git, the Kubernetes orchestrator keeps applying changes to the cluster until its state has converged with the updated configuration in Git. This model works for any Kubernetes resource and is also extensible using Kubernetes Custom Resource Definitions (CRDs).
When an update occurs, the following happens:
- The cluster is observed and compared with Git.
- On convergence a notification for deployment success is sent.
- On divergence an alert is sent and if set a convergence is triggered.
The mechanisms for this convergence can be communicated via Diff alerts in Terraform or via Weave Cloud’s deployment automator.
Can I use a CI server to orchestrate convergence in the cluster?
Your CI server is not an orchestration tool. You need something that continually attempts to make progress (until there are no more diffs). CI fails when it encounters a difference. In combination with a human operator, a CI server can be made to force convergence, but this creates other issues. For example your CI scripts might not be able to enforce an idempotent and/or atomic group of changes.
Also if something breaks (and it will) then you could end up being in a partial and unknown state that requires a full reboot to fix. It is easier to use dedicated orchestrators like Kubernetes and Terraform to provide convergence rather than relying on your CI tool to do that.
Final Thoughts
For the answers to more questions like these, head on over to the Official GitOps FAQ and if you have a question that you want answered on here, please don’t hesitate to contact us.
Need Help?
For the past 3 years, Kubernetes has been powering Weave Cloud, our operations as a service offering. You can have 24x7 access help from our team of Kubernetes experts to assist with your Kubernetes installation and set up. We’re happy to share our knowledge and help teams embrace the benefits of on-premise installations of Kubernetes and Istio.
See Weaveworks’ Professional Services for Kubernetes for details about our Kubernetes support packages.
