Considérations supplémentaires

Cette section couvre les considérations générales relatives à la conteneurisation Java qui ne sont pas propres aux applications Java EE.

Utilisation d'une petite image de base

Nous vous recommandons de créer une petite image de base (moins de 500 Mo) et bien gérée. La diminution de la taille de l'image de base permet de réduire vos coûts de réseau et d'exploitation. Une image de base plus petite peut également améliorer la sécurité en réduisant le nombre de composants exploitables. Vous pouvez utiliser l'une des images sans distroless basées sur Debian. Les images comportent le nombre minimal d'outils installés sur elles et ne contiennent pas de gestionnaires de packages ni de shells. Ces images sans distroless peuvent également réduire la surface d'attaque globale. Les images sans distroless peuvent être inférieures à 150 Mo. Pour plus d'informations, consultez le référentiel d'images GitHub de conteneurs « Distroless ».

Il est recommandé de suivre le principe de cessibilité et de développer un temps de démarrage rapide pour vos images de conteneurs. En utilisant des techniques telles que ahead-of-time-compilation(documentation OpenJDK) ou le partage de données de classe d'application (documentation OpenJDK), vous pouvez améliorer le temps de démarrage global en compilant les classes Java en code natif avant de lancer la machine virtuelle et en autorisant le prétraitement d'un ensemble de classes dans un fichier d'archive partagé. Vous pouvez également utiliser GraalVM pour générer des images Docker minimales pour les applications Java. Pour plus d'informations, consultez le billet de blog Utiliser GraalVM pour créer des images Docker minimales pour les applications AWS Java.

Mise à niveau vers une version du JDK compatible avec les conteneurs

Avant le JDK 8u131, la JVM ne reconnaissait pas les limites de mémoire ou de processeur définies par le moteur Docker à l'aide d'indicateurs. Cela signifie que chaque fois que vous exécutez votre application dans un conteneur, la JVM « voit » le nombre total de processeurs disponibles sur le système ou, dans le cas de machines virtuelles, sur le système virtuel. Il en va de même pour les limites de mémoire par défaut : la JVM examinera la mémoire globale de l'hôte et l'utilisera pour définir ses valeurs par défaut. Par conséquent, la JVM peut réclamer plus de mémoire que ne le permet la plateforme de conteneur, ce qui entraîne la fin du processus Java par la plateforme de conteneur (Docker). Une solution à ce problème consiste à migrer votre application Java vers Java 9 ou 8u131+ avant de la conteneuriser. Java 10 et versions ultérieures offrent une prise en compte et une prise en charge complètes des conteneurs.