Konzeption zur Überführung von bestehenden Applikationen in die Cloud (Teil 4)

Wie ihr wisst, handelt es sich bei einem Pod um die Gruppierung von einem oder mehreren Docker-Containern. Neben den zuvor beschriebenen Technologien gibt es noch einige Features, Tools und Möglichkeiten, die ihr bei der Arbeit mit Pods kennen solltet. Diese möchte ich euch nacheinander vorstellen und euch zum Abschluss den Zusammenhang zwischen den vorgestellten Technologien aufzeigen.

EFK-Stack

Hinter den Buchstaben EFK verbergen sich die folgenden Technologien:

• E = Elasticsearch – ein Objektspeicher, in dem alle Logeinträge gespeichert werden
• F = Fluentd – sammelt die Logs von den Nodes und überführt diese zu Elasticsearch
• K = Kibana – eine Weboberfläche für Elasticsearch

Sobald dieser EFK-Stack erfolgreich konfiguriert ist, besitzt ihr ein projektübergreifendes Monitoring sowie ein Log Aggregation Tool innerhalb von OpenShift. Dieses Tool ist besonders im Entwicklungsprozess für einen neuen Pod sehr wichtig, da es alle Logs sammelt - auch die Logs von zerstörten Docker Layern. In der Entwicklung ist dieses Tool hilfreich, da das Terminal innerhalb von OpenShift nur Informationen logt, wenn der Pod noch „lebt“. Durch den EFK-Stack erhaltet ihr somit zusätzliche Informationen, selbst von nicht lauffähigen oder zerstörten Pods.

Liveness- und Readiness- Probe

Bei der Liveness- und Readiness-Probe handelt es sich um ein Kubernetes Feature, das die Funktionalität der erstellten Pods prüft. Wogegen geprüft werden soll, könnt ihr innerhalb der YAML-Konfigurationsdatei des jeweiligen Pods festlegen. Die Liveness-Probe sollte dabei so gewählt werden, dass die Hauptfunktion des jeweiligen Pods sichergestellt ist. Sobald diese nicht mehr gewährleistet ist, greift die Liveness-Probe und startet den Pod neu.

Die Readiness-Probe stellt sicher, dass der Pod arbeitsbereit ist und Daten akzeptieren kann. Diese Probe prüft jede Instanz einer Pod-Gruppe. Ein Pod gilt als „ready“, wenn alle enthaltenen Container arbeitsbereit sind. Sollte diese Probe fehlschlagen, wird der Pod nach einer Weile herunterskaliert, da er als „not ready“ klassifiziert wird.

Vergleichen wir die Liveness- und Readiness-Probe mit einem Beispiel, wird das Ganze sicher deutlicher: Stellt euch vor, ihr möchtet ein Eis essen und besucht eine Eisdiele. Sie muss geöffnet sein (Liveness-Probe) und in den Eisbehältern müssen unterschiedliche Eissorten vorhanden sein, aus denen ihr wählen könnt (Readiness-Probe).

Die Liveness- und Readiness-Probe ist nicht zwingend erforderlich bei der Pod-Erstellung. Dennoch stellt sie ein wichtiges Instrument dar, um die Funktionsfähigkeit der jeweiligen Pods sicherzustellen. Überlegt ihr, dieses Feature einzusetzen, solltet ihr euch im Vorfeld überlegen, was genau getestet werden soll.

Secrets

Bei einem „Secret" kann es sich um Passwörter (Key-Value), Dateien oder um einen Lizenzschlüssel handeln. Ein Lizenzschlüssel wird für eine Anwendung innerhalb eines Pods benötigt - entweder zum Ausführen der Anwendung oder zur Authentifizierung der Services untereinander. Hier kommen wir zu einem größeren und generellen Problem bei der Entwicklung innerhalb einer Cloud-Plattform: Bis jetzt ist eine Lizenz meist Hardware- oder Namensgebunden und auf eine Instanz beschränkt. Dies ändert sich allerdings innerhalb der Cloud. Die Pods können nämlich bei einem Neuaufsetzen auf einer darunterliegenden Hardware oder Node ausgeführt werden. Zudem kann sich bei der Nutzung eines definierten ReplicaSet (mehrere Instanzen eines Pods) der spezifische Pod-Name ändern, da dieser durch Kubernetes initialisiert und gemanagt wird. Hierbei muss das Lizensieren einer Anwendung neu überdacht werden. Ein Ausweg aus dieser Lage kann darin bestehen, Technologien zu nutzen, die bereits für solche Fälle konzipiert sind. Daher solltet ihr die einzusetzenden Technologien im Vorfeld genau untersuchen. Der Best Practice zur Ablage von Secrets ist übrigens ein Mounted Volume.

Sticky Sessions

Durch die Möglichkeit zur Skalierung von Webservern innerhalb der Cloud und den Einsatz von Load Balancern – sie verteilen die Anfragen auf die einzelnen Webserver – werden Sticky Sessions immer wichtiger. Sie schreiben dem Load Balancer vor, dass dieser alle Anfragen eines Clients an denselben Webserver richten soll. Solltet ihr keine Sticky Sessions konfiguriert haben, steht es dem Load Balancer frei, an welchen Webserver er die Anfrage weiterleitet.

Service Account

Ein weiteres Kubernetes Feature sind die Service Accounts. Sie stellen eine Identität für Prozesse zur Verfügung, die in einem Pod ausgeführt werden. Wenn die Administratoren auf einen Dienst zugreifen möchten, müssen sie sich vorab bei einem Server authentifizieren. Bei Prozessen, die in den Pods laufen, kann es ebenfalls vorkommen, dass sie sich bei Diensten authentifizieren müssen. An dieser Stelle benötigt ihr dann den Service Account des jeweiligen Pods. Bei der Erstellung eines Pods müsst ihr keinen Service Account anlegen, es wird nämlich automatisch ein „default“-Service Account erstellt. Natürlich habt ihr auch die Möglichkeit, einem Service Account übergreifende Privilegien zu geben.

Makefile

Hinter dem Begriff „make“ verbirgt sich ein Buildtool, mit dem ihr das Kompilieren von Quellcode steuern könnt. Der Einsatz von make eignet sich besonders bei größeren Projekten, in denen einzelne Arbeitsschritte nacheinander abgearbeitet werden müssen und wo Abhängigkeiten der Dateien untereinander bestehen. Ein mögliches Beispiel ist die Überführung einer Anwendung in die Cloud. Dabei müssen Abhängigkeiten der Pods untereinander berücksichtigt werden. Für jeden zu erstellenden Pod sollte auch ein lokales Makefile in der Ordnerstruktur vorhanden sein. In ihm können die Befehle zur Erstellung des Pods, zum Erstellen des Images, zum Löschen und zur Neuinstallation des Pods deklariert werden. Über die lokalen Makefiles der einzelnen Pods sollte ein übergeordnetes – also globales - Makefile existieren, das in der Lage ist, die Befehle der lokalen Makefiles nacheinander auszuführen.

Im Folgenden seht ihr den Zusammenhang zwischen den vorgestellten Technologien unter Berücksichtigung der OpenShift Container Platform innerhalb einer lokalen Entwicklungsumgebung. Die virtuelle Maschine (VM) ist als Wolke dargestellt. Damit soll eine Verknüpfung zur Cloud angedeutet weden. Der blaue Punkt innerhalb des OpenShift-Logos (roter Kreis) symbolisiert einen Pod, der innerhalb eines Nodes läuft. Der Nexus ist in dieser Darstellung außerhalb der Cloud-Plattform zu sehen - er lässt sich aber auch in die Cloud-Plattform integrieren.

Ausblick

Wie ihr gesehen habt, gibt es unterschiedliche Tools, die euch bei der Arbeit mit Pods unterstützen. Ich hoffe, dass ich euch mit meinen Ausführungen sowie mit der illustrierten Darstellung einen guten Überblick verschaffen und etwas Licht ins Dunkel bringen konnte.

In meinem nächsten Blog-Beitrag geht es um die Möglichkeiten zur Pod-Erstellung in OpenShift. In diesem Zusammenhang werde ich euch zwei verschiedene Modelle – die Docker-Strategie und die Source-to-Image-Strategie - vorstellen.

Weitere Beiträge dieser Blog-Serie:

Konzeption zur Überführung von bestehenden Applikationen in die Cloud (Teil 1)
Konzeption zur Überführung von bestehenden Applikationen in die Cloud (Teil 2)
Konzeption zur Überführung von bestehenden Applikationen in die Cloud (Teil 3)
Konzeption zur Überführung von bestehenden Applikationen in die Cloud (Teil 5)