Einleitung
Im ersten Teil haben wir gesehen, wo man einen bereits vorhanden Chart findet (Helm Hub) und wie man diesen auf einem Kubernetes Cluster installiert. Wir haben uns angeschaut, wie man eigene Konfigurationen an den Chart übergeben kann und wie man ein Upgrade und Rollback durchführt. Heute wollen wir noch einen Schritt weiter gehen und uns anschauen, wie man einen eigenen Chart erstellen kann.
Aufbau eines Chart
Wollen wir uns als erstes anschauen, wie ein Helm Chart aufgebaut ist. Am einfachsten erstellen wir uns hierfür einen eigenen Chart. Helm bietet uns einen einfachen Befehl, mit dem wir das Grundgerüst unseres eigenen Chart erstellen können.
|
|
Schauen wir uns an, was passiert ist. Es wurde ein Ordner erstellt, in dem die erforderlichen Konfigurationen liegen.
|
|
Chart.yml
In dieser Datei befinden sich die Metadaten des Charts, wie Name, Beschreibung, Typ und Version. ApiVersion muss immer gesetzt werden und ist für Helm 3 “v2”.
|
|
Verzeichnis: charts
Dieses Verzeichnis ist leer. Wir haben hier die Möglichkeit bereits bestehende Charts hinzuzufügen, welche für unseren Chart benötigt werden, also Abhängigkeiten. Eine weitere und von Helm bevorzugte Möglichkeit Abhängigkeiten hinzuzufügen, ist als dependencies Feld in der Chart.yaml
Datei. Wir können hier Abhängigkeiten hinzufügen und anschliessend mit dem Befehl helm dependency update
diese Abhängigkeiten in den charts Ordner herunterladen.
Für unser einfaches Beispiel brauchen wir diese Funktion aber erstmal nicht.
|
|
Weitere Informationen dazu findet man auf der Helm Seite.
Verzeichnis: templates
Nun kommen wir zu dem Herzstück unseres Charts. In diesem Verzeichnis finden sich alle Konfigurationsdateien, welche wir für die Installation auf dem Kubernetes Cluster benötigen. Alle Dateien, die sich im templates Verzeichnis befinden, werden durch die Helm Template Rendering Engine gesendet. Die Ergebnisse der Templates werden gesammelt und anschliessend zu Kubernetes gesendet.
|
|
Wir sehen hier verschiedene Dateien, welche bereits von Helm für uns angelegt wurden.
-
NOTES.txt
:- Das ist der Hilfetext für einen Chart. Dieser wird dem Benutzer angezeigt, wenn er helm install ausführen
-
deployment.yaml
,service.yaml
,hpa.yaml
,ingress.yaml
,serviceaccount.yaml
:- Grundgerüste um eine Kubernetes Resource zu erstellen
-
_helpers.tpl
:- Hier befinden sich Helper für Templates, welche im Chart wiederverwendet werden können.
-
tests
:- Hier befinden sich Tests um die Funktionalität des Charts im Cluster zu verifizieren.
values.yaml
Die values.yaml
Datei ist wichtig um die Templates zu parsen. Hier befinden sich alle Default Werte, welche vom Benutzer mit helm install
oder helm upgrade
überschrieben werden können.
Mit diesem Wissen können wir nun unseren ersten eigenen Chart entwickeln.
Der erste eigene Chart
Wollen wir mit einem einfach Beispiel starten. Dafür löschen wir im Ordner templates erstmal alle Dateien, damit wir unser kleines Tutorial von Grund auf beginnen können.
|
|
Anschliessend erstellen wir unser erstes eigenes Template. Wir erstellen eine Datei mit dem Namen configmap.yaml
mit folgendem Inhalt:
|
|
In der Datei haben wir nun eine unbekannte Syntax.
{{ .Release.Name }}
und {{.Values.myName}}
. Beides sind spezielle Platzhalter, welche durch die Template Rendering Engine ersetzt werden.
{{ .Release.Name }}
wird, wie der Name schon sagt, dynamisch durch den Namen des Release ersetzt, welchen wir beim Installieren angeben.
{{.Values.myName}}
wird durch das Property myName aus der Datei values.yaml
ersetzt. Schauen wir uns dafür diese Datei einmal genauer an.
|
|
Nun haben wir bereits einen vollständig lauffähigen und installierbaren Chart. Schauen wir uns an, was bei der Installation passiert. Dafür können wir dem install Befehl das Flag --dry-run
anhängen um die Installation lediglich zu simulieren. Mit --debug
aktivieren wir “verbose” Output.
|
|
Wie wir sehen können wurden unsere Platzhalter wie gewünscht ersetzt. Nun können wir unseren Chart installieren. Wir wollen aber bei der Installation nicht den Default Name “b-nova” nutzen, sondern wollen einen eigenen Namen vergeben. Weiter oben haben wir bereits gesehen, dass wir die Werte durch Angabe einer eigenen values.yaml
Datei, oder durch das --set
Flag bei der Installation überschreiben können. Wir wollen an dieser Stelle die zweite Variante versuchen.
|
|
Success! Der Chart wurde erfolgreich installiert und der Default-Name wurde mit dem dynamischen Wert ersetzt. Jetzt wollen wir noch einmal verifizieren, ob unsere ConfigMap auch wirklich richtig deployed wurde. Wir schauen also mit kubectl
direkt auf dem Cluster nach.
|
|
Wie wir sehen wurde die ConfigMap mit dem richtigen Namen angelegt. Schauen wir uns zur Vollständigkeit auch noch den Inhalt an.
|
|
Den gesamten Code findet ihr im im b-nova Github
Auch der Inhalt entspricht dem erwarteten Ergebnis. Wir haben damit erfolgreich unseren ersten Chart erstellt und auf unserem Cluster installiert.
Next Steps:
Helm Charts hat im Managed Container Umfeld eine grosse Zukunft. Wir werden die Entwicklung von Helm daher gespannt weiterverfolgen. Im nächsten TechUp will ich mit euch die folgenden Themen an einem praktischen Beispiel anschauen:
-
Monocular - das Frontend für Helm
-
Ein eigenes Repository hosten
-
Template:
-
Template Functions und Pipelines
-
Flow Control
-
Built-In Objects
-
Named Templates
-
Subcharts
-
Debugging Templates
-
Post Rendering
-
File Handling
-
-
Best practices
Viel Spass und stay tuned!