Templates are indispensable for GitOps-driven automation with Helm
Let’s explore why Helm is fast becoming an indispensable tool for GitOps. We’ll look at one of its major benefits: templates.
Kubernetes gained popularity as it simplifies the scalability and management of containerized applications. It enables you to deploy and manage nodes, pods, containers, services, and configuration maps across the entire application lifecycle. It was difficult to achieve such flexibility and control with scripts. But thanks to Kubernetes’ declarative approach to infrastructure, you can define precise changes at any scale. Kubernetes also empowers you to integrate multiple tools to facilitate automated scheduling, deployment, monitoring for the containers. One such tool is Helm, a CNCF adopted automation framework that has gained popularity not just in Kubernetes circles, but in the GitOps ecosystem as well. In this post, we look at how Helm helps automate the deployment of cloud-native applications on Kubernetes the GitOps way.
What is Helm?
Although described as a package manager, Helm is a powerful tool to automate installation, deployment, upgrade and management of Kubernetes applications. Managing Kubernetes manifests is a task that grows in complexity as systems scale. A single deployment needs multiple YAML files with duplicated and hardcoded values. This required a better way to manage Kubernetes YAML files through a simple packaging format, which led to Helm Charts. However, Helm’s scope goes beyond templating.
Charts
Helm Charts are deployable units for Kubernetes applications. Each chart can contain the files, metadata, and infrastructure of the application. Written in Go, Charts are stored in specific template directories along with associated variables, versions, and descriptions. These Charts can be shared across your development team for reusability by storing them as archives in a Repository.
Once a copy of a Chart is installed in the Kubernetes cluster, it is called a Release. A new release is created every time the Chart is deployed, which can happen multiple times. Releases help you track and install Charts.
Below are some of the key terms to know when working with Helm.
- Chart.yaml: The main file that holds the description of your chart
- Values.yaml: A file that contains the default values of your chart
- Charts: A directory that houses sub-charts
- Templates: A directory where Kubernetes resources are defined as templates
Templates
A Templates folder is an important aspect of Helm. It contains the application’s configuration files, which will be deployed to the cluster. The files within the templates directory call their values from values.yaml.
Why Helm?
Helm adds great value to a continuous delivery ecosystem as it brings the below benefits.
Improved productivity:
Simplifies process:
Scalability:
Easy rollback:
Helm (along with other deployment tools like Flux) allows you to deploy software with just a click of a button or a single command. This will help your team to direct focus solely on software development.
The concept of charts allows you to duplicate the same chart across the pipeline - development, test, and production - or across different teams’ workflow. This significantly reduces complexity.
Charts are designed to align with Kubernetes cluster architecture, which eases scalability.
Since Helm manages all releases, it helps you roll back changes easily when there are issues.
GitOps leverages both Helm & Flux
Helm can manage complex releases and keep things simple as you scale. However, when changes are introduced progressively, Helm will need additional tools to keep the Kubernetes cluster updated. Flux is a great complementary solution to Helm as it acts as a bridge between Helm and the all-important Git repositories from where the entire Kubernetes cluster and app spec are defined.
Flux is a deployment automation solution based on the GitOps model that puts Git in focus as the starting point, and source of truth for all changes. Flux enables you to maintain consistency between code repositories and Kubernetes clusters, and automates deployments when code changes are introduced.
In a nutshell, Flux automates Helm Chart releases by synchronizing Charts from Git to the Kubernetes cluster.
How does Flux work with Helm?
In order to use Flux as the GitOps operator, you store all Helm Charts along with their YAML files and Kubernetes custom resources in a Git repository. Also, you push immutable images of these resources to a container registry.
Once you commit a change in Git via a 'pull’ request, Flux checks your repository and provides the required resources. The changes are then merged into the production cluster. This, of course, simplifies the process and there is a lot more you can do along the way - such as run smoke tests, or have an SRE approve specific changes - but we’ll keep it simple for now.
If you want to learn more about how Flux 2 and Helm work together to increase velocity, and reliability while decreasing downtime, watch this youtube talk by Scott Rigby.
Things to watch out for: Security guardrails
Both Helm and Flux ensure that a single source of truth is maintained through a Git-based source control system. They ensure that the system remains in sync with the desired state via templates and manifests stored in repositories. However, adding effective security guardrails is critical to prevent misconfigurations
To better understand security implications, identify risks and implement best practices, it takes a policy-based security enforcement platform like Magalix. Magalix will check Helm charts against 100s of out-of-the-box policies for Kubernetes deployments and deliver immediate feedback on policy violations. It enables visibility into Kubernetes clusters and enforces security and compliance policies - such as CIS, PCI DSS, and MITRE ATT&CK - policies on deployments.
Conclusion
Helm reduces the complexity of operating Kubernetes significantly. It adds great value to the GitOps pipeline with the concept of Charts or templates. Having said so, there are other needs beyond templating, such as end-to-end deployment automation. This is where a tool like Flux (or Weave GitOps, which is built on Flux) is essential to make the most of Helm. Additionally, a solution like Magalix ensures Helm releases are compliant and secure.
Weave GitOps is a continuous delivery solution that helps manage Kubernetes at scale. It eases the adoption and execution of GitOps in any organization. Weave GitOps simplifies operations cluster with commands such as ‘gitops install’ to enable GitOps and ‘gitops add app’ to add your application. These commands abstract away the underlying complex tasks that are otherwise involved in deployment automation. Weave GitOps brings together the entire GitOps pipeline including Helm, Flux, Magalix, and more - so you can get started with GitOps without wasting any time.
