Continuous Integration und Continuous Delivery (CI/CD) mit Helm Charts und Argo CD
Damit der Fokus auf die Implementierung der kundenspezifischen Anforderungen gesetzt werden kann, ist ein effizientes und automatisiertes Bereitstellen von Webanwendungen in verschiedenen Umgebungen unerlässlich.
In diesem Blogbeitrag zeigen wir einen möglichen Weg dazu auf.
Einführung
Für die Integration und Bereitstellung der von uns entwickelten Anwendungen haben wir bereits verschiedene Methoden eingesetzt, wie beispielsweise PowerShell Scripts oder Azure DevOps Pipelines. Die meisten davon erfordern manuelles Eingreifen, müssen teilweise aufwändig mit der Weiterentwicklung der Anwendung angepasst werden und sind entsprechend anfälliger für Fehler. Um dies zu vermeiden und die konstante Integration und Bereitstellung containerisierten Anwendungen bieten zu können, wird eine vollautomatisierte Lösung eingesetzt.
Kubernetes, Helm und Argo CD
Die Entwicklung skalierbarer, wiederverwendbarer und anpassungsfähiger Anwendungen erfolgt bei uns durch den Einsatz einer Microservice-Architektur, welche in verschiedenen Docker Images resultiert, wie bereits im Blog über die Dapr Runtime erwähnt. Durch den Cloud-native Computing Ansatz haben wir die Möglichkeit, leichtgewichtige Images auf verschiedensten Systemen bereitzustellen.
Kubernetes ist ein System, welches uns die Verwaltung von Container Anwendungen ermöglicht, was auch als «Orchestrierung» bezeichnet wird. Eine zusätzliche Unterstützung ist Helm, welche die Komplexität der Kubernetes Deployments vereinfacht. Dabei werden anhand Yaml Files eine Art Vorlage für das Bereitstellen der Container erstellt, welche einfach wiederverwendet werden können.
Ein sogenanntes Helm Chart besteht dabei aus drei grundlegenden Komponenten:
Das Chart File
Hier werden die Metadaten der Anwendung definiert, wie der Name und die Version.
Das Value File
In diesem File werden die Variablen für die Steuerung der Templates gesetzt, um beispielsweise festzulegen, welches Docker Image verwendet wird oder wie viele Container erstellt werden sollen.
Der Template Ordner
Hier befinden sich die Vorlagen für das Erstellen der Manifeste anhand der Werte aus dem Value File, welche dann von Kubernetes verwendet werden, um die jeweiligen Ressourcen zu erstellen.
Für die Bereitstellung der Anwendung über Continuous Integration und Continuous Delivery sind zusätzliche Komponenten erforderlich:
GitHub Actions, um Unit Tests durchzuführen, die Images zu bilden und diese bei einem neuen Release (getagt und getriggert durch Commits in einem bestimmten Branch) in ein Artifactory (Artefakt Repository) hochzuladen, um sie für das Deployment bereitzustellen.
Argo CD, als deklaratives GitOps Continuous Delivery Tool für Kubernetes. Es automatisiert die Bereitstellung der verschiedenen Komponenten, wofür es die verfügbaren Images aus dem Artifactory verwendet.
Somit bildet das GitHub Repository, aus dem die Images erstellt werden, den single point of truth, welcher auch über die Version entscheidet, die bereitgestellt wird. Dabei ist es üblich, pro Umgebung Regeln festzulegen, wann welche Versionen bereitgestellt werden. Beispielsweise werden in der Entwicklungsumgebung die Container neu bereitgestellt, sobald eine neue Version der Images vorhanden ist (z.B. von der Version v1.3.1 auf v1.3.2). In der produktiven Umgebung macht es keinen Sinn, automatisch zu deployen, da eine neue Version Fehler beinhalten könnte. Hier werden nur Versionen bereitgestellt, die getestet wurden und verifiziert sind.
Herausforderung
Eine Herausforderung bestand darin, die Helm Charts so erstellen zu können, dass sie für verschiedene Umgebungen einfach und leicht angepasst wiederverwendet werden können. In der Entwicklerumgebung darf beispielsweise nicht dasselbe Passwort für eine Datenbank verwendet werden, wie in der Produktionsumgebung.
Eine weitere Herausforderung war das Evaluieren der Helm Charts von bestehenden Softwarekomponenten. Lokal konnten dafür Docker Images vom Hersteller verwendet werden, Helm Charts wurden aber teilweise keine zur Verfügung gestellt. Diese mussten dann von Drittanbietern bezogen werden.
Vor- und Nachteile
+ Ein klarer Vorteil liegt im Einsparen der Zeit für das manuelle Bereitstellen und Integrieren, was bei jeder neuen Anwendung hinzukommt.
+ Die Möglichkeit eines sogenannten Rollbacks bietet die Lösung, bei einem im Feld aufgetretenen Fehler auf eine zuvor funktionierende Version zurückzuwechseln.
+ Diese Art von Setup bringt eine Konsistenz zur Integration und Bereitstellung verschiedenster Anwendungen.
+ Die Automatisierung verhindert Fehler, die bei repetitiven Aufgaben durch den Entwickler auftreten könnten.
- Die gesamte Infrastruktur besitzt eine gewisse Komplexität, die Zeit zum Einarbeiten benötigt.
- Der Aufwand, eine solche Infrastruktur zu betreiben, lohnt sich nicht für eine einzelne Anwendung. Der grosse Nutzen kommt erst bei dem Betreiben mehrerer Anwendungen zum Tragen.
Fazit
Eine hilfreiche Möglichkeit, sich stärker auf die Implementation kundenspezifischer Anforderungen zu konzentrieren, besteht darin, die Integration und Bereitstellung von Anwendungen so automatisiert wie möglich abzuwickeln.
Der einmalige Aufwand, die Workflows und Systeme aufzusetzen, zahlt sich bei dem Wiederverwenden dieser Infrastruktur für weitere Anwendungen aus und vereinheitlicht das Ganze.
Die Verwendung von GitHub Actions erleichtert nicht nur das automatisierte Builden der Images, sondern unterstützt den Entwickler auch in dem bereits vor einem Review Checks und Tests durchgeführt werden.
Kubernetes, Helm und ArgoCD können auf den ersten Blick etwas komplex wirken. Das ist eine Gegebenheit, die sich bei einem gemeinsamen Einsatz wieder löst.
Aufgrund unserer Erfahrung sind wir in der Lage, Projekte mit automatisierter Integration und Bereitstellung rasch umzusetzen. Die erwähnte Einarbeitungszeit fällt für uns weg und es kann sofort gestartet werden.
Wir freuen uns auf Ihre Anfrage.