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.

Innerhalb der Abbildung ist euch sicher der Schritt „Run build“ aufgefallen, da er mit einem Stern markiert ist. Hier werden Quelldateien, Skripte und Artefakte im „Run build“ entpackt und das „assemble“-Skript wird im „Run build“ aufgerufen.

Sollte das oben genannte Problem - „tar“ oder „/bin/sh“ sind nicht bekannt - bestehen, wird beim zweiten Aufruf des Schritts „Run build“ nur noch das „assemble“-Skript aufgerufen. Schließlich wurden die Quelldateien, Skripte und Artefakte bereits im Schritt „Docker build importing scripts and source“ hinzugefügt.

Fünf Skripte für den S2I-Prozess

Innerhalb des S2I-Prozesses gibt es fünf mögliche Skripte, die zum Einsatz kommen können und die ich euch abschließend kurz vorstellen möchte:

1. „assemble“-Skript: Das „assemble“-Skript ist innerhalb des S2I-Prozesses zwingend notwendig. Es ist für den Bau der Anwendungsartefakte aus der jeweiligen Quelle verantwortlich und packt sie nach Fertigstellung in das entsprechende Verzeichnis innerhalb des Images.

2. „run“-Skript: Das „run“-Skript ist, wie das „assemble“-Skript, ebenfalls im S2I-Prozess erforderlich. Dieses Skript hat nämlich die Aufgabe, die erstellte Anwendung zu starten.

3. „save-artifacts“-Skript: Anders als die zunächst genannten Skripte könnt ihr das „save-artifacts“-Skript optional einsetzen. Es beschleunigt den Build-Prozess, indem es die Artefakte von einem Build in den nächsten „rettet“. Hierzu werden die Artefakte in eine „tar“-Datei gepackt und automatisch von S2I beim nächsten Imagebau hinüberkopiert.

4. „usage“-Skript: Mit dem „usage“-Skript kann einem Benutzer mitgeteilt werden, wie das erstellte Image richtig zu nutzen ist - ähnlich einer Readme-Datei. Allerdings stellt auch dieses Skript keine Voraussetzung dar.

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 4)

5. „test/run“–Skript: Das „test/run“-Skript – ebenfalls optional – kann in einem einfachen Prozess erstellt werden und prüft, ob das Image korrekt funktioniert.

Fazit

In meiner Blog-Serie habt ihr erfahren, welche Technologien sich eigenen, um bestehende Applikationen in die Cloud zu überführen, welche Vor- und Nachteile verschiedene Cloud-Plattformen haben, welches Vorgehen sich bewährt hat und welche Technologien ihr in diesem Zusammenhang unbedingt kennen solltet. Sicherlich konnte ich an der einen oder anderen Stelle nur an der Oberfläche kratzen, aber ich hoffe, dass ich euch einfach und verständlich erklären konnte, wie ihr am besten vorgeht.