Putting Helm at the Heart of your GitOps Pipeline
An introduction to Helm for Kubernetes, explaining what a Helm chart is and how Helm can be used with GitOps.
Helm is a Kubernetes package manager designed to streamline the process of software delivery. The more frequently you deploy, the more time Helm can save you. In this article, we offer a basic outline of Helm and its benefits, alongside a host of useful links for those who wish to dive deeper, plus an introduction to using Helm as part of a GitOps pipeline.
What is Helm in Kubernetes?
Helm is an open source package manager, but it works with Kubernetes, rather than an operating system. Just like Kubernetes, you can run it anywhere, from your laptop to a public cloud. You can think of it as doing what APT, YUM or Homebrew do, but for Kubernetes clusters rather than a computer running Linux.
Helm works by bringing all your Kubernetes resources together into a single unit known as a Helm chart. You can use a Helm chart to deploy all your versioned, pre-configured application resources in one go, saving a great deal of the manual effort involved in deployment. When the time comes to deploy your next update, you just redeploy using your updated Helm chart.
You can learn more about the Helm project from its GitHub project page.
What are Helm Charts?
Contrary to what you might assume, a Helm chart is not a chart – at least, not in the sense of a graph or visual aid. It does have something in common with navigational charts, however (hence the name) in that it guides a system on how to install an application.
Helm charts are essentially packages for Kubernetes applications – and they must contain at least three things.
- A YAML file that describes the package (which should be named Chart.yaml).
- One (and often more) Helm templates, which in turn contain one or more Kubernetes manifest files (also YAML files). Note that a Helm chart often contains many template files – one for every separate component that needs to be deployed.
- Lastly, there is one further YAML file, called values.yaml, which contains the values that will be applied in each template file.
One of the great benefits of Helm is the ability it gives you to deploy the same application into different environments very quickly, just by overriding values.yaml to include the values needed for the target environment – but more on that later.
Once created, your Helm charts can be stored locally on disk, or they can be accessed from remote repositories, just like Debian or Red Hat packages. The Helm client will typically run on your local computer. Helm also supports OCI registries, which means your charts can be stored alongside your container images in the same registry, giving you one less piece of infrastructure to manage.
Why Do you Need Helm?
Writing your manifest files without using Helm will be much more arduous, as you will need at the very least one but likely more files for each environment, just to keep track of all the Kubernetes objects at work in your clusters. So that’s at least three YAML files to update for every deployment. With Helm, you still need to write the manifest, but Helm’s templating language means that, as we mentioned above, you can use a single Helm chart to deploy an application into different environments with different configurations, just by changing the values in one file. The more environments you need to deploy to, the more time you will save.
The Benefits of Using Helm
Helm has become immensely popular in the Kubernetes community because, like all successful package managers, it makes life significantly easier for developers and operators alike. Its benefits can be summarised as follows:
1- It’s faster
Using a Helm chart reduces the amount of manual work involved in a deployment. The alternative is a chain of actions that often need to be undertaken by a team of people, slowing down the process of deploying apps and updates.
2- It’s More Accurate
Often, all it takes to misconfigure an application is a typo. By packaging all your Kubernetes resources in a Helm chart, you can eliminate errors that might otherwise cause the deployment to fail. When you have a lot of dependencies, one configuration error can cause everything to fail – and it can take a lot of time to track down the source of the problem.
3- It Makes Applications Shareable
Helm charts make it easy for others to deploy your application as you intended – and that works both ways. You can pick up an application developed by someone else and packaged using Helm, and deploy it with similar ease.
4- It Cuts Complexity
Helm charts simplify the process of deploying software by automating a lot of configuration that would otherwise need to be done manually, by people intimately familiar with both the platform and the application. This reduction in complexity pays dividends when you’re under pressure to deploy frequently.
5- It Flattens the Learning Curve
Okay, so ‘flattening’ might be a slight exaggeration. But packaging everything into a Helm chart that can be deployed quickly and easily takes a great deal of the pain out of working with Kubernetes – especially for teams who are new to cloud native development. Because the hard work is done up front, when the Helm charts are created, it means that deployment can be easily delegated to less experienced team members – which means you can deploy more frequently with greater confidence.
6- It Can Mean Extra Management Functionality Without Extra Effort
Helm Charts can reference other charts, which can reference other charts, which can… you get the picture. In other words, you can use a Helm chart that not only deploys an application, but also that references a separate Helm chart that deploys one of its dependencies. So you could, for example, do helm install o11y and get Prometheus, Grafana, Loki, Promtail and even your own custom dashboards, into the bargain. This makes the deployment of everything you need to manage your application quicker and easier, while also ensuring you deploy the latest version of each component.
Installing Helm
The most important prerequisite for installing Helm is a Kubernetes cluster on which to put it to work. The current and only supported major version of Helm is v3. It’s recommended to install the latest release as it includes all the features mentioned above such as full OCI support.
You can learn more about how to install Helm in this step-by-step guide.
With Helm itself installed, you can find charts for commonly deployed Kubernetes applications on CNCF Artifact Hub. Alternatively, you can write your own charts – you can find out how to do that in the Developer’s Guide.
Using Helm with GitOps
GitOps is a set of tools and processes for the continuous delivery of software into a Kubernetes cluster. It applies the version control capabilities of Git to config as well as application code, while also leveraging the declarative nature of Kubernetes to automate many aspects of software deployment. Crucially, it uses a software agent called Weave GitOps (built on the open source tooling Flux) that sits between the information in Git and the production Kubernetes cluster, to reconcile any drift that occurs between the two.
Helm can be used as part of a GitOps pipeline to streamline the process even further. Weave GitOps has been designed to work with Helm and it will actively poll the relevant https or OCI repositories looking for Helm charts to use for your deployment.
Weave GitOps can also be configured to match semver patterns, so that whenever a new Helm chart becomes available for your application, it will be version-matched and, provided the match is successful, the deployment can then be made automatically. If you have your GitOps pipeline configured to send notifications (usually via Slack or email), you will be notified that the reconciliation was successful and your deployment went ahead as planned.
This clearly saves time with just one environment, but if you use the same chart to deploy across multiple clusters, all you need to do is reuse the same chart and make the requisite overrides to the values in the template files, enabling you to automate deployment across development, staging and production, for example.
Check out this article for a detailed, step-by-step guide to using Helm in a GitOps pipeline.
Conclusion
Helm is not the only way to deploy to Kubernetes clusters. But just as Kubernetes has become the de facto container orchestration system, Helm has quickly become the de facto application package manager for Kubernetes.
Free and open source, it offers numerous benefits, specifically around automating arduous manual work. As a result, it can make software deployment quicker and easier, while also simplifying the Kubernetes learning curve.
Like many applications in the Kubernetes ecosystem, Helm can be even more beneficial when used in conjunction with other tools and models that help to automate software delivery, especially GitOps.
GitOps is an operational framework for continuous application delivery, and it leverages both Helm and Weave GitOps to keep the Kubernetes clusters updated. Weave GitOps automates Helm chart releases by synchronizing Charts from Git to the Kubernetes clusters. To learn more about the use of Helm and GitOps, check out our blog post “Templates are indispensable for GitOps-driven automation with Helm.”
To learn more about what Helm and GitOps could help you achieve in your organization, contact us today.
Contact us TodayWhitepaper: GitOps Accelerates Self-service for Developers and Operators
Create and manage development environments and deliver a modern developer experience.
