There have been a number of recent discussion and some innovation around charts for Helm, the popular package manager for Kubernetes. Given the number of discussions going on along with planning for Helm v3 that will be happening soon, I wanted to take a moment to talk about how we got here and what the options are for chart hosting exist today.
How Helm Natively Works
Out of the box, Helm comes with the ability to create a chart repository that can be accessed by one or more clients. This repository can be hosted by a static web server, an object storage service, or something similar.
While not a direct clone, the out of the box experience was designed based on Debian. If you’ve used apt-get to install packages on Ubuntu the underlying mechanisms are similar. You can add repos, you can update the knowledge of the repos packages, and you can install them. Just like with Debian (and Ubuntu), when you add or update a repo a file is downloaded with all the details about the packages.
On a Helm repo site there are one or more chart versions packaged as .tgz files along with an index.yaml file containing metadata about all the charts and their versions. While this setup may seem simple, it has proven to work with Debian and Ubuntu with a known scalability model.
If you’re interested in using the build in Helm repository tools there is a guide in the Helm documentation.
App Registry
Kubernetes is a container manager. Container images are distributed in a model that is fairly different from the way Debian and Ubuntu packages are. The model is the way Docker Hub, Quay, and private registries all work. A model founded by Docker.
App Registry comes from the team at Quay as a way to share charts (and applications in a broader context) the same way container images are shared.
App Registry is made up of a server, specification, and client to talk with a server. The client is even available as a Helm plugin. The folks at Quay have implemented the spec on Quay itself (you can read about it here, here, and here).
The way charts are moved around and stored is different than how Helm 2.x works. Charts are pushed and pulled from an app registry. There is no index with all the charts and no way to search for them from the client. But, it is very similar to the way we handle container images and Quay has implemented authentication so that private apps can have the same level of access control as private images (this would be nice in the open source version).
This model is gaining a lot of traction and popularity.
Chartmuseum
A recent addition to the chart server discussion is ChartMuseum. ChartMuseum provides the same API to Helm clients that a native chart repo provides. That is an index.yaml file and packages stored as .tgz files.
But, it goes beyond what core Helm provides. It implements API CRUD operations to upload, delete, and otherwise manage chart versions. Instead of being static, this chart repository is dynamic.
To store files, this project has support for multiple cloud storage back-ends such as Google Cloud Storage and Amazon S3.
Which Should You Pick?
From a long term perspective, the jury is still out. I would hope that any change to charts for Helm 3 would have a certain amount of backward compatibility for Helm 2. There may be a future where both systems live side by side in core Helm. My suggestion is to take a look at the options and make a decision for yourself. If you have feedback for an individual project please take the time to share it with them.