The Doppler Quarterly (DEUTSCHE) Frühjahr 2018 | Page 57

Das Team grenzte das Problem auf drei Aspekte ein, die bei dieser Anwen-
dung fehlten:
1. Standardisierte CI/CD-Pipeline für die Automatisierung von Builds und
Implementierung
2. Stabile und wiederholt ausführbare Implementierungen
3. Kleinere und häufigere Releases
Beginn mit einem Basisimage
Zunächst wollten wir den Umfang der Codeänderungen während der Containerisie-
rung minimieren. Damit lässt sich die Komplexität reduzieren, während wir dennoch
die Möglichkeit haben, einen Regressionstest vor und nach dem Plattformwechsel
von VMs zu Containern durchzuführen. Sobald die Anwendung in Containern in der
Produktionsumgebung ausgeführt wurde, wollten wir die Vorteile von Containern
für das Refactoring und die Neugestaltung der Architektur der Anwendung nutzen.
Da es sich hierbei um ein „Lift-and-shift“-Szenario handelte, wurden das
Betriebssystem und die Bibliotheken von der vorhandenen Anwendung defi-
niert. Unser Ziel bestand darin, die beste Vorgehensweise für die Integration
dieser Abhängigkeiten in einen Container zu finden. Die Anwendung erfor-
derte Linux und das Java Development Kit. Daher nutzten wir ein Open-Sour-
ce-Image von Docker Hub, das auf Alpine Linux und OpenJDK basierte. Je nach
Situation gibt es weitere Möglichkeiten, z. B. zertifizierte Images aus dem
Docker Store, falls Sie Support benötigen, oder die Erstellung eines neuen
benutzerdefinierten Images, um die Richtlinien und Tools des Unternehmens
beizubehalten. Die zuletzt genannte Möglichkeit bietet die größte Flexibilität,
erfordert jedoch zusätzlichen Aufwand für Support und Wartung.
Wir erstellten eine Dockerfile aus einem Open-Source-Basisimage, kopierten
die Anwendungs-JAR-Datei in das Dateisystem des Containers und führten
dann die Anwendung aus, indem wir die JAR-Datei aus dem Befehl ausführten.
FRÜHJAHR 2018 | THE DOPPLER | 55