Conteneurisation d'applications Kotlin avec Docker : Guide complet

Pourquoi la conteneurisation Kotlin est-elle un must-have pour le développeur moderne ?

Imaginez la situation : vous avez écrit une super application Kotlin sur votre MacBook. Tout fonctionne parfaitement. Vous envoyez le code à un collègue sous Windows — la base de données ne se connecte pas. À un autre sous Linux — la version du JDK n'est pas la bonne. Ça vous parle ? Docker résout ce problème une fois pour toutes.

La conteneurisation d'applications Kotlin n'est pas seulement une tendance à la mode. C'est un moyen de garantir que votre application fonctionnera de la même manière sur n'importe quelle machine : du laptop d'un junior au serveur de production sur AWS. Dans cet article, nous allons voir comment empaqueter correctement une application Kotlin dans une image Docker, optimiser sa taille et la configurer pour la production.

Ce que vous allez apprendre :

\n
• Comment écrire un Dockerfile pour une application Kotlin avec Gradle
\n
• Comment réduire la taille de l'image de 3 à 5 fois
\n
• Comment utiliser Docker Compose pour lier Kotlin + base de données
\n
• Best practices pour la conteneurisation en production
\n

Dockerfile de base pour une application Kotlin

Commençons par le simple. Supposons que vous ayez une application Kotlin standard qui se compile avec Gradle. La première idée qui vient à l'esprit — prendre une image JDK, copier les sources et lancer la compilation. Faisons cela, mais en tenant compte immédiatement des best practices.

Compilation monolithique (à ne pas faire en production)

# Dockerfile\nFROM gradle:7.6-jdk17 AS build\nWORKDIR /app\nCOPY build.gradle.kts settings.gradle.kts ./\nCOPY src ./src\nRUN gradle build --no-daemon -x test\n\nFROM openjdk:17-jdk-slim\nWORKDIR /app\nCOPY --from=build /app/build/libs/app.jar app.jar\nEXPOSE 8080\nCMD ["java", "-jar", "app.jar"]

Cette approche fonctionne, mais elle présente trois inconvénients majeurs :

\n
• Taille : l'image pèse environ 400-500 Mo à cause du JDK complet
\n
• Mise en cache : à la moindre modification des sources, Gradle téléchargera à nouveau les dépendances
\n
• Sécurité : l'image conserve les outils de compilation qui ne sont pas nécessaires à l'exécution
\n

Compilation optimisée : multi-étapes et mise en cache

La véritable magie de Docker réside dans les multi-stage builds. Nous allons diviser le processus en trois étapes :

\n
• Téléchargement des dépendances (mis en cache)
\n
• Compilation de l'application
\n
• Image finale minimale
\n

Dockerfile correct pour Kotlin + Gradle

# Stage 1 : Téléchargement des dépendances\nFROM gradle:7.6-jdk17 AS dependencies\nWORKDIR /app\nCOPY build.gradle.kts settings.gradle.kts ./\nRUN gradle dependencies --no-daemon\n\n# Stage 2 : Compilation\nFROM dependencies AS build\nCOPY src ./src\nRUN gradle build --no-daemon -x test\n\n# Stage 3 : Image finale\nFROM eclipse-temurin:17-jre-alpine\nWORKDIR /app\nCOPY --from=build /app/build/libs/app.jar app.jar\nRUN addgroup -S appgroup && adduser -S appuser -G appgroup\nUSER appuser\nEXPOSE 8080\nCMD ["java", "-jar", "app.jar"]

Qu'est-ce qui a changé ?

\n
• Alpine JRE au lieu du JDK complet — l'image est réduite à ~120 Mo
\n
• Mise en cache des dépendances — si build.gradle.kts n'a pas changé, Docker utilise le cache
\n
• Sécurité — l'application est lancée par un utilisateur non privilégié
\n

Compilation avec Gradle Wrapper (méthode recommandée)

Si vous utilisez Gradle Wrapper (et vous devriez !), le Dockerfile devient encore plus élégant. Le Wrapper garantit que la version de Gradle sera la même pour tous les développeurs et dans le CI/CD.

FROM eclipse-temurin:17-jdk-alpine AS builder\nWORKDIR /app\nCOPY gradlew gradlew.bat ./\nCOPY gradle ./gradle\nRUN ./gradlew --version\n\nCOPY build.gradle.kts settings.gradle.kts ./\nRUN ./gradlew dependencies --no-daemon\n\nCOPY src ./src\nRUN ./gradlew build --no-daemon -x test\n\nFROM eclipse-temurin:17-jre-alpine\nWORKDIR /app\nCOPY --from=builder