Quarkus : un environnement local pour plusieurs services
Quarkus a déjà résolu la partie que la plupart des frameworks font mal : le mode dev recharge à l'enregistrement et les Dev Services vous montent un conteneur pour la base de données que vous aviez oublié de démarrer. Ce qu'il ne résout pas, c'est le service d'à côté, ni le suivant.
Où s'arrête le mode dev
- C'est par service. Cinq services, ce sont cinq terminaux, cinq modes dev et il faut se souvenir du port que chacun a pris.
- Les Dev Services sont eux aussi par service. Chacun qui veut une base de données emporte son propre conteneur. C'est très bien pour isoler et c'est mauvais pour un flux où trois services lisent le même topic Kafka.
- Les URLs entre services restent votre affaire. Chaque
@ConfigPropertyou URL de base d'un client REST qui pointe vers un autre service doit bien pointer quelque part quand vous ne montez pas tout le système. - L'ordre compte toujours. Le rechargement n'aide pas si la dépendance ne répondait pas au démarrage de celui qui l'appelle.
Ce qu'ajoute Aseptic
Aseptic détecte un service Quarkus par son manifeste et le démarre comme un processus
natif avec votre outil de build, en injectant la configuration au démarrage sous forme
de propriétés -D ou de variables d'environnement. Les URLs entre services
sont réécrites là, si bien que application.properties reste exactement tel
qu'il est dans git.
Un scénario, c'est le flux : les services qui y participent, l'ordre dont ils ont besoin et où se résout chaque dépendance —un service local, votre environnement partagé dans le cloud ou un mock—. Les ports qui entrent en collision sont remappés et c'est la nouvelle valeur qui est communiquée à ceux qui appellent.
Pour l'infrastructure commune, Aseptic monte Kafka, Redis et PostgreSQL dans Docker une seule fois, pour tout le scénario, et fait pointer tous les services vers la même instance. C'est là la différence avec les Dev Services : un broker partagé par le flux, au lieu d'un par service. Si pour une exécution précise vous préférez les Dev Services, rien ne vous en empêche : Aseptic démarre votre service comme vous le lui dites.
Des bibliothèques que vous modifiez en même temps
Si la fonctionnalité couvre un service et une de vos bibliothèques, Aseptic construit la bibliothèque et la lie là où Maven et Gradle la résolvent, en la reconstruisant et en la reliant à chaque changement. Le fichier de build du consommateur n'est jamais modifié, et délier ne défait que ce qu'Aseptic avait posé.
Ce qu'il ne fait pas
Il ne remplace pas le mode dev, et il ne devrait pas : recharger à l'enregistrement est l'affaire de Quarkus et il le fait mieux que ne pourrait l'ajouter n'importe quel lanceur. Il ne construit pas d'images natives et n'exécute pas de cluster Kubernetes, donc tout ce que vous devez vérifier à ce niveau relève d'ailleurs. Et il a besoin de Docker installé pour l'infrastructure commune.
Il est en bêta publique, publié pour Windows, macOS et Linux, et gratuit pour un usage personnel.
À côté des alternatives
Si vos services sont déjà conteneurisés et se déploient avec des manifestes que vous maintenez, Tilt et Skaffold vous donnent une boucle qui a la forme de la production. La page des alternatives à Docker Compose couvre tout le terrain.
Il existe des équivalents de cette page pour Spring Boot et pour Node.
Questions fréquentes
Le mode dev de Quarkus ne me suffit-il pas ?
Pour un service, il est excellent. Ce que le mode dev ne résout pas, c'est qui démarre les autres, dans quel ordre et contre quoi : dès que le flux traverse trois services, cette partie reste la vôtre.
Aseptic casse-t-il le rechargement à chaud de Quarkus ?
Non. Le service est démarré comme un processus natif avec sa propre commande, donc le rechargement à chaud reste celui d'habitude.
Puis-je mélanger Quarkus avec des services d'une autre technologie ?
Oui. Le moteur ne contient aucune logique propre à une technologie donnée : chaque stack a son profil et ils peuvent cohabiter dans un même scénario.