Helm Repository Best Practices

Wouldn’t it be great if there were a way to deploy applications on Kubernetes as quickly and easily as you can deploy them on traditional operating systems using package managers like apt and dnf? Fortunately, there is: It’s called Helm, and it provides an efficient way to package Kubernetes applications, store them in Helm repositories and deploy them into your clusters.

Here’s a primer on how Helm works and which best practices to consider when working with Helm charts inside a Helm repository.

What is Helm?

Helm is an open source platform for packaging and deploying applications on Kubernetes.

Helm lets developers package applications into a format known as charts. A Helm chart contains all of the files and configuration data necessary to deploy an application (or a set of applications) into Kubernetes.

Helm is not mandatory to deploy Kubernetes applications, as you can deploy manually with kubectl. But, if you have many applications to deploy, and you need to redeploy frequently as your applications are updated, manual deployment can be tedious and inefficient.

Helm solves this problem by allowing complex applications to be deployed quickly and, if desired, automatically.

What is a Helm repository?

A Helm repository is a collection of Helm charts. Developers can upload charts to a Helm repository, and users can download them from there.

The ability to share charts using a repository is another advantage of Helm. Helm repositories make it easy for developers to share their applications with users, and for users to find the applications they need, in a centralized location. Without Helm repositories, users would be left to scour GitHub manually when looking for the charts they need to deploy applications on Kubernetes.

Artifact Hub (which was previously known as Helm Hub) is probably the most widely used Helm repository. It’s an open source repository managed by the Cloud Native Computing Foundation, a major open source community organization.

However, Artifact Hub is by no means the only place to share and download Helm charts. You can also create your own Helm repository using a platform like JFrog Artifactory, which provides access control features, integrations and other enhancements not available from all Helm repositories.

Best practices for working with Helm repositories

Whichever platform you use, there are several key factors to consider when creating and managing a Helm repository and managing charts in it.

Granular access control. Unless your application is designed for use by the public at large, you should configure granular access controls so that you can restrict who is able to download and run it. A single Helm repository could contain charts that require varying levels of access. Some may be for one unit of your business while others should be available only to those in another unit, for example, or some may be for external users while others are for your in-house engineering team.

Granular access control lets you define exactly who can use which charts and avoid sharing charts with parties who should not have access.

Local and remote repository aggregation. In some cases, you may wish to use Helm charts from third-party repositories while at the same time maintaining your own local chart repository. The most secure and efficient way to do this is to aggregate both types of repositories — remote and local ones — into a single “virtual” repository.

That way, your developers and users can upload and download whichever packages they need from the virtual repository, without having to navigate between different Helm repositories. Virtual repositories also allow you to apply extra security protections to charts stored in remote repositories, which would not be possible if your users downloaded charts from those repositories directly.

Helm version support. The Helm framework is under active development. Each new version has historically brought major changes to the way Helm charts are packaged and deployed.

Currently, Helm v3 is the only actively supported version. But Helm v2 charts still exist, and may still be needed for working with legacy environments. What’s more, in the future, it’s possible that a newer Helm release will require organizations to use both Helm v3 and Helm v4 (or later) charts at the same time.

When creating a Helm repository, consider the Helm version support and ensure the repository provides the flexibility to manage charts created for whichever versions of Helm you need, now and in the future.

Support for multiple sites. If your developers and users are dispersed across multiple geographic sites, you can best support their needs by building a Helm repository that provides advanced replication options and integrated disaster recovery so that if one instance of your repository fails, charts will remain available.

Getting the most from a Helm repository

If you’re experimenting with Helm charts for the first time, a public repository like Artifact Hub is the best place to start.

But if you need an enterprise-ready, feature-rich Helm repository that gives you full control over security and disaster recovery, consider Artifactory, which supports Helm repositories that you can deploy in any data center or cloud and automate using the Artifactory REST API or JFrog CLI.