Carolyn Van Slyck

Publish Helm Charts to Azure Storage

I’d like to share my magic script, passed down from repo to repo, for publishing Helm charts to Azure storage during a CI build. I’ve used this most recently for the Athens project, but it has made an appearance with Minibroker, and nearly everything I’ve worked on with a Helm chart lately.

Just last night I was seriously considering rolling it into my tiny azure cli so that it didn’t need to be a script at all. But a girl’s gotta blog, so here’s the magic steps for making this work on your next project!

Gophers on the Azure Logo
pew! pew!

  1. Get a free Azure account. 💰

  2. Create a blob storage account.

  3. Create a public container in the storage account named charts.

  4. Copy the Connection String for the account, it will look like this DefaultEndpointsProtocol=https;AccountName=myaccount;AccountKey=myaccountkey;EndpointSuffix=core.windows.net.

  5. Log into your CI system, for example Travis CI, and create a sensitive/private environment variable named AZURE_STORAGE_CONNECTION_STRING, then for the value use the quoted connection string from the previous step. Putting quotes around this value is VERY IMPORTANT*. It should look like this AZURE_STORAGE_CONNECTION_STRING="DefaultEndpointsProtocol...EndpointSuffix=core.windows.net".

    * If this environment variable isn’t defined and formatted with quotes just right, you will see the follow error at the very end, and waste lots of time like me, Error: AZURE_STORAGE_ACCOUNT and AZURE_STORAGE_ACCESS_KEY or AZURE_STORAGE_CONNECTION_STRING must be set.

  6. Here is the magic script that I mentioned earlier. Copy that into your repository, into scripts/publish-charts.sh and run chmod +x on it.

    The script handles the first run scenario, where the container is empty. It will create a new index.yaml file and upload it, along with the compressed chart files. When an index.yaml already exists, it is downloaded and merged, preserving older versions.

  7. This script relies on two CLIs being installed: helm and the az cli (tiny or official). I prefer to use a build image container, rather than mess with installing directly on the build server. This lets me test my build scripts locally. I put this file in scripts/build-image/Dockerfile.

  8. Here are the commands to build the container, and execute the push-charts script. It mounts the root of the repository into the container, passes along the AZURE_STORAGE_CONNECTION_STRING environment variable and runs push-charts.sh inside of our build-image container.

Now your builds will publish your charts and an index of all your chart versions to https://CONTAINER.blob.core.windows.net/charts.

Here’s what it looks like from the user’s perspective:

$ helm repo add gomods https://athens.blob.core.windows.net/charts
"gomods" has been added to your repositories

$ helm search athens-proxy
NAME               	CHART VERSION	APP VERSION	DESCRIPTION
gomods/athens-proxy	0.2.0        	0.2.0      	The proxy server for Go modules

It is a bit of glue, but it does work. Sometimes I’m asked why I do this instead of hosting on Chart Museum or some other solution. Mostly because I like static file storage because it’s not something that requires “opsing” down the road. I don’t have to keep a service up or secured which is good because that isn’t something I enjoy or am good at. 😅

Maybe in a week or six months, I’ll replace this with a tiny go binary. We can only hope!