Profile picture of Philémon GLOBLÉHI
Philémon GLOBLÉHI
Développeur Java
Follow me
Generated by linktime
May 23, 2025
5 points essentiels à garder en tête pour construire une image Docker optimisée, sécurisée et adaptée à la production 👇 1- Utiliser le multi-stage build On compile d’abord l’application dans une image contenant Maven, puis on exécute l’application dans une image plus légère (comme Amazon Corretto ou Eclipse Temurin). Résultat : une image finale propre et compacte. 2- Tirer parti du cache Docker En copiant d’abord le pom.xml puis en exécutant mvn dependency:go-offline, on télécharge les dépendances en amont. Cela permet de ne pas les re-télécharger à chaque modification du code source. 3- Choisir une image d’exécution légère L’image finale ne devrait contenir que ce qui est nécessaire pour faire tourner l’application. Par exemple : amazoncorretto:21-alpine au lieu d’une image Maven complète. 4- Exécuter l’application en tant qu’utilisateur non-root C’est une mesure de sécurité simple mais souvent oubliée. Elle limite les risques en cas d’attaque sur le conteneur. 5- Exposer les bons ports et documenter l’image Même si ce n’est pas obligatoire pour le fonctionnement, exposer les ports et structurer clairement le Dockerfile rend la maintenance plus facile pour l’équipe. --- PS : Vous avez un besoin en architecture backend Java robuste ? Réservez un rendez-vous : https://lnkd.in/ecRArCmt Ou envoyez-moi un message en DM !
Stay updated
Subscribe to receive my future LinkedIn posts in your mailbox.

By clicking "Subscribe", you agree to receive emails from linktime.co.
You can unsubscribe at any time.

74 Likes
May 23, 2025
Discussion about this post
Profile picture of Rayan SAMET Expert Spring Angular AWS
Rayan SAMET Expert Spring Angular AWS
Senior Software Engineer - Freelance
3 months ago
L’étape 1 peut se faire en amont durant ton build au sein d’un job git ou Jenkins webhook pour n’avoir au final qu’à build ton image docker de façon plus light en run et donc avoir juste l’étape 2 dans ton docker file. Ça évite d’avoir une image pour build et une autre pour run.
Profile picture of Kouamé Julien BOSSOMBRA ♾
Kouamé Julien BOSSOMBRA ♾
Computer System Engineer | Enthusiastic DevSecOps & Cloud | Passionate About Innovative CNCF Solutions
3 months ago
Très utile, merci Philémon !
Profile picture of Kevin NZUGUEM
Kevin NZUGUEM
Cloud Software Engineer | {3xAWS , 1xAZURE, 1xK8S, 1xHashiCorp} Certified | {Quarkus, LLM} Lover
3 months ago
Merci pour le partage 👏 Philémon GLOBLÉHI, Voici quelques éléments supplémentaires à prendre en compte : 1. L'image de base pour le runtime : C'est déjà bien de ne pas embarquer du Maven dans une image de PROD, mais on peut viser des images encore plus petites, en optant pour des images contenant juste la JRE et non toute une JDK. L'image amazoncorretto:21-alpine contient une JDK et tous les outils de développement. Tu peux opter pour du eclipse-temurin:21-jre-alpine 2. Profiter du Layering Docker pour optimiser les builds et l'utilisation du stockage sur ta OCI Registry : Une image qui wrappe un JAR ça marche plutôt bien. Mais on peut faire mieux en faisant un unpack du JAR (c'est d'ailleurs la reco de Spring) et avoir les dépendances, ton code et tes properties sur des layers différents. Comme le code change plus fréquemment que tes dépendances, tu auras la layer des dépendances qui changera rarement et tu évitera de stocker plusieurs fois les mêmes dépendances sur ta registry La suite dans ce thread 👇🏽