C’est tout nouveau, c’est tout frais, Google vient d’annoncer et de publier Jib, un outil pour “Build Java Docker images better”.
https://cloudplatform.googleblog.com/2018/07/introducing-jib-build-java-docker-images-better.html
Mais, pourquoi Jib ?

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 :

FROM java:8
WORKDIR /
ADD jeanmichel.jar jeanmichel.jar
CMD java - jar jeanmichel.jar

Et, pour ordonnancer ce workflow, l’outil de CI 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).

Alors pourquoi Jib ?

Jib vient avec plusieurs promesses :

1. Simplifier le workflow pour le réduire à une seule phase, full Java, directement géré 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 : fini 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 inputs donneront la même image Docker.

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).

<plugin>
  <groupId>com.google.cloud.tools</groupId>
  <artifactId>jib-maven-plugin</artifactId>
  <version>0.9.2</version>
  <configuration>
    <to>
      <image>nomDeLimage</image>
    </to>
  </configuration>
</plugin>

Exécution :

# Build et push sur un registry (à configurer, en particulier les credentials)
$ mvn compile jib:build
# Build et push en utilisant le client Docker local
$ mvn compile jib:dockerBuild

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

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 (3 couches distinctes) et paramètre l’entrypoint suivant :

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

• Il pousse sur un registry distant (paramétrable) ou utilise le client Docker local

On aime

• L’effet WOW. Ca 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 espace de la séparation en couches de l’image.

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.
• Actuellement pas de solution de débug ni de paramétrage du javaagent. Les flags JVM sont cependant utilisables via la variable d’environnement JAVA_TOOL_OPTIONS.

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