Helm for Kubernetes. Helmfile.
The current chapter is the continuation of Helm exploration journey started with previous ones:
The input for the current chapter is here. The project has three Helm charts (RabbitMQ is maintained by Bitnami, a handcrafted chart with naive REST API server communicating with RabbitMQ and a utility Helm chart with TLS certificate used for HTTPS access via Ingress).
My current project consists of three Helm charts and to install everything following commands need to be run:
There are few small issues with this script:
- individual chart has individual command to deploy (what if the project will includes more and more charts?).
- some parameters (see namespace “-n medium”) need to be passed everywhere and be similar.
- some charts need to have customization values (see line #2, “-f ./rabbitmq/my-values.yaml”) are sent from outside as direct modification of chart maintainer files is a bad idea.
- other charts have everything baked inside (see line #3) which is laconic for now but will prevent from deploying chart to different environments due to lack of customization.
Helmfile is the remedy against weaknesses above. It is not really yet another file format for Helm (in fact, binary to install on host machine), but kind of umbrella under individual Helm charts, helping to treat it as group which has shared parameters and can be installed at once.
The plan for this chapter is to wire 3 existing Helm charts together in one Helmfile project and prepare two environments (dev and prod) installation versions by using same Helm chart and feeding it with valid values for each environment.
Please install Helmfile on your PC (as a reminder, I am brave enough to use Windows 10 with minikube run Docker desktop) and let’s get started!
Future file structure looks like:
On top level:
- charts is a folder for existing 3 Helm charts (there will be minimal adaptation of what I have in previous chapter mainly to pull values files out of chart to Helmfile area).
- envs is a Helmfile folder, which will hold a parallel structure for dev and prod environments. As a kind of disclaimer, my intention is to have an easy to grasp to Helmfile migration process. Thus, a fully independent per-environment structure is used and no optimization to keep everything in common structure is done. Please, refer to the official documentation to get an impression on what might be improved.
Let’s concentrate on envs/dev part in details. The core file, as name implies, is helmfile.yaml:
#1 .. #2: general settings applied to all Helm charts.
#4: start of Helm chart goes into current Helmfile project section. Each individual Helm chart has a dedicated, but very similar, section here. Let’s describe last section, for handcrafted server-heartbeats chart in details.
#21: future Helm chart name (helm list … command will show it).
#22: dedicated Kubernetes namespace for all charts on dev environment.
#23: path to Helm chart sources itself.
#24 .. #25: Helm chart value customization yaml-file, which used to be inside this chart and now has been pulled out to Helmfile file structure, which should increase it observability as it most like will have environment dependant values.
#26 .. #27: Helm chart secrets value customization yaml-file, similarly used to live inside this chart. In previous chapters I played a lot with nice way to keep secrets at the same repo as regular code, but encoded with GPG key. Please, refer to that chapters, especially this one.
And below is file structure for Helmfil’s dev environment:
Nothing difficult here: helmfile.yaml references all 6 files in values subfolder. It has just happened to me that each chart has one values and one secret-values file. Some file might be not needed or, from other side, many values file can coexist in one chart.
Let’s look into server-heartbeats specific value files. 90% of it content came from previous chapters, so will just briefly look through.
yaml-file has params secured_username and secured_password (line #1 .. #2) crypted with PGP key (line #9). Both parameters are used to connect from service Pod to RabbitMQ running in the same namespace. File transited from previous chapter without modification.
#2 .. #3: less important chart specific value.
#4 .. #6: values used in Ingress part of current service to point to TLS certificate and domain (see one of previous chapter for details).
#1: is freshly added and very interesting in current context. The plan is to have a different value for dev and prod environments. This value is also used in Ingress section to build a different host names (https://dev-heartbeats.localdev.me and https://prod-heartbeats.localdev.me) for different environments. It gives a possibility to install both environments in one Kubernetes cluster, since it will be in separate namespaces and run both at the same time, since Ingress reverse proxy rules will point to corresponding Kubernetes services.
All Helmfile file structure for prod environment is the same. Of course, mentioned above stage param should be changed and secrets for prod should be different.Same apply to Kuberntes namespace as target now is prod-medium namespace.
Please refer to results for prod environment deploy with Helmfile.
Installing Helmfile is much easier now (in comparison to individual Helm chart installation)
In 10 seconds 6 Helm charts (3 for dev and 3 for prod), located in two separate namespaces should be installed:
Couple Lens screenshots with deployed resources:
By typing minikube tunnel command (remember I use minikube on Windows), I can have access to services on both environments simultaneously:
All sources can be found on github.
Helmfile is really useful Helm wrapping declarative utility. Indeed, any project now has more than one Helm chart (as Kubernetes is orchestrator, not solo singer) and Helmfile allows to deal with crowd of charts in a single batch. It is absolutely easy and naturally use it having Helm chart knowledge under the belt. Please, explore it capabilities reading through documentation.
