Conteneurisation d'applications Java avec Docker : guide étape par étape

Docker, Java et pourquoi cela change la donne

Imaginez : vous avez écrit une super application Java. Elle fonctionne sur votre MacBook, mais quand vous la donnez à un collègue sous Windows — tout se casse. Familier ? Et si le serveur est sous Linux ? Inutile de deviner — l'histoire classique du "ça marche sur ma machine".

La conteneurisation avec Docker résout ce problème une fois pour toutes. Vous empaquetez l'application avec son environnement (JVM, bibliothèques, dépendances) dans un conteneur léger qui s'exécute de la même manière partout. Pour Java, c'est particulièrement pertinent — car nous avons l'habitude du "Write Once, Run Anywhere", mais en pratique cet idiome échoue souvent à cause des versions de JDK, des bibliothèques système ou des configurations.

Dans cet article, nous allons détailler la conteneurisation d'applications Java avec Docker de A à Z. Vous apprendrez à écrire un Dockerfile, optimiser l'image, utiliser Docker Compose et éviter les pièges courants. C'est parti !

Qu'est-ce que Docker et pourquoi en a-t-on besoin en tant que développeur Java ?

Docker est une plateforme pour empaqueter, livrer et exécuter des applications dans des environnements isolés — les conteneurs. Contrairement aux machines virtuelles, les conteneurs utilisent le noyau commun de l'OS, mais ont leur propre espace de fichiers, réseau et processus. Cela les rend légers (mégaoctets, pas gigaoctets) et rapides (lancement en quelques secondes).

Pour un développeur Java, Docker offre trois super-pouvoirs :

\n
• Reproductibilité — plus de "ça marche chez moi". Si le conteneur se lance localement, il se lancera sur n'importe quel serveur.
\n
• Isolation — chaque application vit dans son propre monde, sans interférer avec les autres. Vous voulez deux applications Java avec des versions de JDK différentes ? Facile.
\n
• Mise à l'échelle — les conteneurs se clonent, s'équilibrent et s'orchestrent facilement (Kubernetes, Docker Swarm).
\n

Premier Dockerfile pour une application Java

Commençons simplement. Nous avons une application Java standard (par exemple, Spring Boot ou simplement Main.java). Nous voulons l'empaqueter dans une image Docker. La manière la plus simple est d'utiliser l'image officielle OpenJDK.

Voici un Dockerfile minimal :

# Utilisation de l'image officielle OpenJDK 17\nFROM openjdk:17-jdk-alpine\n\n# Définition du répertoire de travail\nWORKDIR /app\n\n# Copie du fichier JAR dans le conteneur\nCOPY target/my-app.jar /app/my-app.jar\n\n# Lancement de l'application\nCMD ["java", "-jar", "my-app.jar"]

Maintenant, construisons l'image et lançons le conteneur :

# Construction de l'image\ndocker build -t my-java-app .\n\n# Lancement du conteneur\ndocker run -p 8080:8080 my-java-app

Tout fonctionne. Mais c'est un mauvais exemple. Pourquoi ? Analysons cela.

Problème n°1 : Taille de l'image

L'image openjdk:17-jdk-alpine pèse environ 150 Mo. C'est correct, mais si vous y ajoutez toutes les dépendances, la taille peut atteindre 500+ Mo. Pour la production, c'est beaucoup.

Problème n°2 : Build et runtime dans la même image

Nous copions un JAR déjà prêt, ce qui signifie que la construction (mvn clean package) doit être faite à l'avance. Il est préférable d'utiliser une construction multi-étapes (multi-stage build) pour séparer l'étape de compilation de l'étape d'exécution.

Optimisation : construction multi-étapes (multi-stage build)

L'idée est simple : dans la première étape, nous utilisons une image avec Maven et JDK, nous compilons le projet, et dans la seconde — seulement JRE et le JAR final. Cela réduit l'image finale de plusieurs fois.

# Étape de construction\nFROM maven:3.8.5-openjdk-17 AS builder\nWORKDIR /build\nCOPY pom.xml .\nCOPY src ./src\nRUN mvn clean package -DskipTests\n\n# Étape d'exécution\nFROM openjdk:17-jre-alpine\nWORKDIR /app\nCOPY --from=builder /build/target/my-app.jar /app/my-app.jar\nEXPOSE 8080\nCMD ["java", "-jar", "my-app.jar"]

Qu'est-ce qui a changé ?

\n
• La première étape (builder) contient Maven et JDK — elle n'est nécessaire que pour la compilation.
\n
• La seconde étape utilise une image JRE légère (~50 Mo