Immer mehr Unternehmen verlagern ihre Anwendungen in die Cloud und stehen dabei vor der Wahl: "Lift and Shift" oder die Lösungen cloud-native neu aufsetzen – wobei dieser Begriff sehr unterschiedlich ausgelegt wird. Dieser Beitrag widmet sich dem zweiten Ansatz und stellt eine Technik vor, die beim Überführen von Anwendungen in Container (z. B. Docker) und deren Orchestrierung mit Kubernetes gute Dienste leistet.
Quelle: iStockPhoto
Die Bootstrapping-Herausforderung
DevOps und Cloud-Migrationen versprechen unter anderem, den Aufwand im klassischen Betrieb durch Automatisierung manueller Prozesse spürbar zu senken. Besonders mächtig ist der deklarative Ansatz von Kubernetes, der den gewünschten Zustand Ihrer Anwendungen automatisch sicherstellt. Manchmal brauchen Anwendungen aber "Bootstrapping"-Schritte, bevor sie sauber laufen, oder müssen in einer bestimmten Reihenfolge gestartet werden, um Abhängigkeiten zu anderen Systemen wie Queues oder Datenbanken aufzulösen.
Damit die App zuverlässig startet, könnten Sie sie um eine eigene Retry-Logik erweitern, die so lange wiederholt, bis die Bedingungen passen – das verzögert allerdings Ihre Migration. Eine Alternative ohne Eingriffe in den Code: kleine Apps, Skripte oder Befehle erstellen und als InitContainers einbinden.
Mögliche Anwendungsfälle für Init Containers
- Eine Blockchain-App, die sich bei ihren Peers registrieren muss
- Eine App, die ein Access Token von einem Identity Provider abrufen muss
- Dynamische Daten, die aus einer Datenbank geladen und für den App-Start zwischengespeichert werden
- Verschlüsselte Secrets aus einem Vault holen und ins Dateisystem schreiben
- App-Start blockieren, bis ein anderes System verfügbar ist (z. B. eine Queue oder ein Datenbankserver)
Einfaches Beispiel mit zwei Busybox-Images
Nehmen wir an, eine App soll vor dem Start dynamisch mit Daten befüllt werden (wie in den Szenarien oben). Das ließe sich zwar auch mit einer ConfigMap umsetzen – um die Möglichkeiten dieser Technik zu veranschaulichen, lohnt sich aber der Blick auf weitere Szenarien.
- Einen PersistentVolumeClaim anlegen
Zunächst brauchen wir ein Storage-Volume, auf das wir zugreifen können.
Persistent Volume Claim
$ kubectl apply -f test-pvc.yamlpersistentvolumeclaim/test-pvc created
2. Eine Deployment-Konfigurations-YAML erzeugen
$ kubectl create deployment test-app --image=busybox:1.28.0 -o yaml --dry-run > test-app.yaml
3. Deployment bearbeiten und Volume sowie Init Container wie folgt ergänzen
Deployment mit Init Container
In dieser Datei haben wir das Volume hinzugefügt und im initContainer ein weiteres Busybox-Image eingebunden. Das könnte jedes beliebige Image sein – für dieses Beispiel wollte ich lediglich etwas Inhalt in eine Datei im gemounteten Dateisystem schreiben. Startet die App anschließend mit dem zweiten Busybox-Image, greift sie auf die Datei zu und liest deren Inhalt aus.
4. Deployment ausführen und Logs beobachten
# deploy app
$ kubectl apply -f test-app.yamldeployment.apps/test-app configured# monitor logs
$ kubectl logs -f deployment/test-appFile content: Hello, World!
Wenn Sie "File content: Hello, World!" sehen, hat es geklappt. Auf Basis dieses einfachen Beispiels können Sie Ihre App anpassen, das Haupt-Container-Image austauschen und beliebig viele weitere Init Containers ergänzen, damit Ihre App mit allem startet, was sie braucht. Der Clou: Sie automatisieren das Deployment Ihrer Apps, ohne komplexe Retry-Logik oder Fehlerbehandlung schreiben zu müssen, um vormals manuelle Abhängigkeiten abzubilden.
Weitere Informationen zu Init Containers finden Sie in der offiziellen Kubernetes-Dokumentation: