All about GitOps
GitOps is currently enjoying a period of peak attention in the DevOps community, but oftentimes AWS, EKS, GCP & GKE are the main CSPs. In this article we will cover Microsoft Azure – Azure Kubernetes Service. We will dive into what GitOps is, what it isn’t, how we can easily leverage GitOps through the FluxCD project on Microsoft Azure, whether you should use Microsoft’s implementation of GitOps or go straight to OSS, and finally look at certain areas to be aware of and considerations.
What GitOps is
The term GitOps itself was coined in 2017 at a company called Weaveworks by Alexis Richardson.
In GitOps, Git is the source of truth for the deployment of the application. Standard practice is to include Kubernetes manifests, Kustomize manifests, Helm charts or Terraform for the deployment of Infrastructure as Code (IaC), within that Git repo. You will then use another tool to manage this infrastructure into Kubernetes.
Around the GitOps pattern a plethora of tools have arrived in order to improve the developer experience, reducing the effort of uptaking the pattern.
Chief among these tools include GitOps Operators like FluxCD or ArgoCD which run on your Kubernetes Cluster.
What GitOps is not
GitOps is not a replacement for IaC + MRs (Merge RequestS) + CI/CD (Continuous Integration/Continuous Delivery). Nor does it alone enhance delivery into the realms of progress delivery or continuous deployment. GitOps is not really for the building of an application but rather for the deployment of the application from Kubernetes manifests, Helm charts, Git repositories, and in the case of some operators – Terraform.
However, the GitOps pattern has led to the development of additional tooling for progressive delivery – tools such as Flagger, Argo Rollouts and SaaS tooling like LaunchDarkly, Harness.io.
At a high level, when we say “progressive delivery” or “continuous deployment” we think of software being deployed automatically using mechanisms such as Blue/Green or Canary Deployment, using an ingress controller or service mesh, to a subset of users and monitored for errors, or feedback which dictate further progress with / without a human operator.
GitOps is also not the only method of enhancing continuous delivery. There are tools such as Spinnaker or Humatic which enhance pre-existing pipelines to deploy the application. Tools such as these rely upon push notifications from CI/CD pipelines, changes to images, approval gates.
How do I move GitOps forward on Azure?
So how do you bring GitOps to your Microsoft Azure AKS Cluster? The first step in this process is to choose your GitOps Operator. As mentioned previously some well known OSS GitOps Operators include FluxCD and ArgoCD.
You will also need a Git Repository of your choosing. Azure DevOps, GitLab, and GitHub all will serve in this space.
Within Azure itself Microsoft offers an implementation of the CNCF GitOps Operator – FluxCD for customers. It is installed and configured as an extension to an MSI-based AKS cluster.
The extension can be deployed through Azure Resource Manager (ARM) or Bicep templates, Azure Powershell, or Azure Cli. As of writing it hasn’t made its way into a Terraform provider.
Some areas to consider with the FluxCD extension on Azure:
- There is no cost for the use of this extension in an AKS Cluster unless you start using Azure Arc-enabled Kubernetes beyond 6 VCPUs
- Supports multi-tenancy
- It is easy to deploy the extension to your AKS cluster
- It uses ARM/Bicep for the configuration which is easily configurable in a CI/CD pipeline
- ARM/Bicep documentation is not as great as the Flux OSS and you don’t know how much is implemented at Microsoft compared to OSS, so be prepared to do some digging.
- Microsoft provides some excellent tutorials on using the Fluxv2 extension in Azure and CI/CD with GitOps.
- Can configure webhooks in FluxCD to Slack, Microsoft Teams, Discord or Rocket webhook for alerting on GitOps pipeline status
If you prefer, you can also install it yourself directly from the CNCF Helm charts or the Terraform registry and without the Microsoft implementation. There are pros and cons to this choice:
- It is free and easy to deploy through the install guide
- Supports multi-tenancy
- The configuration of Flux is well documented on Fluxcd.io
- Has good community
- Lacks vendor support; if there are problems your only recourse for support is Slack
- Can configure webhooks in FluxCD to Slack, Microsoft Teams, Discord or Rocket webhook for alerting on GitOps pipeline status
Other GitOps considerations
There are some elements to beware of when implementing GitOps: secrets and imperative changes.
It is not best practice to store secrets in Git. As we know, secrets are base64 encoded and not encrypted in git; these are not true secrets. So your organisation must explore other methods of secret management. Common methods of secret management that exist include Azure Keyvault Secrets Provider, Hashicorp Vault agent or Container Storage Interface (CSI). We can also explore sealed secrets whereby the secret is stored in Git, however it is encrypted, and unreadable to anyone browsing the repository and the private key used to encrypt / decrypt it is stored away from Git.
GitOps very much favours declarative changes, our Git being a source of truth. So imperative changes are an anathema. Therefore imperative changes to resources managed by Flux such as kubectl edit or applying manifests will not survive a reconciliation by Flux of the configuration in Git. Consider hand-in-hand with Flux reducing the ability of developers, application to make manual changes and avoid unwelcome outcomes.
Learn to love Kustomize for setting up your declarative management of Kubernetes objects and really enhance your working experience with GitOps. It allows you to structure your GitOps repository to suit your development needs whilst not closing the door to using HelmRelease and Helm charts in GitOps.
GitOps Summary
In summary, we have covered how GitOps as a pattern can be implemented in an organisation seeking to simplify the deployment of an application to a Kubernetes cluster. This can be done through existing tools and scripting. However, choosing a tool specific to that purpose can reduce the level of effort required by developers.
Whilst other tools are available, Flux is an easy option for Developers on the Microsoft Azure platform to get started. That is not to say that it will suit all needs, indeed you can deploy pretty much any current GitOps tooling to your AKS Cluster. However it is generally available and will surely grow in popularity among users of the Microsoft Azure Cloud.
Lastly, the idea of using Git as the source of truth returns the deployment process to a series of Merge Requests in a familiar environment – Git. No requirement to use Terraform, scripting, Helm charts through CI/CD plugins or tasks directly. Just a standard tool any Developer will be comfortable with.
For more information, please contact michael.spinks@cloudreach.com
