{"id":5177,"date":"2019-02-24T14:30:15","date_gmt":"2019-02-24T13:30:15","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=5177"},"modified":"2023-06-09T12:08:02","modified_gmt":"2023-06-09T10:08:02","slug":"migrating-to-kubernetes-part-3-creating-environments-with-helm","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2019\/02\/24\/migrating-to-kubernetes-part-3-creating-environments-with-helm\/","title":{"rendered":"Migrating to Kubernetes Part 3 – Creating Environments with Helm"},"content":{"rendered":"\n

Written by: Pirmin Gersbacher, Can Kattwinkel, Mario Sallat<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Creating Environments on the Fly<\/h2>\n

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.<\/p>\n<\/div>\n\n\n\n\n\n\n\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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"<\/code>.<\/p>\n<\/div>\n\n\n\n