Helm for the Second Time – Versioning and Rollbacks for Your Application

Hi, today at Innokrea, we continue the topic of the package manager for Kubernetes, Helm. We will try to show you how to update your configuration, perform a rollback, override values with your own, and explain what templates are. If you haven’t read our previous articles on containerization or DevOps, feel free to check them out at https://www.innokrea.pl/blog.

MongoDB vs Version Management

Let’s start by constructing an example based on MongoDB, a very popular NoSQL database. We will begin by searching for available chart versions using the command helm repo search <name>.

Figure 1 – Available Chart Versions in the Bitnami Repository

We can notice that if we add the –versions flag to our command, we will see all available chart versions along with a description of the application version they correspond to. There are three types of versions in Helm that are important to distinguish:

• Chart version – The version of the Helm package prepared by the team responsible for the application. The version is specified in the Chart.yaml file.
• App version – The version of the application used by the Helm package. The application itself is prepared by the development team. This version is also listed in the Chart.yaml file. The chart version should align with the app version.
• Revision version – The version of a release on the client side using the Helm chart. This is a sequential number that increases when commands like upgrade, install, and rollback are executed. It allows identification of different release versions and switching between them if a new deployment is problematic in some way.

Let’s install two selected versions of the MongoDB chart – one being the latest, i.e., 16.4.0 with app version 8.0.4, and the other, an older version, 16.2.2 with app version 8.0.3. We also need to remember to assign appropriate names to our releases, in our case, it will be my-mongo-<version>.

Figure 2 – Installation of Two Different MongoDB Versions: 16.4 and 16.2

Updating the Configuration

To update the configuration provided in the YAML file, we can use two techniques. The first one involves directly overwriting values using the –set flag, e.g., –set auth.rootPassword=test. The second method involves writing all the values we want to overwrite in the values.yaml file. Values that are not defined will remain the default ones, as defined by the chart author. But how do we know which values can be overridden? You should refer to the definition of the values.yaml file published by the chart authors in repositories like GitHub.

Figure 3 – The values.yaml File Defined for MongoDB by the Chart Authors

Now, let’s try to overwrite the password by defining a simple values.yaml file and using the upgrade command.

Figure 4 – values.yaml File Created Similar to Figure 3

Figure 5 – Displaying the Password Change Using the upgrade Command and values.yaml File

Let’s also pay attention to the Revision, which has changed to number 2 after executing the upgrade command. We can check this change using the kubectl get secrets command (where release metadata is stored) and helm history. Let’s try to roll back to the previous version using the helm rollback command.

Figure 6 – Rollback Process to the Previous Version

Note that, since we did not use the –version flag and performed an upgrade with a values.yaml file that only overwrote the password, the default values (from values.yaml) were fetched from the latest chart version. This means that by modifying only the administrator password, we also updated the chart version and, consequently, the application version to 8.0.4. To avoid such unintended updates, we should specify the exact chart version using the –version flag as follows:

helm upgrade my-mongo-16-2 bitnami/mongodb –values values.yaml –version 16.2.2

Helm Templates

We already know that by using the values.yaml file, we can override selected values, but how does this actually work? How can we ensure that our created application has the ability to dynamically replace key values depending on the values.yaml file? This is where templates come in, which are YAML files for Kubernetes enhanced with templating syntax based on the Go Templates language. To explore this mechanism, let’s take a look at the serviceaccount.yaml template for the MongoDB application.

Figure 7 – MongoDB’s serviceaccount.yaml Template with Templating Syntax

In the file, we can observe the use of the Values object (i.e., the defined values.yaml file), as well as simple logic utilizing if statements and logical conditions. Often, projects also use the _helpers.tpl file, an auxiliary file used to define code fragments that are reused multiple times. This is an optional but highly useful element of Helm charts, allowing the creation of helper functions and avoiding code duplication in other template files within the templates directory in large projects.

Figure 8 – The helpers.tpl File Containing Auxiliary Logic and Values

Summary

We hope that today you’ve gained more knowledge about Helm. We showed you how easy it is to revert to previous application versions through rollbacks, but also how important it is to be cautious when using the correct versions. Additionally, we demonstrated how templates work, along with some example logic that supports the configuration generation for MongoDB. If you found this post interesting, we encourage you to explore similar topics related to Docker and Kubernetes.

See you in the upcoming weeks!

Sources:

https://github.com/bitnami/charts/blob/main/bitnami/mongodb/values.yaml

https://github.com/bitnami/charts/blob/main/bitnami/mongodb/templates/serviceaccount.yaml