Que ce soit au sein d’un système d’information d’entreprise (SI) ou sur le WEB, via des flux de fichiers, des API ou encore des files de messages, nos applications communiquent toujours plus avec « l’extérieur », c’est-à-dire avec d’autres programmes. Ceux-ci peuvent ne pas se baser sur les mêmes technologies, ne sont pas plus supposés connaître le fonctionnel ni les spécificités de nos applications, que nous ne connaissons les leurs. Lorsque plusieurs applications doivent interagir de concert pour manipuler des données, la première question qui se pose a l’air toute bête : comment faire référence à ces données? Quelle information connue, même de l’application client si elle est l’instigatrice de la communication et interprétable sans ambiguïté par les deux parties, utiliser ?

Introduction Le Time-To-Market (TTM) indique le temps moyen pour qu’un besoin devienne une fonctionnalité disponible sur le marché. Dans le monde du numérique, une idée passe par plusieurs étapes de transformation et entre les mains de différentes équipes avant de devenir une solution fonctionnelle. En fonction de la taille et de l’activité de l’entreprise, une idée peut être prise en charge par :

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 : Avec un Dockerfile à peu près comme ça :

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

Exécution :

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