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.

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.

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.

Ihr möchtet mehr zum Thema „Überführung von bestehenden Applikationen in die Cloud“ erfahren? Dann werft auch einen Blick in meinen ersten, zweiten, dritten und vierten Blog-Beitrag.