Given the application, how should you convert your application to helm chart, so it can be deployed anywhere, with ease of configuration?
You might think your application is so simple, and just need 1–2 yaml files. Using “kubectl apply” will do, why bother writing the helm chart as it’s complicated? Maintaining few yaml files is okay if your application is a pretty small module, and most of settings are static, not much changes. Otherwise, I would recommend you are converting your application into the helm chart. This will help you:
- You only need to write the template one time, and all the changes in one values.yaml file should cover all the changes you need for your application.
- You have to deploy your application in different environments, you only need to change the values.yaml file, that would tailor to your experiments.
- Deploy and upgrade never been easier with just 2–3 commands. Or if you need to tear it down, helm uninstall will help you to clear all the resources for that release.
- The sharing to community or other team is also flexible and convenient. You don’t need to share the actual values or secrets with them. All you share is the templates. You shouldn’t miss any secret you put somewhere in the yaml file because hard-coded somewhere in the long yaml file and you forgot to clean up before you press “Send” button!
Okay, without further due, should we deep dive into how creating the sample helm chart.
This is the sample application with just 1 yaml file
Let’s create the helm chart for this application!
First, let start with the helm chart structure. Each chart must have at least:
- Chart.yaml
- values.yaml
- template/
Where the Chart.yaml file contains the general information about your application: name, version and links, reference and maintainer, etc.
The values.yaml should contain the default values for your chart. The values.yaml can be very long, it’s up to how many settings you want to expose or let user customise. I usually learn and use the community charts like prometheus, mongodb, mysql or other charts as the reference.
Example of these two files are here:
Now, it comes to the most complexity part of the helm chart, and I also get struggle by it when I first use and learn about it. It’s the template/ folder, with
- _helpers.tpl (Golang),
- NOTES.txt (optional), and
- bunch of yaml files.
The yaml files are totally up to you. You might have preference to separate yaml files into kubernetes components (like deployment.yaml, service.yaml, configmap.yaml, etc.) or your application components (server.yaml, frontend.yaml, routing.yaml, etc.).
In our sample application, as it’s only one module, so I will break this into different kubernetes components.
Few things about the helper.tpl that you should know:
- $.Values.<something> or .Values.<something>
The $.Values.<something> is the absolutely to the root whereas the .Values.<something> is relative to the parent.
- name of the variable.
The name of variable only including ascii, or hyphen, lowercase.
NOTES.txt in your helm chart
NOTES.txt is the content you should see when you finished installing the application. So it’s depend on you to write this notes.
You can verify the helm chart by rendering this chart into yaml file, and/or run test with kubect apply for unit testing.
helm template <release-name> -f <path/to/values.yaml> charts/sampleapp --output-dir manifest/
Next topic (To be updated): Host the helm charts on the internet (Github, GCP, and other options).
