Weitere Überlegungen

In diesem Abschnitt werden allgemeine Überlegungen zur Java-Containerisierung behandelt, die nicht spezifisch für Java-EE-Anwendungen sind.

Verwenden eines kleineren Basis-Images

Wir empfehlen, ein kleines (weniger als 500 MB) und gut gepflegtes Basis-Image zu erstellen. Durch die Verringerung der Größe des Basis-Images sinken Ihre Netzwerk- und Betriebskosten. Ein kleineres Basis-Image kann auch die Sicherheit verbessern, da die Anzahl der Komponenten, die ausgenutzt werden könnten, reduziert wird. Sie können eines der auf Debian basierenden Distributionsabbilder verwenden. Auf den Images ist die Mindestanzahl an Tools installiert und sie enthalten keine Paketmanager oder Shells. Diese streuungsfreien Images reduzieren auch die gesamte Angriffsfläche. Streuungsfreie Images können kleiner als 150 MB sein. Weitere Informationen finden Sie im Repository „Distroless“ Container Images GitHub .

Es hat sich bewährt, dem Verfügbarkeitsprinzip zu folgen und eine schnelle Startup-Zeit für Ihre Container-Images festzulegen. Mithilfe von Techniken wie ahead-of-time-compilation(OpenJDK-Dokumentation) oder der gemeinsamen Nutzung von Anwendungsklassendaten (OpenJDK-Dokumentation) können Sie die Gesamtstartzeit verbessern, indem Sie Java-Klassen vor dem Start der virtuellen Maschine in systemeigenen Code kompilieren und eine Reihe von Klassen in einer gemeinsam genutzten Archivdatei vorverarbeiten lassen. Sie können GraalVM auch verwenden, um minimale Docker-Images für Java-Anwendungen zu erstellen. Weitere Informationen finden Sie im Blogbeitrag Using GraalVM to Build Minimal Docker Images for Java Applications. AWS

Führen Sie ein Upgrade auf eine containerfähige JDK-Version durch

Vor JDK 8u131 erkannte die JVM keine Speicher- oder CPU-Limits, die von der Docker-Engine mithilfe von Flags festgelegt wurden. Das bedeutet, dass JVM immer dann, wenn Sie Ihre Anwendung in einem Container ausführen, die Gesamtzahl der auf dem System verfügbaren Prozessoren oder, im Fall von virtuellen Maschinen, das virtuelle System „sieht“. Das Gleiche gilt für die standardmäßigen Speicherlimits: Die JVM schaut sich den Gesamtspeicher des Hosts an und verwendet diesen, um die Standardeinstellungen festzulegen. Folglich kann die JVM mehr Speicher beanspruchen, als die Container-Plattform ihr erlaubt, was dazu führt, dass der Java-Prozess durch die Container-Plattform (Docker) beendet wird. Eine Lösung für dieses Problem besteht darin, Ihre Java-Anwendung vor der Containerisierung entweder auf Java 9 oder 8u131+ zu migrieren. Java 10 und spätere Versionen verfügen über eine vollständige Containererkennung und -unterstützung.