Making Reusable Helm Chart
Hi fellows, before we get to the topic, just want to let you guys know that I will write my medium’s article in English from now on. since I have noticed that technical stories are not getting much interests written in Thai, and of course, to sharpen my writings.
—
Ok let’s get to the story. Today I want to share my experience using Helm library chart.
Fundamentally, I only have just a little experience using Helm, I know Helm is a Kubernetes package management. We turn all of our application’s Kubernetes objects in to templates, and then we can create a Release by supplying our value files to the template which will in turn create/update our Kubernetes objects in the actual cluster.
Once these are all set we barely need to do anything after we have them in CI/CD pipeline.
—
Now, it comes to the difficult part. I have been assigned to Helmize this new project. Initially, I thought that this is same old same old. I could reuse what I have set up before and this should be done in few hours.
However, when I saw the project I needed to Helmize, it’s not that easy peasy no more.
I have noticed that this project is using Mono-repo type of structure!
This project consists of around 10 mini services in the repo, I know I know, shh shh, we are not going to debate on mono-repo, micro-repo here. stay calm.
In fact, If I were to finish by job easily, I could easily copy and paste my Helm chart definition to all these services since they are almost identical in term of architecture used.
However, that could soon become a very big burden in term of performance by their identical nature.
If I need to add some new definitions to all services I need to copy and paste them to all services and I could mess up at any point, and programatically, this is wet (not DRY 😏)
I need to find a better way out of this situation. so, I did some researches and found this concept of library chart.
Library chart helps you define similar definitions that could be shared among your Helm charts. this can be Helper, Logic, Templates depends on your need.
This is exactly what I am looking for, so let’s see how it works.
You start off my creating chart as usual.
change type of Chart.yaml to library
now, it’s time for our protagonist, named template.
Typically, Helm will not make an object out in Kubernetes cluster for files that start with _ (_xxx.tpl, _xxxx.yaml) just as your default _helpers.tpl
so, complying with this rule I can now conveniently create my objects like this under my library chart’s templates folder
the last thing we need to do is to wrap our object’s definition in this named template
we are now all set to use this library chart in our services
to use this library we need to go to our services’ helm chart and add this little thing called dependencies
in my case, it’s a mono-repo. so, I can reference to the shared-lib chart from file
then we can now run this command
helm dependency update ./helm
you will see a file created under charts directory
the usage is utterly simple. in your service’s templates directory you will need just only one file app.yaml (you name it)
within this file, you can use include to use lib-chart object definition you defined earlier
that’s it, try dry-run install your chart and you can see the objects will be created as expected
that’s it, hope you guys find this useful and can apply this in your work.
find the code example in this repo: https://github.com/InsomniaCoder/helm-library
Cheers!
