Tutoriel pour apprendre à utiliser Jib, un outil pour construire des images Docker pour Java

Olivier Levitt

C'est tout nouveau, c'est tout frais, Google vient d'annoncer et de publier Jib, un outil pour « Build Java Docker images better ».

Nous vous proposons dans cet article de découvrir cet outil Jib.

Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum Commentez .

- Titre : Tutoriel pour apprendre à utiliser Jib, un outil pour construire des images Docker pour Java

- Auteur : Olivier Levitt

- Parution : 3 septembre 2019

- Licence : Copyright ® 2019 Olivier Levitt. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. L'existant

- II. Alors pourquoi Jib ?

- III. Comment ça marche Jib ?

- IV. Le dessous des cartes

- V. On aime

- VI. On aime moins

- VII. Conclusion

- VIII. Remerciements

I - L'existant

Bon, on ne va pas se mentir, construire des images Java pour Docker n'est pas vraiment quelque chose de nouveau et révolutionnaire, il y a déjà de nombreuses possibilités pour ce faire et ça ressemble en général à ça :

(Source cloudplatform.googleblog.com (https://cloudplatform.googleblog.com/2018/07/introducing-jib-build-java-docker-images-better.html))

Avec un Dockerfile à peu près comme ça :

Dockerfile

1. FROM java:8

2. WORKDIR /

3. ADD jeanmichel.jar jeanmichel.jar

4. CMD java - jar jeanmichel.jar

Et, pour ordonnancer ce workflow, vous pouvez utiliser l'outil d’intégration continue de votre choix. Avec en général une phase de build / push de l'image qui se fait en dehors de maven (sauf si vous utilisez le plugin dockerfile-maven de Spotify).

II - Alors pourquoi Jib ?

Jib vient avec plusieurs promesses :

1. simplifier le workflow pour le réduire à une seule phase, full Java, directement gérée par le plugin maven / plugin et sans configuration (pas besoin de Dockerfile) ;

2. accélérer le process en s'appuyant de façon intelligente sur le système de couches de Docker. En séparant par exemple les couches dépendances, ressources et classes. Les builds sont donc plus incrémentaux et plus rapides : finie la couche unique non réutilisable parce qu'une ligne de code a changé dans le fatjar ;

3. garantir la reproductibilité de votre image en se basant sur les métadonnées maven / gradle. Les mêmes entrées donneront la même image Docker.

III - Comment ça marche Jib ?

Jib promet de s'occuper de tout pour vous, du début (le code de votre projet), à la fin (l'image docker poussée dans un registry).

(Source cloudplatform.googleblog.com (https://cloudplatform.googleblog.com/2018/07/introducing-jib-build-java-docker-images-better.html))

Concrètement, il s'agit simplement d'un plugin maven (existe aussi en version gradle) offrant un goal qui réalise l'ensemble du process.

Configuration dans le pom.xml :

Plugin maven Jib

1. <plugin>

2. <groupId>com.google.cloud.tools</groupId>

3. <artifactId>jib-maven-plugin</artifactId>

4. <version>0.9.2</version>

5. <configuration>

6. <to>

7. <image>nomDeLimage</image>

8. </to>

9. </configuration>

10. </plugin>

Exécution :

1. # Build et push sur un registry (à configurer, en particulier les credentials)

2. $ mvn compile jib:build

3. # Build et push en utilisant le client Docker local

4. $ mvn compile jib:dockerBuild

Et… voilà ! Une image Docker de votre application est disponible sur le registry cible !

IV - Le dessous des cartes

Mais en fait, il fait quoi Jib ?

- il intègre son propre moteur (light), 100 % Java, de Docker (build et push) ;

- il repart d'une image distroless (il est possible d'utiliser d'autres images comme base) et y copie les dépendances, ressources et classes de votre projet (trois couches distinctes) et paramètre l'entrypoint suivant :

Entrypoint

java -cp /app/libs/*:/app/resources/:/app/classes/ votreClasseMainDetecteeAutomatiquement

- il pousse sur un registry distant (paramétrable) ou utilise le client Docker local.

V - On aime

- l'effet « WOW ». Ça marche, out of the box, en un copier-coller de conf ;

- l'implémentation full Java du build / push Docker. Jib n'a pas besoin de client ou de démon Docker sur la machine. Très pratique pour dockeriser dans des environnements contraints ;

- l'approche « intelligente » du projet Java. Jib profite au maximum de la puissance de maven / gradle pour comprendre l'organisation et les spécificités d'un projet Java ;

- les gains en temps et en espace liés à la séparation en couches de l'image.

VI - On aime moins

- le défaut de ses qualités : en masquant la complexité, il permet moins de flexibilité. Par exemple, il ne s'occupe pas du tout des applications Jakarta EE (Java EE). Globalement, on a du mal à l'imaginer comme outil structurant un gros projet ;

- l’absence actuellement de solution de débogage ainsi que de paramétrage du javaagent. Les flags JVM sont cependant utilisables via la variable d'environnement JAVA_TOOL_OPTIONS.

VII - Conclusion

Jib propose une approche pensée et implémentée 100 % Java pour dockeriser vos projets. Il est incroyablement simple de prise en main et très efficace.
Il souffre évidemment de défauts de jeunesse (première version en février 2018 et officialisation publique début juillet 2018) et troque de la flexibilité au profit de l'efficacité.
Jib est-il l'outil parfait pour vos besoins ? Faites l'essai !

https://github.com/GoogleContainerTools/jib

VIII - Remerciements

Cet article a été publié avec l'aimable autorisation de Olivier Levitt. L'article original (Jib, Java + Docker en mode facile ?) peut être consulté sur le blog/site de Zenika.

Nous tenons à remercier Escartefigue pour sa relecture orthographique attentive de cet article puis Winjerome et Mickael Baron pour la mise au gabarit.