Utilisation des plugins Maven/Gradle pour construire des images Docker (Jib, Spring Boot Build Plugin)

Découvrez comment utiliser les plugins Jib et Spring Boot (Buildpacks) pour créer des images Docker optimisées directement depuis Maven ou Gradle, sans Dockerfile.

Pourquoi utiliser des plugins de build pour les images Docker ?

Bien qu'écrire un `Dockerfile` soit l'approche traditionnelle pour créer des images Docker, elle demande une certaine connaissance des bonnes pratiques Docker pour obtenir des images optimisées (utilisation du multi-stage build, gestion des layers, exécution en tant qu'utilisateur non-root, etc.). Pour les développeurs Java et plus spécifiquement Spring Boot, des outils intégrés aux systèmes de build Maven et Gradle offrent des alternatives puissantes.

Ces plugins, comme Jib de Google ou l'intégration Buildpacks du plugin Spring Boot, permettent de générer des images Docker directement depuis votre build Maven ou Gradle, souvent sans nécessiter l'écriture d'un `Dockerfile` et parfois même sans nécessiter l'installation d'un démon Docker local. Ils intègrent des optimisations spécifiques au monde Java pour créer des images plus efficaces, plus rapides à construire (grâce à une meilleure gestion du cache des couches) et potentiellement plus sécurisées.

Adopter ces plugins simplifie le processus de conteneurisation pour les développeurs, en l'intégrant naturellement dans le flux de travail de build existant et en appliquant automatiquement des bonnes pratiques de création d'images.

Jib : Construire sans démon Docker ni Dockerfile

Jib est un projet open-source de Google conçu spécifiquement pour construire des images Docker ou OCI (Open Container Initiative) pour les applications Java. Sa particularité principale est qu'il n'a pas besoin d'un démon Docker installé sur la machine de build et qu'il ne nécessite pas de `Dockerfile`.

Jib fonctionne en analysant votre projet Java (Maven ou Gradle) et en séparant intelligemment l'application en plusieurs couches (dépendances, ressources, classes). Il place ces couches directement dans une image Docker conforme aux bonnes pratiques (par exemple, en utilisant une image de base Distroless pour la sécurité et la légèreté, ou un JRE standard). Cette séparation en couches optimise la reconstruction des images : si seule votre code source change, Jib ne reconstruit que la couche des classes, réutilisant les couches des dépendances (qui changent moins souvent), rendant les builds incrémentiels très rapides.

Les avantages de Jib incluent :

Rapidité : Optimisation des couches et builds incrémentiels.
Reproductibilité : Les builds sont plus déterministes car ils ne dépendent pas d'un démon Docker ou d'un Dockerfile potentiellement variable.
Simplicité : Pas de Dockerfile à maintenir.
Sécurité : Facilite l'utilisation d'images de base minimalistes (comme Distroless) et la création d'images non-root.
Pas de démon Docker requis : Idéal pour les environnements CI/CD où l'installation de Docker peut être complexe ou non souhaitée.

Configuration de Jib avec Maven

Pour utiliser Jib avec Maven, ajoutez le plugin `jib-maven-plugin` à votre `pom.xml` :


    
        
            com.google.cloud.tools
            jib-maven-plugin
            3.4.0 
            
                
                    eclipse-temurin:17-jre-jammy 
                
                
                    docker.io/votre-user/votre-app:${project.version}

Vous pouvez ensuite construire et pousser l'image vers un registre distant (comme Docker Hub) avec :

# Nécessite une authentification préalable au registre (docker login, ou config Jib)
mvn compile com.google.cloud.tools:jib-maven-plugin:build

Ou construire l'image et la charger dans votre démon Docker local (si vous en avez un et que vous voulez tester localement) :

mvn compile com.google.cloud.tools:jib-maven-plugin:dockerBuild

Jib offre de nombreuses options de configuration pour personnaliser l'image de base, les JVM flags, les variables d'environnement, les labels, etc.

Configuration de Jib avec Gradle

Pour utiliser Jib avec Gradle, appliquez le plugin `com.google.cloud.tools.jib` dans votre `build.gradle` ou `build.gradle.kts` :

Exemple (`build.gradle` - Groovy DSL):

plugins {
    id 'com.google.cloud.tools.jib' version '3.4.0' // Utilisez une version récente
    id 'java'
    // ... autres plugins (ex: org.springframework.boot)
}

jib {
    from {
        image = 'eclipse-temurin:17-jre-jammy' // Image de base
    }
    to {
        image = 'docker.io/votre-user/votre-app:' + version // Image cible
        // tags = ['latest'] // Tags optionnels
    }
    // container {
    //     mainClass = 'com.example.MyMainClass'
    //     ports = ['8080']
    // }
}

Pour construire et pousser l'image vers un registre :

# Nécessite une authentification préalable au registre
./gradlew jib

Pour construire et charger l'image dans le démon Docker local :

./gradlew jibDockerBuild

Spring Boot Build Plugin et Cloud Native Buildpacks

Depuis Spring Boot 2.3, le plugin `spring-boot-maven-plugin` (pour Maven) et le plugin `org.springframework.boot` (pour Gradle) intègrent nativement la capacité de construire des images Docker en utilisant les Cloud Native Buildpacks (CNB). Les Buildpacks sont une technologie (initiée par Heroku, puis standardisée par la CNCF) qui transforme votre code source applicatif en une image de conteneur exécutable, sans nécessiter de `Dockerfile`.

Le processus Buildpacks analyse votre application (type, version de Java, framework utilisé comme Spring Boot), détermine les dépendances nécessaires (JRE, agent APM, etc.) et assemble une image Docker en appliquant des optimisations et des bonnes pratiques. Il crée également des couches intelligentes pour maximiser le caching et minimiser la taille des mises à jour. Spring Boot utilise par défaut les Paketo Buildpacks, un ensemble de Buildpacks open-source et modulaires.

L'avantage principal est la simplicité d'utilisation : une seule commande suffit souvent. L'inconvénient est que cela nécessite un démon Docker fonctionnel sur la machine de build, car les Buildpacks s'exécutent eux-mêmes dans des conteneurs ('builder images'). C'est une approche plus opinionnée que Jib, mais très efficace pour obtenir rapidement des images prêtes pour la production.

Utilisation avec Maven (`spring-boot:build-image`)

Avec Maven, si le `spring-boot-maven-plugin` est présent (ce qui est le cas par défaut pour les projets Spring Boot), vous pouvez construire l'image Docker avec la commande :

mvn spring-boot:build-image

Par défaut, l'image sera nommée d'après l'artifactId et la version du projet (ex: `docker.io/library/votre-app:1.0.0`). Vous pouvez personnaliser le nom de l'image dans la configuration du plugin `pom.xml` :


    org.springframework.boot
    spring-boot-maven-plugin
    
        
            docker.io/votre-user/votre-app:${project.version}

Ou en passant un paramètre en ligne de commande :

mvn spring-boot:build-image -Dspring-boot.build-image.imageName=docker.io/votre-user/votre-app:latest

Utilisation avec Gradle (`bootBuildImage`)

Avec Gradle, si le plugin `org.springframework.boot` est appliqué, la tâche `bootBuildImage` est disponible :

./gradlew bootBuildImage

Vous pouvez configurer le nom de l'image et d'autres options dans le bloc `bootBuildImage` de votre `build.gradle` :

bootBuildImage {
    imageName = 'docker.io/votre-user/votre-app:' + version
    // builder = 'paketobuildpacks/builder-jammy-tiny'
    // environment = ['BP_JVM_VERSION': '17']
}

Ou en ligne de commande :

./gradlew bootBuildImage --imageName=docker.io/votre-user/votre-app:latest

Jib vs Buildpacks : Quel plugin choisir ?

Les deux approches sont excellentes et bien meilleures qu'un `Dockerfile` basique pour la plupart des applications Spring Boot. Le choix dépend de vos priorités :

Jib :

✅ Avantages : Pas besoin de démon Docker, builds potentiellement plus rapides (surtout pour les builds incrémentiels), plus de contrôle sur l'image de base et la structure des couches, reproductibilité.
❌ Inconvénients : Moins 'magique', nécessite une configuration minimale dans le fichier de build, peut demander plus d'ajustements pour des cas complexes.

Spring Boot Build Plugin (Buildpacks) :

✅ Avantages : Extrêmement simple à utiliser (souvent une seule commande), approche très opinionnée appliquant les bonnes pratiques (sécurité, layering), gère des cas plus complexes automatiquement (ex: agents APM).
❌ Inconvénients : Nécessite un démon Docker fonctionnel, moins de contrôle direct sur le processus de build (dépend du 'builder' utilisé), peut être plus lent pour le premier build.

Si vous ne pouvez/voulez pas installer Docker sur votre environnement de build (CI/CD), Jib est la solution. Si vous privilégiez la simplicité maximale et faites confiance à l'approche opinionnée des Buildpacks, l'intégration native de Spring Boot est excellente. Les deux génèrent des images optimisées et bien structurées, idéales pour le déploiement dans le cloud ou sur des orchestrateurs comme Kubernetes.

◄ Précédent Suivant ►

く