Introduction Jib

De Reservoircode
Aller à : navigation, rechercher

Principe

Jib permet de créer une image Docker ou OCI d'une application Java, sans la nécessité de créer un fichier dockerfile ou même d'avoir Docker installé sur sa machine. Jib repense donc la conteneurisation de son application en passant du workflow suivant :

Application -> Création Image Dokcer -> Build Application -> Build Image Docker -> Push registry Docker

à

Application -> Cartographie de l'application -> Push registry
            `-> application des changements -> Push registry 

Ainsi, Jib simplifie le workflow de création de déploiement des conteneurs d'application Java en ne construisant que ce qui est nécessaire.

En effet, si une des couches d'application change, Jib se chargera de créer un layer Docker en embarquant que les modifications apportées à cette couche. Les couches prisent à charge par Jib sont :

  • Le code,
  • Les ressources,
  • Les dépendances...

Exemple d'application

Pour tester rapidement Jib, nous allons partir de l'application spring-petclinic de Spring.

$ git clone https://github.com/spring-projects/spring-petclinic.git

Lancement la commande Jib sans intégration Maven

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

...

[INFO] Getting base image gcr.io/distroless/java
[INFO] Building dependencies layer...
[INFO] Building resources layer...
[INFO] Building classes layer...
[INFO] Loading to Docker daemon...
[INFO] Finalizing...
[INFO] 
[INFO] Container entrypoint set to [java, -cp, /app/libs/*:/app/resources/:/app/classes/, org.springframework.samples.petclinic.PetClinicApplication]
[INFO] 
[INFO] Built image to Docker daemon as petclinic:2.0.0.BUILD-SNAPSHOT
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 17.834 s
[INFO] Finished at: 2018-07-16T13:50:07+02:00
[INFO] ------------------------------------------------------------------------

Voir l'image Docker générée

$ docker images
REPOSITORY          TAG                    IMAGE ID            CREATED             SIZE
petclinic           2.0.0.BUILD-SNAPSHOT   806b4b892a9b        48 years ago        158MB

Lancement de l'application Dockerisée

$ docker run --rm -p 8080:8080 petclinic:2.0.0.BUILD-SNAPSHOT
...
...
2018-07-16 11:53:50.934  INFO 1 --- [  restartedMain] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http) with context path ''
2018-07-16 11:53:50.937  INFO 1 --- [  restartedMain] o.s.s.petclinic.PetClinicApplication     : Started PetClinicApplication in 5.754 seconds (JVM running for 6.093)

L'application est prête à l'emploi

Jib image 1.png

Mis à jour de le conf. pour ajouter la langue française

Jib image 2.png

Après lancement de l'application, nous avons l'application mise à jour

Jib image 3.png

Intégration Maven

Ajout du plugin

L'intégration dans son application est simple, il faut commencer par déclarer le plugin dans le POM

<project>
  ...
  <build>
    <plugins>
      ...
      <plugin>
        <groupId>com.google.cloud.tools</groupId>
        <artifactId>jib-maven-plugin</artifactId>
        <version>0.9.6</version>
        <configuration>
          <to>
            <image>mon_application</image>
          </to>
        </configuration>
      </plugin>
      ...
    </plugins>
  </build>
  ...
</project>

Le lancement du plugin se fera par la commande suivante :

$ mvn compile jib:dockerBuild

Branchement dans cycle Maven de packaging

Afin d'éviter le lancement d'un goal Maven précis, on peut brancher notre commande Maven sur la phase package.

<plugin>
  <groupId>com.google.com.tools</groupId>
  <artifactId>jib-maven-plugin</artifactId>
  ...
  <executions>
    <execution>
      <phase>package</phase>
      <goals>
        <goal>build</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Exemple de customisation possible

Si l'on souhaite utiliser une image from dédiée et non pas celle par défaut (distroless), on peut spécifier les options suivantes :

  • from
  • jvmflags
  • arguments
  • les ports à écouter...

Comme par exemple :

<configuration>
  <from>
    <image>openjdk:alpine</image>
  </from>
  <to>
    <image>localhost:5000/my-image:built-with-jib</image>
    <credHelper>osxkeychain</credHelper>
  </to>
  <container>
    <jvmFlags>
      <jvmFlag>-Xms512m</jvmFlag>
      <jvmFlag>-Xdebug</jvmFlag>
      <jvmFlag>-Xmy:flag=jib-rules</jvmFlag>
    </jvmFlags>
    <mainClass>mypackage.MyApp</mainClass>
    <args>
      <arg>some</arg>
      <arg>args</arg>
    </args>
    <ports>
      <port>1000</port>
      <port>2000-2003/udp</port>
    </ports>
    <format>OCI</format>
  </container>
</configuration>

Conclusion

Jib semble avoir un avenir dans les équipes ne souhaitant pas ou n'ayant pas l'envie ou n'ayant pas le besoin d'avoir un background Docker important. Mais dans la plupart des équipes Java, l'industrialisation d'une CI Jenkins/Docker/Kubernetes est un prérequis dans le démarrage de projet, donc ce genre de produit s'adressera en premier aux équipes souhaitant démarrer vite et bien une application Java sous Docker.