Migrating to Kubernetes Part 3 – Creating Environments with Helm

Creating Environments on the Fly

The last step has been the deployment of a classic 3 tier application onto a Kubernetes Cluster powered by Minikube. In the next stage it gets a little complicated, since there are two things to do that depend on each other. So far the deployment files contain static values, thus exactly one environment can be initialized with them. Since the goal is to initialize any number of environments, the Yaml files for Kubernetes must be filled with dynamic values.

There are many ways and means to achieve this, the most popular one currently is Helm. The package manager for Kubernetes allows you to make Yaml files dynamic using the Go template engine – this is called a Chart. In addition dependencies (other charts) can be referenced. Therefore the PostgreSQL database will be no longer part of the deployment. Instead, the official Helm Postgres Chart is used.

In a productive environment, the use of an operator for the database should also be considered. For this tutorial the Helm chart will be sufficient. However, it should be noted that ignoring volume claims can lead to data loss.

The goal of this chapter is to create a configurable deployment. This is then used to start any number of environments from the CI pipeline. In addition to Production and Staging there will be a separate environment for each Feature Branch which reflects the current state of the branch. Due to the integration of Gitlab, this environment is also displayed in the respective merge request and is even degraded as soon as the merge request is closed.

Since the Go Template does not necessarily make the Yaml files more human-readable, it is recommended to split the complete-deployment.yaml file. Each service, deployment and ingress controller goes to a single file. How helmet then works is actually relatively simple. Values that were previously hard coded in the Yaml files are replaced with variables. These variables are stored as the standard configuration in the so-called Values.yaml file. With the later build, one is able to overwrite individual values by attaching a parameter to the corresponding Helm command, e.g. helm install --set serviceName="client-service".

In addition to variables, the Go Template notation can also be used to implement If-statements and function calls and many more handy stuff. Of course, this is sometimes at the expense of legibility.

What Helm can also do is to reference other charts. This is exactly how PostgreSQL is integrated. Therefore the file requirements.yaml is created and filled with the following code.

What follows now is to migrate any values to variables. These variables will be filled later via the CI Pipeline. Only static values like the URL slug for API (/api) remain, anything required dynamic like host, ports, credentials, service/deployment names and so on needs to be configurable. Take a look at the follow-by repository for detailed information. As example the server service is shown. Some values, here PostgreSQL values will be exposed through the previously required chart and thus can we used.

If all Kubernetes files are made configurable, then this chart – as long as one takes the trouble to enter all variables – can be deployed to Minikube for testing purposes. In this article we’ll connect the whole thing to Kubernetes and Gitlab right away. But usually it is recommended to test locally first, since this is quite a time saver.