Beim Entwickeln und Bereitstellen von Anwendungen stehen Entwickelnde und DevOps-Teams oftmals vor komplexen Herausforderungen, insbesondere in Multistage-Umgebungen. Diese Multistage-Umgebungen können bspw. vom Entwicklungsstadium (DEV) über Integrationstests (INT) bis hin zur Produktionsphase (PROD) reichen. Jede dieser Phasen erfordert spezifische Konfigurationen. Die manuelle Verwaltung dieser Umgebungen kann dabei stets zeitaufwändig sowie fehleranfällig sein.

Um genau diese Probleme zu lösen, befassen sich unsere Xperten mit dem Einsatz von Helm in Multistage-Umgebungen. Helm ist ein leistungsstarkes Werkzeug zur Vereinfachung der Verwaltung von Kubernetes-Anwendungen. In diesem Beitrag werden wir Schritt für Schritt erläutern, wie Helm dabei hilft, die Komplexität von Multistage-Umgebungen zu bewältigen und die Effizienz von Entwicklungs- sowie Bereitstellungsprozessen zu steigern.

Multistage-Umgebungen – Schwierigkeiten

Ein Kernproblem von Multistage-Umgebungen besteht darin, dass die Konfigurationen von Stage zu Stage variieren können. Die Entwicklungsstufe (DEV) benötigt möglicherweise nicht die gleiche Skalierung und Ressourcenzuweisung wie die Produktionsstufe (PROD) oder Integrationstest (INT). Dies führt häufig zu einem erheblichen Konfigurationsaufwand, der viel Zeit in Anspruch nimmt. Oftmals werden diese Konfigurationen für die verschiedenen Staging-Umgebungen auch manuell erstellt und gewartet, sodass die Fehleranfälligkeit ansteigt. In der Folge verbringen Entwickelnde sowie DevOps-Teams viel Zeit damit, diese zu ermitteln, sobald Probleme auftreten.

Setzt das Entwicklungsteam dazu auch noch auf Kubernetes, kann die Konfiguration von Multistage-Umgebungen schnell komplex werden. Kubernetes bietet zahlreiche Ressourcentypen wie bspw. Secrets, ConfigMaps oder Deployments. Die Verwaltung dieser Ressourcen sowie die Gewährleistung einer konsistenten und korrekten Konfiguration stellt für viele Entwickelnde eine Herausforderung dar.

Die Lösung? Helm

Bevor wir jedoch auf die spezifischen Lösungsmöglichkeiten für oben genannte Problemstellung eingehen, geben wir einen kurzen Überblick über die Eigenschaften von Helm.

Was ist Helm?

Helm ist ein leistungsstarkes Tool zur Vereinfachung der Verwaltung von Kubernetes-Anwendungen. Es wurde entwickelt, um die Komplexität bei der Installation, Verwaltung und Aktualisierung von Deployments in Kubernetes zu reduzieren. Seine zentralen Eigenschaften sind:

• Templating Engine: Helm bietet eine leistungsstarke Templating Engine, die es ermöglicht, Kubernetes-Manifestdateien zu erstellen, die variabel und anpassbar sind. So kann die Konfiguration in verschiedenen Staging-Umgebungen angepasst werden.
• Versionierungssystem: Helm ermöglicht die Versionierung von Charts, was die Nachverfolgung von Änderungen und die Wiederherstellung früherer Konfigurationen erleichtert.
• Paketmanager: Helm fungiert auch als Paketmanager, um die Verteilung und den Austausch von Anwendungen zu vereinfachen.
• Open Source und von CNCF verwaltet: Helm ist ein Open-Source-Projekt und wird von der Cloud Native Computing Foundation (CNCF) unterstützt. Eine aktive und robuste Entwicklungsumgebung wird somit gewährleistet.

Helm kann die Probleme, die bei der Konfiguration und Verwaltung von Multistage-Umgebungen auftreten, erheblich mildern. Im Folgenden werden wir genauer darauf eingehen, wie Helm funktioniert und wie es die Konfiguration und Verwaltung von Staging-Umgebungen vereinfachen kann.

Wie kann Helm nun für eine Multistage-Umgebung genutzt werden?

Die zentrale Funktion von Helm in einer Multistage-Umgebung ist die Verwendung seiner Templating Engine. Diese Engine ermöglicht es, Kubernetes-Manifestdateien zu erstellen, die variabel und anpassbar sind. Das ist besonders nützlich, wenn derselbe Service in verschiedenen Staging-Umgebungen bereitgestellt werden soll.

Wir empfehlen Deployments von Services in einem Helm-Chart zusammenzufassen. Ein Helm-Chart ist eine strukturierte Sammlung von Kubernetes-Manifesten und Konfigurationen, die für einen Service benötigt werden. Statt einzelne Manifeste manuell zu erstellen und zu verwalten, können diese einfach in einem Helm-Chart zusammengefasst werden. So wird die Bereitstellung und Wartung erheblich erleichtert.

Helm-Charts haben eine standardisierte Struktur, die es erleichtert, unterschiedliche Charts zu erstellen und zu verwenden. Diese Struktur sorgt dafür, dass die Chart-Dateien leicht verständlich und wartbar sind.

Zudem enthält ein Helm-Chart alle notwendigen Kubernetes-Konfigurationen, die für die Bereitstellung eines bestimmten Services erforderlich sind (bspw. Deployments, Secrets, Services und andere Ressourcen). Dies ermöglicht es, dass die komplette Kubernetes-Konfiguration des Dienstes gemeinsam mit dem Quellcode im selben Repository existiert.

Um das Helm-Chart für den Einsatz in verschiedenen Staging-Umgebungen anzupassen, wird das Chart „abstrakt“ gestaltet. Das bedeutet nichts anderes, als dass alle Einstellungen und Werte, die sich zwischen den Stages unterscheiden sollen, durch Variablen abgebildet werden. Für jede Staging-Umgebung wird eine separate Variablen-Datei erstellt. Diese Dateien enthalten die spezifischen Werte und Einstellungen, die für jede Stage unterschiedlich sein können. Helm verwendet diese Variablen, um die Templates im Chart entsprechend anzupassen.

Diese Variablen werden in sogenannten Value-Dateien definiert:

Values-dev.yaml
replicaCount: 2
enableIngress: true

Values-prod.yaml
replicaCount: 8
enableIngress: false

Die definierten Variablen können darauf im Helm Chart mit einer speziellen mustache-Schreibweise genutzt werden. Im nachfolgenden Beispiel wird die variable replicaCount im Deployment verwendet.

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

Jetzt kann Helm instrumentiert werden, indem die Befehle helm upgrade oder helm install verwendet werden. Je nachdem, welche Variablen-Datei mitgegeben wird, werden die unterschiedlichen Konfigurationen im Helm-Chart festgeschrieben. In unserem Beispiel werden in der Produktions-Umgebung 8 Pods und in der Development-Umgebung bloß 2 Pods von Kuberenetes erstellt. Das Helm-Chart kann also an die Anforderungen der jeweiligen Umgebung angepasst werden.

Nach Anpassung des Helm-Charts mithilfe der definierten Variablen erfolgt die direkte Bereitstellung im Kubernetes-Cluster durch Helm. Das automatisiert den Bereitstellungsprozess und gewährleistet eine konsistente sowie zuverlässige Konfiguration für jede Umgebung. Besonders hilfreich ist dabei, dass Helm nicht nur die Variablen ausfüllt, sondern auch die entsprechenden Kubernetes-Objekte direkt an Kubernetes sendet. Vor einem Update überprüft Helm zudem, ob die spezifische Entität tatsächlich von der bereits vorhandenen abweicht, und führt das Update nur durch, wenn das auch notwendig ist. Zusätzlich kümmern sich Kubernetes und Helm selbst um Rolling Updates, bspw. für deployments. Diese ganzheitliche Automatisierung stellt sicher, dass der Bereitstellungsprozess effizient abläuft und eine einheitliche Konfiguration in jeder Umgebung gewährleistet ist.

Darüber hinaus verfügt Helm noch über eine ganze Reihe hilfreicher Funktionen. In Projekten kann es immer wieder vorkommen, dass ganze Kubernetes-Objekte nur auf bestimmten Stages vorhanden sein sollen. Helm ermöglicht dies durch sein komplexes Templating-System, das Flow-Control-Operatoren wie if / else und die range-Syntax für foreach-ähnliche Loops unterstützt.

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

Hier ist der Ingress bloß in der Entwicklungsstufe (DEV) nicht aber in der Produktionsstufe (PROD) angelegt.

Fazit

Auf den ersten Blick mag Helms Motto „so start using Helm and stop the copy-and-paste“ vielleicht etwas ungewöhnlich und nicht gerade intuitiv wirken. Trotz anfänglichen Aufwands bei simplen Architekturen bietet Helm jedoch erhebliche Vorteile in Multistage-Umgebungen, die wir abschließend noch einmal hervorheben möchten.

Durch die Verwendung von Helm wird die Konfiguration des Services im GIT-Repository festgehalten. So verfügt die Konfiguration über eine klare Versionierung und befindet sich an einem logischen Ort, direkt neben dem Quellcode der Anwendung. Dies erleichtert die Nachverfolgung von Konfigurationsänderungen und stellt sicher, dass die Konfiguration immer konsistent mit der Anwendung bleibt. Es ist jedoch wichtig sicherzustellen, dass sensible Informationen wie z. B. Passwörter oder Secrets nicht im Helm-Chart selbst gespeichert werden.

Da ein Helm-Chart immer gleich aufgebaut ist, können sich neue Teammitglieder schneller in die Konfiguration einarbeiten und auch externe Ressourcen haben sich an diese Struktur zu halten.

Ein weiterer Vorteil ergibt sich daraus, dass viele manuelle kubectl-Befehle nicht mehr in einem Terminal eingegeben oder über Jenkins ausgeführt werden müssen. Alles was benötigt wird, ist ein simpler Helm-Befehl. Helm erkennt, wenn sich Konfigurationen geändert haben und aktualisiert nur jene Kubernetes-Entitäten, die sich auch tatsächlich verändert haben. Dadurch ermöglicht Helm einfache Rolling Updates von Deployments und erleichtert die Verwaltung der Anwendung erheblich.

Zudem verfügt Helm über eine Rollback-Funktion, mit der auf frühere funktionierende Versionen des Service zurückgesprungen werden kann, falls eine Änderung sich nicht wie erwartet verhält. Diese Funktion bietet eine zusätzliche Sicherheitsebene, die unerwünschte Auswirkungen von Konfigurationsänderungen minimiert.

Alles in allem gelingen mit Helm eine verbesserte Verwaltung und Bereitstellung von Anwendungen in Multistage-Umgebungen. Es erleichtert die Nachverfolgung von Konfigurationsänderungen, fördert die Einhaltung von Standards, automatisiert den Bereitstellungsprozess und bietet eine robuste Rollback-Funktion. Indem Helm in Entwicklungs- und DevOps-Praktiken eingebunden wird, kann es die Effizienz sowie Zuverlässigkeit deutlich steigern.