When developing and deploying applications, developers and DevOps teams often face complex challenges, especially in multistage environments. These multi-stage environments can range, for example, from the development stage (DEV) through integration testing (INT) to the production phase (PROD). Each of these phases requires specific configurations. Manually managing these environments can be time-consuming and prone to errors.
To solve precisely these problems, our experts are exploring the use of Helm in multistage environments. Helm is a powerful tool for simplifying the management of Kubernetes applications. In this post, we’ll explain step by step how Helm helps manage the complexity of multistage environments and increase the efficiency of development and deployment processes.
Multistage Environments – Challenges
A key challenge in 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 stage (PROD) or integration testing (INT). This often results in a significant and time-consuming configuration effort. Often, these configurations for the various staging environments are also created and maintained manually, which increases the likelihood of errors. As a result, developers and DevOps teams spend a great deal of time troubleshooting these issues once problems arise.
If the development team also relies on Kubernetes, configuring multistage environments can quickly become complex. Kubernetes offers numerous resource types, such as Secrets, ConfigMaps, and Deployments. Managing these resources and ensuring consistent and correct configuration poses a challenge for many developers.
The solution? A helmet
However, before we discuss specific possible solutions to the problem mentioned above, let's take a brief look at Helm's features.
What is Helm?
Helm is a powerful tool designed to simplify the management of Kubernetes applications. It was developed to reduce the complexity of installing, managing, and updating deployments in Kubernetes. Its key features are:
- Templating Engine: Helm offers a powerful templating engine that allows you to create Kubernetes manifest files that are flexible and customizable. This makes it possible to adapt the configuration across different staging environments.
- Versioning system: Helm enables versioning of charts, which makes it easier to track changes and restore previous configurations.
- Package Manager: Helm also serves as a package manager to simplify the distribution and exchange of applications.
- Open source and managed by the CNCF: Helm is an open-source project supported by the Cloud Native Computing Foundation (CNCF). This ensures an active and robust development environment.
Helm can significantly alleviate the problems that arise when configuring and managing multistage environments. Below, we'll 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 in a multistage environment?
Helm's key function in a multistage environment is the use of its templating engine. This engine makes it possible to create Kubernetes manifest files that are flexible and customizable. This is particularly useful when the same service needs to be deployed in different staging environments.
We recommend grouping service deployments into a Helm chart. A Helm chart is a structured collection of Kubernetes manifests and configurations required for a service. Instead of manually creating and managing individual manifests, they can simply be grouped together 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 required to deploy a specific service (e.g., deployments, secrets, services, and other resources). This allows the service’s complete Kubernetes configuration to be stored in the same repository as the source code.
To adapt the Helm chart for use in different staging environments, the chart is designed to be „abstract.“ This simply means that all settings and values that are intended to differ between stages are represented by variables. A separate variable file is created for each staging environment. These files contain the specific values and settings that may vary for each stage. Helm uses these variables to customize the templates in the chart accordingly.
These variables are defined in what are known as value files:
The defined variables can then be used in the Helm Chart using a special Mustache syntax. In the following example, the variable replicaCount used in the deployment.
Helm can now be set up using the `helm upgrade` or `helm install` commands. Depending on which variable file is provided, the different configurations are specified in the Helm chart. In our example, Kubernetes creates 8 pods in the production environment and only 2 pods in the development environment. The Helm chart can therefore be adapted to the requirements of each environment.
After customizing the Helm chart using the defined variables, Helm deploys it directly to the Kubernetes cluster. This automates the deployment process and ensures a consistent and reliable configuration for every environment. What’s particularly helpful is that Helm not only populates the variables but also sends the corresponding Kubernetes objects directly to Kubernetes. Before an update, Helm also checks whether the specific entity actually differs from the existing one and performs the update only if necessary. In addition, Kubernetes and Helm handle rolling updates themselves, for example, for deployments. This end-to-end automation ensures that the deployment process runs efficiently and guarantees a consistent configuration across every environment.
In addition, Helm offers a whole range of helpful features. In projects, it’s not uncommon for entire Kubernetes objects to be required only at certain stages. Helm makes this possible through its sophisticated templating system, which includes flow-control operators such as if / else and the range-Supports syntax for foreach-like loops.
Here, the Ingress is only created in the development environment (DEV), but not in the production environment (PROD).
Conclusion
At first glance, Helm’s motto—„so start using Helm and stop the copy-and-paste“—might seem a bit unusual and not exactly intuitive. However, despite the initial effort required for simple architectures, Helm offers significant advantages in multistage environments, which we’d like to highlight once more in conclusion.
By using Helm, the service’s configuration is stored in the Git repository. This ensures that the configuration is clearly versioned and located in a logical place, right next to the application’s source code. 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, is not stored in the Helm chart itself.
Since a Helm chart always follows the same structure, new team members can familiarize themselves with the configuration more quickly, and external resources must also 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 it takes is a simple Helm command. Helm detects when configurations have changed and updates only those Kubernetes entities that have actually changed. This allows Helm to perform simple rolling updates of deployments and significantly simplifies application management.
In addition, Helm includes a rollback feature that allows you to revert to previous, functioning versions of the service if a change does not behave as expected. This feature provides an additional layer of security that minimizes the unintended consequences of configuration changes.
All in all, Helm enables improved management and deployment of applications in multistage environments. It makes it easier to track configuration changes, promotes compliance with standards, automates the deployment process, and offers a robust rollback feature. By integrating Helm into development and DevOps practices, it can significantly increase efficiency and reliability.
