Installing multiple helm charts in one go using helmfile

In this article we will be talking about Approach 2 i.e. how to get multiple helm charts installed using helmfile.

If you haven't read the previous article where I discussed about Approach 1, feel free to read it over.

Ref: https://community.aws/content/2ZOK3opgXbo27Kn3tFiyecACAld/installing-multiple-helm-charts-in-one-go-approach-1

Prerequisites:

A running Kubernetes cluster with proper permissions, here I have used minikube.
kubectl, helm, and helmfile installed on your machine to interact with the Kubernetes cluster.
- Ref: https://kubernetes.io/docs/tasks/tools/
- Ref: https://helm.sh/docs/intro/install/
- Ref: https://github.com/helmfile/helmfile

Installation of helmfile is pretty straight forward, we just need to grab its binary and put that in /usr/local/bin and we are done (Ref: https://helmfile.readthedocs.io/en/latest/#installation for operating system other than linux).

Grab the latest one from the assets section from here: https://github.com/helmfile/helmfile/releases.

Once helmfile is installed, we need to initialize it so that it can download necessary helm plugins.

If you want to list it out what all plugins init installs, it can be found using below command:

Note: A notice to upgrade helm may appear if the helm version is 3.10 or lower.
- helm version is too low, the current version is 3.10.1+g9f88ccb, the required version is 3.12.3 use: 'https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3' [y/n]: y

Approach 2:

helmfile is pretty intresting and a very useful utility when it comes to get multiple helm charts installed. Using a single file helmfile.yaml we can manage N number of charts.

When it comes to installing mutiple helm charts, helmfile is a really helpful and interesting tool. The helmfile.yaml values file and helmfile binary is all that is needed to manage N number of charts. Internally helmfile invokes helm command to manage Kubernetes objects/charts. Also you can think of helmfile as a wrapper around helm together with some helm plugins.

Below is a quick example, wherein I have a 3-Tier application comprising of a frontend, backend, and database and for all of them I have 3 individual charts.

Now, we will use helmfile (that too a single command to get these charts installed).

In the same directory where my charts are there, lets create a new file called helmfile.yaml. Just to add here we are referring local charts now, but we will refer charts from helm repositories in next examples.

Location: Local helm charts

Lets break this file now:

There can be multiple sections in this YAML file, but majorly we will focus on .releases and .repositories sections.
For more details around what all things we can have in a helmfile.yaml, ref: https://helmfile.readthedocs.io/en/latest/#configuration.
.releases is an array which basically signifies what all helm releases we need to deploy in a Kubernetes cluster.
- Important KV pairs in each item are .releases[].name which refers to the name of the release.
- .releases[].namespace, it refers to the name of the namespace where we need to install the chart.
- .releases[].chart, it refers to the location of the chart from where helm needs to pull it. In this example its in my local machine and in the current directory.
- .releases[].version, it refers to the version of chart which needs to be installed.
- .releases[].installed, it is a boolean key which referes if we want to get specific chart installed or not (by default the value is true).
- .releases[].wait, it is same as --wait flag of helm, which means the operation will wait untill all the components are ready/healthy. Ref: https://helm.sh/docs/intro/using_helm/.

Now, lets see helmfile in action:

As of now nothing is installed.

We will first initialize helm to gather all the dependencies.

Lets list out what all releases are defined in our release file?

All, looks good, lets apply the state file using helmfile apply.

If you will see here, using a single command it instructed helm to build the dependency of all the charts specified in the state file then it used helm diff to list out actual k8s yaml files, then it installs all the releases.
If you will fire helm list or kubectl get pods now, you will see all the intended resources.

Get the status using helmfile status if required.

Now, lets assume you just need to update the database release and that too just the replicaCount,
- How to update that using values file or using set key?
- What helmfile will do?
- How to check what all changes helmfile will make?

By default, similar to helm, this will also use helm chart's default values.yaml file which is a part of helm chart itself. So either you can update that and fulfill your requirement (which idelly is not a good practice, since in real world scenario that is most unlikely to happen and ideally we should to override intended keys).

To cater this need we have something called values and set which we can specify in the state file and helmfile will consider those values and will override them.

Lets use the same example, but now I have added few additional line for backend as well as for the database item in our releases array.

Just to cut short, values is same as --values and set is same as --set in helm.
Here if you will see, for backend I have used set and I am overwriding relicaCount to 2 and for database I have used 'values' and there I have passed a path where my values file resides which contains again the replicaCount as 2 but for database release.
Now, comes the 2nd question, how to see what all differences will helmfile make, simply fire helmfile diff.

Here, if you will observe, firstly it compared the release webapp (wherein it didn't found any differences then it compared backend where it found that the replicaCount was updated to 2) then it compared database where it again found that the replicaCount was updated to 2.
Using helmfile apply, we will apply the changes now.
Note: helmfile apply basically calls two operations helmfile diff and helmfilesync.
Again it will show you what all changes it will bring then will apply the changes.

Revision got incremented by 1, and now I have 2 new pods running +1 for backend and +1 for database.

In the above example we referred the helm charts which were placed locally, now lets see how to consume the helm charts which are a part of OCI or HTTPS repositories.

Location: helm charts from OCI repositories

Let's now install a helm chart from an opensource oci repository (ref: https://artifacthub.io/); Just for an example we will install nginx chart.
Again, I have a new helmfile.yaml and the only difference here is in the chart key.

Here, if you will observe firstly helmfile is pulling the helmchart then will list out the difference i.e. what all things it will create and then will get the k8s resources created.

Location: helm charts from HTTPS repositories

Let's now install a helm chart from an opensource HTTPS repository and here I have taken an example from the official helmfile documentation (ref: https://helmfile.readthedocs.io/en/latest/#getting-started)
Here is the new helmfile.yaml and now the difference here is .repositories and .releases[].chart.

Here, if you will observe in this helmfile we have a new section called .repositories which again is an array and can contain multiple repositories with a human friendly name which can be referred in the .releases section. For instance here the repo is https://prometheus-community.github.io/helm-charts and it can be referred in the releases section as prometheus-community.
And in-turn .releases[].chart now is prometheus-community/prometheus where prometheus is the chart name. When installing many charts from the same source, this eliminates duplication, and if we only need to change the repository, the update would only be needed at one place and we are done.
Another point to note here is, adding .repositories is similar to running helm repo add prometheus-communit https://prometheus-community.github.io/helm-charts this command.

Repositories

We already touched upon this topic but just for completeness sake similar to above example we can have OCI repositories as well defined under .repositories section.
Here is an example for the same:

If you are referring an oci repository make sure to use repositories[].oci as true.

Feel free to read it over and share your thoughts and comments.

Happy Learning!

PS: The cover image is created using https://www.canva.com/.

References:

https://helmfile.readthedocs.io/en/latest/

Site Terms, Privacy, and more.