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