3 Helmfile features you don’t know

Using helmfile for deploying applications to several Kubernetes clusters, I found several features that could be useful for setting up a bit difficult deployment scheme but without adding additional logic to the deployment process.

Missing file handler

The feature allows you to skip missing files that you specified under release configuration in helmfile, so you can easily manage releases for a huge count of environments and don’t worry about where you override default configuration or not. Let’s look closer:

Sample of helmfile directories organization

Use it, if it’s enough for having only default values to be able to configure nginx-ingress for a lab environment. For other environments, where we need to add overrides, use the following option: missingFileHandler, and when helmfile isn’t able to find a specified file from values section, it will only warn you without failing deployment. It’s a nice workaround but you can’t specify this parameter globally at the moment.

Release dependencies

It’s a common issue with defining specific orders for deployment of your application. The right choice for solving the problem is using Kubernetes operator, but it’s a bit overhead for simple dependencies when you just need to update common configmap which should be included in all of the applications’ deployments (Kubernetes object).

Firstly, helmfile will deploy the nginx-ingress-conf release, and after it was deployed successfully nginx-ingress will be deployed as well.

Conditions

There are several ways to add flexibility to your helmfile:
1. Using if, if not, if eq

Redis release will be deployed only if the environment equals “lab”. You can pass it using: helmfile -e {ENVIRONMENT_NAME} -l name=redis apply, where ENVIRONMENT_NAME is the environment from partial/environments.yaml

2. Using additional file and configuration parameters. Let’s imagine that we have several environment-specific services like DB, Memcached and something else inside Kubernetes, we don’t want to add all of them to shared application helmfile, so it will be growing up to fast, we can use the following approach to avoid mixed common and environment-specific configuration:

• Create a file inside partial, for example, lab-only.yaml
• In environments.yaml add a parameter that will be responsible for enabling or disabling this part of applications, for example

• Inside lab-only.yaml add as first and last lines, it means: take described releases into account only if labonly option is true.

You can find more info about helmfile in an official GitHub repo.