CoreMedia goes Kubernetes - aber wie?

Vielen CoreMedia Kunden steht mit dem Upgrade auf Version 10 der CoreMedia Content Cloud neben einer Softwaremigration auch eine grundlegende betriebliche Änderung ins Haus:

Wurden ältere CoreMedia Versionen meist manuell oder teilautomatisiert auf dedizierten oder virtuellen Servern deployed, hat CoreMedia mit seinem aktuellen Release den Schritt zur containerbasierten Softwarebereitstellung mit Kubernetes weiter vorangetrieben. Operative Bereiche müssen infolge dessen nicht nur eine passende Containerplattform selbst aufbauen oder als Service einkaufen, sondern auch lernen, die einzelnen Softwarekomponenten und umgebenden Services auf Kubernetes bereitzustellen.

CoreMedia bietet hierzu ein grundlegendes Set an Skripten, basierend auf dem Deployment Management Tool „Helm“ (https://helm.sh/) mit welchem sich eine Standard CoreMedia Applikationsumgebung inklusive der benötigten Datenbanken und Searchengines auf Kubernetes erstellen lässt. Weicht das geplante Setup vom Standard ab, müssen entweder die mitgelieferten Skripte angepasst oder grundlegend neu geschrieben werden.

Die Entscheidung, ob man mit den vorhandenen Helm Charts arbeitet oder nicht, basiert zunächst auf den Unterschieden zwischen der geplanten Zielumgebung und der „All-in-One-Lösung“, die die mitgelieferten Skripte bieten.

Geht es nicht mehr um eine (lokale) Testinstallation, sondern um weiterführende Integrations- und Produktivumgebungen, so werden z.B. üblicherweise Datenbanken durch eigene Datenbankteams aufgebaut und verwaltet. Auch die benötigten Solr Installationen werden oftmals getrennt bereitgestellt und betrieben. Zusätzlich variiert die Anbindung der ausliefernden Schicht an vorgeschaltete Loadbalancing Umgebungen, was Änderungen in den Kubernetes Netzwerk-Services notwendig macht.

Je mehr solcher Abweichungen vorhanden sind, desto aufwändiger wird es, die bestehenden Charts anzupassen und man erreicht den Punkt, an dem das Erstellen neuer Skripte „from scratch“ zielführender ist.

(+) Schnelles Aufsetzen einer All-in-One-Testumgebung inkl. Kubernetes

(+) Vorlage für das grundlegende Vorgehen (StatefulSet vs. Deployments, Init-Container, Limits etc.)

(-) Anwendung für produktive Umgebung mit Abweichungen im Layout

Hat man sich auf Basis dieser Punkte für das Erstellen eigener Skripte entschieden, lohnt sich ein zusätzlicher Blick auf Alternativen zu Helm wie beispielsweise Kustomize.

Was spricht für Helm?

Helm basiert auf Go-Templates und bietet dadurch im Vergleich eine höhere Flexibilität um komplexe Applikationsarchitekturen abzubilden:
Müssen mehrere Umgebungen provisioniert werden und unterscheiden sich diese in größeren Teilen, wie unter anderem der Anzahl der genutzten CoreMedia Komponenten, der Art der eingesetzten Netzwerk Services oder auch den benötigten Monitoring-Parametern, so eignet sich Helm. Mit seinem Template basierten Ansatz lassen sich sehr leicht einzelne Komponenten umgebungsspezifisch an- und abschalten.

Durch Auslagerung der Variablen in eigene Files leidet allerdings die Lesbarkeit der Charts und die Komplexität in der Pflege steigt. Dies kann insbesondere für Teams, die mit CoreMedia gerade neu im Kubernetes Kosmos angekommen sind, zu einer zusätzlichen Hürde werden.

Und was für Kustomize?

Kustomize arbeitet im Gegensatz dazu mit einem Overlay Ansatz und bietet zusätzliche Generatoren für ConfigMaps und Secrets, welche bei inhaltlichen Änderungen ein automatisches Aktualisieren des Deployments veranlassen. Als Basis dienen herkömmliche Kubernetes Manifeste im YAML-Format. Umgebungsspezifische Anpassungen werden in zusätzlichen Overlay-Files (Kustomization) festgehalten, die im gleichen Format angelegt werden und nur die zu ändernden Paramater enthalten.

Gerade Installationen, bei denen sich verschiedene CoreMedia Umgebungen nur in Form einzelner Parameter (DB-Connection, URL-Parameter, Ports) unterscheiden, lassen sich mit Kustomize einfach und übersichtlich konfigurieren. Die Overlay Dateien können in diesem Fall sehr klein gehalten werden und sind für operative Mitarbeiter leicht zu interpretieren.

(+) Basis besteht in der Regel aus gültigen und gut lesbaren Kubernetes-Manifesten

(+) Praktische Generatoren für ConfigMaps und Secrets

(-) Overlays werden unübersichtlich bei großen Unterschieden zwischen Basis und Overlay

(-) Geringere Flexibilität