Die Sources - ein Mix aus YAML und Code

In den Source-YAMLs definieren wir die Bausteine und referenzieren die Konfigurationen. Für unseren orders Microservice sieht diese Datei folgendermaßen aus (→ github):

#@ load("@ytt:data", "data")
#@ load("@k8syaml:main.lib.yaml", "createService", "createDeployment")
 
#@ serviceName = "orders"
 
#@ def getConfig():
    #@yaml/text-templated-strings
    serviceConfig: |
        maximumAmountPerOrder=(@= str(data.values.configs.maxOrderAmount) @)
        someOtherProp=someValue
#@ end
 
  --- #@ createService(serviceName, 8080)
  --- #@ createDeployment(serviceName, config=getConfig(), withDb=True)

Zuerst definieren wir den Namen des Microservice (Zeile 4), der in den beiden Funktionsaufrufen zur Erstellung von Kubernetes-Service und Kubernetes-Deployment verwendet wird. Die aufgerufenen Funktionen (Zeilen 13 und 14) importieren wir (Zeile 2) aus unserer main-Library.

Zusammengefasst bietet diese Library eine Sammlung an Funktionen, die wiederum YAML-Fragmente mit (internen) Funktionen kombinieren. Diese Kombination hält die YAML-Fragmente einerseits übersichtlich und bietet andererseits enorm vielfältige Möglichkeiten der Ausgestaltung. So entsteht eine mächtige und flexible Mischung aus statischem YAML und dynamischer Programmierung.

Die für den Microservice benötigte Konfiguration geben wir per Multiline-String in die createDeployment()-Funktion. Innerhalb dieses Strings laden wir die produktspezifischen Konfig-Werte (hier nur einer, in Zeile 9) die den Standard-Werten innerhalb der createDeployment()-Funktion hinzugefügt werden. Auf diese Weise erhalten wir die finale Konfig-Datei, die dann in den Container gemountet wird.

Haben wir alle Bauteile und Konfigurationen zusammen, ist es Zeit, die YAMLs zu erzeugen, die wir im Cluster betreiben wollen. Dazu erschaffen wir uns ein kleines Bash-Skript, das uns für alle 4 benötigten Produkte sämtliche Kubernetes-Resourcen erzeugt. Diese wenden wir nun per kubectl apply... im Cluster an. Damit sind die Produkte live. Fertig - denken wir.

Nach kurzer Zeit fällt uns allerdings auf, dass der Datenbanktreiber Probleme mit der Entropie hat. Um das Problem zu lösen, müssten wir allen Pods mit Containern, die eine Datenbankverbindung aufbauen, einen bestimmten Datei-Mount hinzuzufügen. Also erweitern wir die createDeployment()-Funktion und starten unser Generierungs-Skript erneut.

Der Commit 44ae035 zeigt uns die daraus resultierenden Änderungen (bei Fehlern oder Problemen könnten wir gegensteuern) und die Auswirkung auf die generierten YAMLs: Mit wenigen Zeilen und einem kleinen if konnten wir alle betroffenen Deployments (orders, stock) anpassen.

Natürlich sind nicht immer alle Änderungen derart einfach zu integrieren. Trotzdem illustriert dieses kleine Beispiel das Potenzial sehr gut. Wäre der Fehler erst später aufgefallen, nachdem noch 7 weitere Produkte hinzugekommen sind, wäre die Änderung die gleiche gewesen, hätte aber trotzdem alle 13 Produkte angepasst.