Why Helmfile?

Why do we need helmfile?

One of them is that when we want to override values from a values.yaml file we need to compose a specific command. To the helm upgrade command we need to add the --values flag followed by a file name. This is called an imperative approach because to get what we want (install the application) we need to execute several steps. Like in our example, first we need to add a Helm repository (for PostgreSQL), and then install the back-end and front-end Services. Relatively simple, but only for now. In the real world, in large distributed systems, we have to deal with hundreds of applications, so this approach might not scale that well.

Let’s imagine a situation in which we are working on such a system with hundreds of software engineers. And now we need to add a new Service to this already complex system. How would we do that? Sure, we would need to prepare a Helm chart for that, but how do we deploy it? Of course, we could ask around and probably after a couple of hours we would get to the right person who would say that the only thing to do is to adjust the CI/CD script. But that works only for a development environment. If we want to deploy it on the end-to-end (E2E) testing environment also we would need to adjust a different script. And if we want to install it on production there is also another script. Again, in simple systems, it might not be a problem, but what if we’re talking about a system with a large number of Helm releases, with each one of them having its own configuration values files? Additionally, it’s using the CI/CD system which we don’t know or it is too complex to figure it out.

Helm gives a nice way to deploy a single application, but it might be tricky when we want to create more Helm releases. The umbrella chart could be a solution to that, but it has its flaws. To overcome that, we need a tool that can provide us a consistent way of declaring what our cluster could look like instead of running all imperative commands and hoping that at the end we’ll get what we want.

Luckily for us, such a tool exists, and it’s a Helmfile. With it, we can declaratively define which Helm releases we would like to install on a cluster, declare all the values files that are needed for each release, add Helm repositories, and much more. With a Helmfile, we can have one place in which we have the entire configuration for all the applications and environments. With it, we get an easy and consistent way of managing complex systems.

How it works?

The main idea of a Helmfile is to put all the configurations in a single file, including information about where the charts are located (repositories), which releases we would like to create, and specific the configuration for each environment. Once we have it, the only thing to do is to run a simple command with an optional flag, -environment environment-name.