Skip to Sidebar Skip to Content

Uploading a Helm Chart

Uploading a Helm Chart

Highlights

  • Core Concept: Discover what a Helm chart repository is and how it hosts your packaged applications.
  • Modern Alternatives: Understand how traditional repositories differ from an OCI-compliant Helm chart registry.
  • Preparation & Transfer: Learn how to create an index.yaml file and prepare your Helm package upload.
  • Command Mastery: Master the essential Helm CLI commands needed to index, add, and update your repositories.
  • End-to-End Workflow: See how to successfully push Helm chart archives online and execute a seamless Helm chart deployment.

Once you have finalized and signed your Helm chart, the subsequent task is to distribute it online. This enables your users to effortlessly install it by executing a single command. Consequently, your chart can be easily shared and installed, guaranteeing that your users are utilizing the most up-to-date version of your application.

In this blog, you will learn what a Helm chart repository is, how to create an index file, and how to upload Helm chart files. You'll also see how to use the uploaded chart.

Learn how to create a Helm Chart from this blog: What is a Helm Chart? An Absolute Beginners' Guide - with Examples

What is a Helm Chart Repository?

A Helm chart repository serves as a platform for hosting and sharing Helm charts, which facilitates the accessibility of these charts to users. A repository comprises a set of versioned and well-organized charts, enabling effortless navigation and search.

Chart repositories can be hosted on multiple platforms, including GitHub, AWS S3, and Google Cloud Storage. Once a chart is uploaded to a repository, it can be installed through a straightforward Helm command using a URL like helm install my-release our-repo/nginx.

Generally, our chart repositories will contain these things:

  1. The packaged chart. In our case, this is the nginx-0.1.0.tgz file we created earlier.
  2. The index file. This file contains information about the chart repository, the charts it contains, the checksums for our .tgz files, descriptions, and so on. This is the file that Helm will read when we add a new repository with a command like helm repo add our-repo https://example.com/ourcompany/charts. We’ll soon take a look at what content we have here so that we understand it better.
  3. (Optional) The provenance file. This file is for users who want to verify cryptographic signatures. They do this to be sure they downloaded the content approved by the author and not some potentially malicious content that some attacker could have uploaded to a compromised server.

Let us now look at how to create the index file.

Generating the Index File

To generate the index file, we first need to know where we will upload Helm chart files. In our exercise, we'll assume we have a web server accessible at https://example.com and we'll upload the charts at https://example.com/charts.

Grouping Chart Files in a Local Directory

Let’s create a directory where we can group the files that we’ll upload to our online repository.

mkdir nginx-chart-files

Assuming we already have our archived chart and our provenance files, we can copy those to our directory using this command:

cp nginx-0.1.0.tgz nginx-0.1.0.tgz.prov nginx-chart-files/

Finally, we can generate the index file using the command below:

helm repo index nginx-chart-files/ --url https://example.com/charts

We can see the syntax of the command is straightforward. After repo index we point to the directory that contains our archived charts and provenance files, nginx-chart-files/. Finally, we’ve decided we will be uploading our charts to a location accessible at https://example.com/charts so we pass that to the --url parameter.

We now have this structure in our directory:

nginx-chart-files/
├── index.yaml
├── nginx-0.1.0.tgz
└── nginx-0.1.0.tgz.prov

Let’s take a look at the mysterious index.yaml file.

apiVersion: v1
entries:
  nginx:
  - apiVersion: v2
    appVersion: 1.16.0
    created: "2021-07-03T21:59:00.34571153-04:00"
    description: Basic Nginx website for our company
    digest: b22a325b03c8e88b6a6a8d1a8e79f5d0498813855174a983426466b6de5a5f71
    maintainers:
    - email: john@example.com
      name: John Smith
    name: nginx
    type: application
    urls:
    - https://example.com/charts/nginx-0.1.0.tgz
    version: 0.1.0
generated: "2021-07-03T21:59:00.345199016-04:00"

The info we see here is pretty straightforward. As far as the Helm tool is concerned, the urls: section is the most important. This tells it the locations from where it can download charts whenever users want to install something from this repository.

urls:
    - https://example.com/charts/nginx-0.1.0.tgz

Uploading Charts

You are free to upload your charts wherever you want. We recommend a web server that you control or a service like Google Cloud Storage (GCS) bucket, Amazon S3 bucket, DigitalOcean Object Storage, and so on. These services are very cost-effective and super-easy to maintain. You could upload the files to GitHub Pages but the process is slightly more complicated (although easy if you’re already familiar with how GitHub operates).

(Note: In modern environments, teams often push Helm chart packages to an OCI-compliant Helm chart registry instead of an HTTP server, but HTTP repositories remain incredibly common and easy to use).

In our case, we can quickly simulate that we have a web server somewhere. We’ll just install a simple Nginx web server locally.

sudo apt update && sudo apt install nginx

Next, we’ll add this line to the end of our /etc/hosts file: 127.0.1.99 example.com. What this does is instruct our local machine to consider that example.com has the IP address of our local machine (127.0.1.* just points back to our own computer/virtual machine).

sudo sh -c "echo '127.0.1.99       example.com' >> /etc/hosts"

Great! Our web server is running and will be accessible (from our local machine) at http://example.com.

To keep things simple, we won’t enable HTTPS on our Nginx web server. For our special case, let’s regenerate the index file to point to http:// instead of https://. But remember, in real scenarios, always use https:// if possible. (With most online web services to host your files, you will have HTTPS available). So if you’re using an online service with this available, you can skip directly to the part where we are uploading files.

helm repo index nginx-chart-files/ --url http://example.com/charts

Our Nginx web server, by default, makes files stored in /var/www/html available to web visitors. So let’s create the charts directory there so that Helm can later download its content from http://example.com/charts.

Finally, we can “publish” our chart by copying

  1. the chart .tgz archive
  2. the index.yaml file
  3. and the provenance file to that location.
sudo cp nginx-chart-files/* /var/www/html/charts

And that’s it, job done! Once we have these files online, users can start using them in production.

Using Our Newly Created Helm Repository

Let's assume we're one of these users. We want to use this cool new Helm chart repository. Just like we would with a repository from Bitnami, we use standard Helm CLI commands and add it with helm repo add.

helm repo add our-cool-charts http://example.com/charts

We can now see that this was successfully added to Helm’s list of known online repositories.

user@debian:~$ helm repo list
NAME           	URL                               
bitnami        	https://charts.bitnami.com/bitnami
our-cool-charts	http://example.com/charts

In a real scenario, before we install a chart we want to make sure we have the latest data available about the repositories’ content (in case updated charts have appeared since we last refreshed this data).

helm repo update

And we can initiate our Helm chart deployment by installing our nginx chart:

helm install my-new-release our-cool-charts/nginx

And kubectl get pods shows us that we achieved our mission: installed a Helm chart from the online repository we created from scratch!

user@debian:~$ kubectl get pods
NAME                                    READY   STATUS    RESTARTS   AGE
my-new-release-nginx-85cb977469-kwh6b   1/1     Running   0          12s

Uploading New Charts

In a real scenario, we’ll keep updating our charts. When we generate a new index file, this will overwrite the old index file and point to our latest chart. This basically means that a helm install command can only install the latest chart we uploaded, as it does not see the older entries.

Sometimes, though, we may want to give our users the option to download older charts if they still need them. So instead of generating a new index file that points to the latest chart, we want to simply add new content to our existing index file. This way, our older entries remain visible/accessible to Helm.

Let’s imagine we updated our chart.

cp nginx-chart-files/nginx-0.1.0.tgz nginx-chart-files/nginx-0.1.1.tgz

We now have a new nginx-0.1.1.tgz an imaginary upgrade to our nginx-0.1.0.tgz chart. Remember, in a real scenario, we would have more work to do like also bumping up the version number in Chart.yaml.

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.1.0 <--This should be changed to 0.1.1 in a real scenario

To let our index file know about the newer entries, but also keep a record of the older ones, we use the extra --merge parameter where we specify the path of the index.yaml file that we want to update with the new info.

helm repo index nginx-chart-files/ --url http://example.com/charts --merge nginx-chart-files/index.yaml

Remember to use --url https:// in production instead of the http:// from this example. At this point, you would upload Helm chart nginx-0.1.1.tgz to example.com/charts, and upload the new index.yaml file (overwriting the older one in the process) and your users can now download both versions of the chart.

Checkout the Helm for the Absolute Beginners course

Helm for Beginners | KodeKloud
Learn and get certified with simple and easy hands-on labs

Conclusion

A Helm chart repository is a platform that enables users to host and share their Helm charts. It comprises a collection of versioned and well-organized charts, making it effortless to browse and search. GitHub, AWS S3, and Google Cloud Storage are other platforms where the repository can be hosted.

After uploading the chart, installation is a breeze with a straightforward Helm command using a URL. The repository comprises the packed chart, index file, and the optional provenance file, which users can use to authenticate cryptographic signatures.


More on Helm:


FAQs

Q1: What exactly is a Helm chart repository?

A repository is an HTTP server that houses an index.yaml file and a collection of packaged Helm charts (.tgz files). It allows users to browse, search, and download your charts.

Q2: How does a repository differ from a Helm chart registry?

While a traditional repository uses HTTP and an index.yaml file, a modern Helm chart registry uses OCI (Open Container Initiative) standards. This allows you to store Helm charts in the exact same registries used for Docker images (like AWS ECR or Docker Hub).

Q3: What happens during a Helm package upload?

During an upload, you transfer your .tgz chart archive and your updated index.yaml file to your hosting provider (like an S3 bucket or Nginx server) so remote users can access it.

Q4: What are the essential Helm CLI commands for interacting with repositories?

The most critical Helm CLI commands are helm repo index (to generate the index.yaml), helm repo add (to link the remote repo locally), and helm repo update (to fetch the latest chart metadata).

Q5: How do I actually push Helm chart versions and run a deployment?

If using a traditional repo, you copy or upload the files manually. If using an OCI registry, you use the helm push command. Once uploaded, any user can execute a Helm chart deployment by running helm install <release-name> <repo>/<chart>.

Mumshad Mannambeth Mumshad Mannambeth
Mumshad is passionate about sharing his knowledge on DevOps and Cloud & Automation technologies. He believes the best way to learn is to learn by doing and in a fun way.

Subscribe to Newsletter

Join me on this exciting journey as we explore the boundless world of web design together.