Using GitLab As Helm Chart Registry
Code, build, and deploy!
Since GitLab 14.1 the Package Registry allows users to build, publish, install, and share Helm charts.
What Is Helm Chart?
Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.
Creating a simple Helm chart
In this story, we are going to create a Helm chart, push it to the GitLab project, package it, and publish it to GitLab Package Registry.
At first, we need to create a project on GitLab, where we’ll store templates of the chart.
As we created the project on GitLab, let’s create a simple Helm chart on the local computer by executing the following command:
$ helm create example-chartMake sure you have installed Helm on your computer. Otherwise, that command won’t execute.
The helm create creates a chart directory along with the common files and directories used in a chart.
The output of the ls command shows that necessary files have been created and we just need to push them to the helm-chart-example project on GitLab.
Once files are successfully pushed, we need to package the directory as a Helm chart for storing in the package registry. At this point, it can be implemented via the helm package command on your computer, and it can be implemented with the CI pipeline that GitLab provides. I recommend packaging and pushing your Helm charts with GitLab CI instead of doing it via the command line on your computer.
Creating CI pipeline on GitLab
Before creating a pipeline, make sure that the Packages button is enabled from the project’s Settings→General→Visibility, project features, permissions tab, as you can see below:
The most interesting part is here! Now, we’re going to create a pipeline on GitLab for packaging and publishing our Helm chart. It’s easy to do from the project's CI/CD→Editor section. If you’re not familiar with GitLab CI/CD, you can check out the Get started guide here.
The pipeline will look something like this:
The pipeline’s code is presented here. Let’s go line by line to understand it.
At the top of the file, we’ve defined the stage name called package-publish , which we’ll use in the helm-package job. The tags keyword is responsible for the gitlab-runners. Since I use a self-hosted gitlab-runner on my minikube environment, I’ll use the corresponding tag of that runner in this project.
* Please note that you should use other tags in your pipeline.
As you noticed, there is the CHART variable whose value is the same as our Helm chart name that we’ve created. The variable is just for comfort, to avoid using the same name multiple times in the code.
In the before_script section, we install some dependencies like the git and helm-push plugin. The next important part is the authentication with the registry via helm repo add command that will add the Helm repository in the shell of the gitlab-runner. The CI_REGISTRY_USER, CI_REGISTRY_PASSWORD, CI_API_V4_URL and CI_PROJECT_ID variables are GitLab’s CI/CD specific variables.
CI_REGISTRY_USER— The username to push containers/charts to the project’s GitLab container/package registry. Only available if the container/package registry is enabled for the project.CI_REGISTRY_PASSWORD— The password to push containers/helm-charts to the project’s GitLab container/package registry. Only available if the container/package registry is enabled for the project.CI_API_V4_URL— The GitLab API v4 root URL.CI_PROJECT_ID— The ID of the current project. This ID is unique across all projects on the GitLab instance.
You can find them here for more about GitLab CI/CD predefined variables.
We do just two actions in the script section: packaging and pushing. That two actions will be done via appropriate commands of the Helm. The helm package command packages a chart into a versioned chart archive file, and the helm push command uploads a chart to a registry.
The last section is about when the GitLab job will trigger. The only.refs keyword means that job will be created in case of any commit to the main branch. The only.changes keyword means the job will be created and will automatically run when there are any changes to the files inside the example-chart directory.
Since we covered all details, it’s time to run our pipeline. For triggering the pipeline, we just need to change any of the files in the example-chart directory.
Once we’ve successfully committed our changes, we can jump to CI/CD tab and see the status of the job.
And finally, let’s check the Helm chart, which has been pushed to the package registry under the 0.1.1 version.
Conclusion
Now you know how to use GitLab Package Registry as a Helm chart registry; it lets you store, publish, and use the charts next to your Kubernetes manifests.
Happy Helming!
Thanks for reading. I hope this story was helpful. If you are interested, check out my other Medium articles.
