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

In meinen letzten Beiträgen habt ihr erfahren, was Pods eigentlich sind und welche Features, Tools und Möglichkeiten es gibt, die ihr bei der Arbeit mit Pods kennen solltet. Abschließend möchte ich euch zeigen, welche Möglichkeiten es zur Pod-Erstellung in OpenShift gibt und euch in diesem Zusammenhang verschiedene Build-Strategien vorstellen.

Möglichkeiten der Pod-Erstellung in OpenShift

Wenn ihr einen lauffähigen Pod in OpenShift erstellen möchtet, dann könnt ihr aus den drei folgenden Build-Strategien wählen:

• Docker-Strategie (Docker build)
• Source-to-Image-Strategie (Source to Image (S2I) build)
• Benutzerdefinierte Strategie (Custom build)

Aber was genau ist eigentlich ein Build? Dabei handelt es sich um einen Prozess, bei dem Eingabeparameter oder Quellcode in ein lauffähiges Image überführt werden.

OpenShift nutzt an dieser Stelle bereits vorhandene Basis-Images, die anschließend durch ein Dockerfile oder Skript modifiziert werden. Diese werden in der eigenen oder, besser gesagt, in der integrierten Docker-Registry als Build Images abgelegt. OpenShift unterstützt standardmäßig Docker Builds und S2I Builds.

Bei der Docker- und S2I-Strategie entstehen lauffähige Images. Bei Anwendung der benutzerdefinierten Strategie entstehen hingegen Objekte, die von dem Builder-Image-Autor festgelegt werden. Benutzerdefinierte Objekte haben – da sie, wie der Name schon sagt, benutzerdefiniert sind – keine allgemeine Gültigkeit. Da diese Objekte von Fall zu Fall unterschiedlich ausfallen, möchte ich an dieser Stelle nicht näher darauf eingehen.

Die Docker-Strategie

Mit Docker lassen sich innerhalb von OpenShift lauffähige Images erzeugen, die anschließend als Pod durch Kubernetes gestartet werden können. Mit anderen Worten: Ein jeweiliges Image könntet ihr quasi als „Baumaterial“ und Kubernetes als eine Art „Bauplan“ betrachten. Beides wird benötigt, um ein funktionierendes Objekt, also den Pod, zu erzeugen.

Die Docker-Strategie in OpenShift verhält sich im Wesentlichen analog zum normalen Docker-Build-Prozess. Übrigens: Bei der Docker-Strategie wird hier der Build-Befehl (docker build) aufgerufen. Um einen Build-Prozess zu starten, benötigt ihr innerhalb eurer Ordnerstruktur ein Dockerfile, wo die Schritte zur Erstellung beziehungsweise zur Modifikation des Docker Images festgelegt werden. Wenn ihr innerhalb des bereits lauffähigen Pods Artefakte benötigt, müssen diese bereits während des Build-Prozesses vorhanden sein. Eure grundlegende Ordnerstruktur für die Erstellung eines Pods würde dann bei Verwendung der Docker-Strategie folgendermaßen aussehen:

• Pod-Ordner-Name

  • Dockerfile

Source-to-Image-Strategie

Im Gegensatz zur Docker-Strategie ist die Source-to-Image-Strategie (S2I) wesentlich komplexer. Allerdings hat dieser Ansatz einige Vorteile: Bei S2I handelt es sich um eine Eigenentwicklung von Red Hat, die im Zusammenhang mit OpenShift entstand. Diese Strategie sieht vor, dass Anwendungen in Docker-basierte Container kopiert werden, um anschließend ein neues Image zu erzeugen. In den aktuellen OpenShift-Versionen ist es aber nur möglich, Artefakte in „tar“-gepackte Dateien innerhalb des S2I-Prozesses hinzuzufügen. Im Umkehrschluss heißt das: Ein Ausgangsimage muss in der Lage sein, „tar“-Dateien zu verarbeiten. Des Weiteren sollte das Kommando „/bin/sh“ bekannt sein. Sind beide Dinge unbekannt, dann ist der S2I-Prozess gezwungen, einen zusätzlichen Container Build durchzuführen, um die Dienste bereitzustellen.