Packaging

L'application Open ENT peut être packagée sous plusieurs formes :

• Bibliothèque JAR : pour une intégration dans d'autres projets.
• Fat JAR : un JAR contenant toute l'application ou un module (voir launcher), appelé fat JAR ou uber-JAR.
• Container Docker : pour une déploiement containerisé.

Il existe 3 profils Maven pour chaque forme de package à préciser en ligne de commande :

• Bibliothèque JAR : mvn package
• Fat JAR : mvn package -Pfat
• Container Docker : mvn package -Pjib
• Container Docker avec un déploiement automatique : mvn package -Premote
• Container Docker avec une image native : mvn package -Pnative

Le mode par defaut construit Open ENT sous forme de bibliothèque JAR d'où le fait de ne pas préciser un profil avec l'option -P.

warning

Les profils permettant de construire sous forme de containers doivent être utilisés pour un déploiement dans Docker-compose ou Kubernetes.

Autres profils Maven

D'autres profils permettent de déployer l'application. Voir la partie publication

Packaging 'Fat' JAR

Un fat jar (ou uber jar) est un fichier JAR qui contient non seulement le code de votre application, mais aussi toutes ses dépendances (bibliothèques externes, frameworks, etc.) empaquetées dans un seul fichier JAR exécutable.

Cela permet de simplifier le déploiement d'une application Java, car tout le nécessaire pour son exécution est inclus dans ce seul fichier. Il est couramment utilisé pour des applications déployées dans des environnements où la gestion des dépendances externes est complexe ou peu pratique.

Caractéristiques principales d'un fat jar :

• Autonome : Le fat jar embarque toutes les dépendances, ce qui permet de l'exécuter directement sur n'importe quelle JVM sans avoir besoin de les installer séparément.

• Simplicité de déploiement : Vous n'avez besoin de déployer qu'un seul fichier, ce qui rend le déploiement plus simple, surtout dans des environnements comme les serveurs ou les conteneurs.

• Taille importante : Le principal inconvénient est la taille du fichier, qui peut devenir très volumineux si l'application a de nombreuses dépendances.

Avec ce packaging, l'application ou le module peuvent être lancés directement avec la commande java -jar <module>.
Les Fat JARs sont disponibles dans le répertoire target du launcher ou des modules.

Pour construire un Fat JAR à partir d'un module, du launcher ou du répertoire principal :

mvn package -Pfat

Exemple de lancement pour le module catalog :

java -jar ./modules/catalog/target/catalog-1.0-SNAPSHOT-runner.jar

Packaging de bibliothèque

C'est le mode par défaut ne demandant de préciser un package :

mvn package

Packaging Docker

Container Docker construit avec JIB

Le packaging sous forme de container Docker est réalisé avec JIB, qui permet la construction automatique des containers.
Cela permet de toujours utiliser des images avec les derniers patchs de sécurité, en s'appuyant sur un container de base géré par Google.

Pour construire l'application avec Docker à partir du répertoire principal :

mvn package -Pjib

Vous pouvez spécifier la version du container et demander une publication immédiate dans un registre de containers :

mvn package -Pjib -Dquarkus.container-image.tag=1.0 -Dquarkus.container-image.push=true -Dmaven.test.skip=true

Par défaut, les containers sont publiés dans GitHub.

🦸‍♂️

Attention : Si vous n'êtes pas contributeur au projet Open ENT, il ne sera pas possible de pousser les containers dans GitHub. Il faut donc ajouter l'option suivante :

-Dquarkus.container-image.push=false

tip

Vous pouvez utiliser votre propre registre d'images avec l'option quarkus.container-image.registry :

-Dquarkus.container-image.registry=<votre-registre>

Exemple avec le registre docker.io :

mvn package -Pjib -Dquarkus.container-image.build=true -Dquarkus.container-image.push=true -Dquarkus.container-image.registry=docker.io -Dmaven.test.skip=true

Container Docker avec une image binaire native

Une image native avec Quarkus fait référence à une application Quarkus compilée en une image binaire native à l'aide de GraalVM, qui permet de générer un exécutable autonome. Contrairement à une application Java classique qui s'exécute sur une JVM, une image native est optimisée pour démarrer très rapidement et consommer moins de mémoire, car elle n'inclut que les éléments nécessaires à l'exécution.

Voici les principales caractéristiques d'une image native avec Quarkus :

Temps de démarrage réduit : Les applications natives démarrent en quelques millisecondes, ce qui est utile dans des environnements comme les conteneurs ou le cloud, où des démarrages rapides sont nécessaires. Consommation de mémoire réduite : Une image native utilise moins de mémoire par rapport à une application fonctionnant sur la JVM, car elle ne charge pas les parties inutilisées de la bibliothèque standard. Exécutable autonome : L'application native ne nécessite pas de JVM pour s'exécuter, car elle est directement compilée dans un fichier binaire pour l'OS cible.

Container Docker pour le développement

Ce mode permet de développer localement et de déployer directement le code sur le serveur dans le container.
Il accélère le développement des correctifs dans un environnement spécifique.

Les containers en mode développement remote ont un suffixe -dev dans leur version pour être correctement utilisés par le chart Helm.
Exécutez la commande suivante pour construire un container en mode remote :

mvn package -Dquarkus.container-image.build=true -Dquarkus.container-image.tag=1.0.1-dev -Dquarkus.container-image.push=true -Dmaven.test.skip=true -Premote

Lancer un module en développement remote

Avec un container construit en mode remote, il est possible de lancer la commande remote-dev avec le profil -Premote pour activer le déploiement de code en direct :

mvn quarkus:remote-dev -Dquarkus.live-reload.url=https://openent.tech.fr -Dquarkus.live-reload.password=openent -Premote

Cette version améliore la structure et la lisibilité, tout en ajoutant des précisions sur les commandes et les contextes d'utilisation.