When developing and deploying applications, developers and DevOps teams often face complex challenges. This especially applies to handling multistage environments. These multistage environments can range from a development stage (DEV) through integration testing (INT) to the production stage (PROD). Each of these stages requires specific configurations. Manually managing these environments can be time-consuming and above all, error-prone.

To solve precisely these problems, our experts are looking at the use of Helm within multistage environments. Here, Helm turns out to be a powerful tool for simplifying the management of Kubernetes applications. In this post, we will explain step-by-step how Helm helps to manage the complexity of multistage environments and simultaneously increase the efficiency of development and deployment processes.

Difficulties of multistage environments

A key problem with multistage environments is that configurations can vary from stage to stage. The development stage (DEV) may not require the same scaling and resource allocation as the production (PROD) or integration testing (INT) stages. This frequently leads to a significant configuration effort that is very time intensive.

As mentioned earlier, configurations for the various staging environments are created and maintained manually, therefore entailing a higher probability of error. Given the nature of this process, developers and DevOps teams consequently spend a lot of time trying to identify these errors.

If the development team additionally relies on Kubernetes, the configuration of multistage environments can quickly become complex. Kubernetes offers numerous resource types such as Secrets, ConfigMaps or Deployments. Managing these resources and ensuring a consistent and correct configuration is a challenge for many developers.

The solution? Helm

But before we dive into specific options to solve the above-mentioned problem, we will give a brief overview of the features of Helm.

What is Helm?

Helm is a powerful tool for simplifying the management of Kubernetes applications. It’s designated to reduce the complexity of installing, managing and updating deployments in Kubernetes. Its key features include the following:

• Templating engine: Helm provides a powerful templating engine that allows you to create Kubernetes manifest files that are variable and customizable, allowing the configuration to be customized in different staging environments.
• Versioning system: Helm enables versioning of charts, making it easier to track changes and restore previous configurations.
• Package manager: Helm also acts as a package manager to simplify the distribution and exchange of applications.
• Open source and managed by CNCF: Helm is an open source project and is supported by the Cloud Native Computing Foundation (CNCF). This ensures an active and robust development environment.

In the following, we will take a closer look at how Helm works and how it can simplify the configuration and management of staging environments.

How can Helm be used for a multistage environment?

The central function of Helm in a multistage environment is the use of its templating engine. This engine makes it possible to create Kubernetes manifest files that are variable and customizable. This is particularly useful if the same service is to be deployed in different staging environments.

We recommend summarizing deployments of services in a Helm chart. A Helm chart is a structured collection of Kubernetes manifests and configurations that are required for a service. Instead of creating and managing individual manifests manually, these can simply be summarized in a Helm chart. This makes deployment and maintenance much easier.

Helm charts have a standardized structure that makes it easier to create and use different charts. This structure ensures that the chart files are easy to understand and maintain.

In addition, a Helm chart contains all the necessary Kubernetes configurations that are required for the provision of a specific service (e.g. deployments, secrets, services and other resources). This allows the complete Kubernetes configuration of the service to exist together with the source code in the same repository.

In order to adapt the Helm chart for use in different staging environments, the chart is made "abstract". This means that all settings and values that should differ between the stages are represented by variables. A separate variable file is created for each staging environment. These files contain the specific values and settings that can be different for each stage. Helm uses these variables to customize the templates in the chart accordingly.

These variables are defined in so-called value files:

Values-dev.yaml
replicaCount: 2
enableIngress: true

Values-prod.yaml
replicaCount: 8
enableIngress: false

The defined variables can then be used in the Helm Chart with a special mustache notation. In the following example, the variable replicaCount is used in the deployment.

deployment.yaml
apiVersion: apps/v1
kind: Deployment
…
spec:
  replicas: { { .Values.replicaCount }}

Helm can now be instrumented by using the commands helm upgrade or helm install. Depending on which variable file is specified, the different configurations are written to the Helm chart. In our example, 8 pods are created by Kuberenetes in the production environment and only 2 pods in the development environment. The Helm chart can therefore be adapted to the requirements of the respective environment.

Once the Helm chart has been adapted using the defined variables, Helm deploys directly to the Kubernetes cluster. This automates the deployment process and ensures a consistent and reliable configuration for each environment. It is particularly helpful that Helm not only fills in the variables, but also sends the corresponding Kubernetes objects directly to Kubernetes. Prior to an update, Helm also checks whether the specific entity actually differs from the existing one and only carries out the update if it‘s necessary. In addition, Kubernetes and Helm take care of rolling updates themselves, e.g. for deployments. The holistic automation ensures that the deployment process runs efficiently and that a uniform configuration is guaranteed in every environment.

Helm also has a whole range of helpful functions. It happens time and again in projects that entire Kubernetes objects be made available only on certain stages. Helm makes this possible using its complex templating system, which supports flow control operators such as if / else and the range syntax for foreach-like loops.

ingress.yaml
{ {- if .Values. enableIngress -}}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  …
{ {- end }}

As the example shows, the ingress is only created in the development stage (DEV) but not in the production stage (PROD).

Conclusion

At first glance, Helm's motto "so start using Helm and stop the copy-and-paste" may seem a little unusual and not exactly intuitive. However, despite the initial effort involved even for simple architectures, Helm offers considerable advantages in multistage environments, which we would like to emphasize once again in conclusion.

By using Helm, the configuration of the service is stored in the GIT repository. This means that the configuration has clear versioning and is located in a logical place, right next to the source code of the application. This makes it easier to track configuration changes and ensures that the configuration always remains consistent with the application. However, it is important to ensure that sensitive information such as passwords or secrets are not stored in the Helm chart itself.

As a Helm chart always has the same structure, new team members can familiarize themselves with the configuration more quickly and external resources also have to adhere to this structure.

Another advantage is that many manual kubectl commands no longer need to be entered in a terminal or executed via Jenkins. All that is needed is a simple Helm command. Helm recognizes when configurations have changed and only updates those Kubernetes entities that have actually changed. As a result, Helm enables simple rolling updates of deployments and thereby makes managing the application much easier.

In addition, Helm is equipped with a rollback function that can be used to revert to previous working versions of the service if a change does not behave as expected. This feature provides an additional layer of security that minimizes the unwanted effects of configuration changes.

All in all, Helm improves the management and deployment of applications in multistage environments. It facilitates the tracking of configuration changes, promotes compliance with standards, automates the deployment process and provides robust rollback functionality. Integrating Helm into development and DevOps practices can significantly increase efficiency and reliability.