Un guide des microservices Java. Partie 2 : Déploiement et tests

Traduction et adaptation des microservices Java : un guide pratique . Lien vers la première partie du guide . Tout programme Java côté serveur, et donc tout microservice, n'est qu'un fichier avec une extension .jar ou .war. Il y a une grande chose à propos de l'écosystème Java, ou plutôt de la JVM : vous n'avez besoin d'écrire du code Java qu'une seule fois et il peut fonctionner sur presque tous les systèmes d'exploitation, à condition que vous n'ayez pas compilé votre code avec une version de Java plus récente que votre version cible de la JVM. C'est important à comprendre, surtout lorsqu'il s'agit de sujets comme Docker, Kubernetes ou (roulements de tambour !) le Cloud. Pourquoi? Examinons différents scénarios de déploiement.

Exemple de déploiement de microservice Java minimaliste

Continuons avec l'exemple de la banque. Nous avons donc un fichier monobank.jar (monolithe) et notre Riskengine.jar nouvellement extrait (le premier microservice de vérification des risques). Supposons également que les deux applications, comme toutes les autres applications dans le monde, ont besoin d'un fichier .properties. Dans notre cas, il ne contiendra que l'URL de la base de données et les informations d'identification. Un déploiement minimal peut être constitué de deux répertoires ressemblant à ceci : Premièrement :

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 monobank-384.jar

ubuntu@somemachine:/var/www/www.monobank.com/java$ java -jar monobank-384.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Deuxième:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 risk-engine-1.jar

ubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Cela laisse la question ouverte : comment les fichiers .properties et .jar parviendront-ils au serveur ? Malheureusement, il peut y avoir plusieurs réponses.

Comment utiliser les outils de build, SSH et Ansible pour déployer des microservices Java

Des conseils ennuyeux, mais non moins excellents sur la façon de déployer des microservices Java... En fait, exactement de la même manière que les administrateurs système ont déployé n'importe quel programme serveur Java dans les entreprises au cours des 20 dernières années. Voici le mélange :

• votre outil de build préféré (Maven, Gradle)
• bon vieux SSH/SCP pour copier des .jars sur des serveurs
• Scripts Bash pour gérer les scripts de déploiement et les serveurs
• ou encore mieux : quelques scripts Ansible.

Bien entendu, cela ne convient pas aux innovateurs qui ont besoin d’un cloud « respirant », de serveurs avec équilibrage de charge automatique, etc. C'est une vieille école vraiment ennuyeuse. Pourtant ça marche !

Comment utiliser Docker pour déployer des microservices Java

Revenons à la douce agonie du choix. Il y a quelques années, Docker est entré en scène, et avec lui la conteneurisation. Si vous n'avez jamais travaillé avec, voici une brève description destinée aux utilisateurs finaux et aux développeurs :

• Un conteneur (simplifié) s’apparente à la bonne vieille machine virtuelle, mais « plus léger ». Si vous ne savez pas ce que signifie « plus facile » dans ce contexte, veuillez consulter cette réponse sur Stackoverflow .
• Le conteneur garantit sa propre portabilité. Autrement dit, cela fonctionne n'importe où. Cela vous semble familier, n'est-ce pas ?

C'est drôle qu'étant donné la portabilité et la rétrocompatibilité de la JVM, cette fonctionnalité ne semble pas être un tel avantage. Vous pouvez simplement télécharger JVM.zip sur n'importe quel Raspberry Pi (ou même téléphone mobile), l'extraire et exécuter n'importe quel fichier .jar. La situation change dans des langages comme PHP ou Python, où les incompatibilités de versions ou les paramètres de déploiement sont plus complexes. Ou si votre application Java dépend de nombreux autres services installés (avec les numéros de version corrects) : par exemple, une base de données Postgres ou un magasin de valeurs de clés Redis. Ainsi, le principal avantage de Docker pour les microservices Java, ou plus précisément pour les applications Java, est le suivant : la possibilité de mettre en place des environnements de test ou d'intégration homogénéisés à l'aide d'outils comme Testcontainers . Les développements complexes sont plus faciles à installer. Prenez le logiciel de forum Discourse . Vous pouvez l'installer avec une seule image Docker, et cette image contient tout ce dont vous avez besoin, du logiciel Discourse écrit en Ruby, à une base de données Postgres, en passant par Redis, jusqu'à l'évier de la cuisine. Si vos déploiements sont similaires ou si vous souhaitez exécuter une jolie petite base de données Oracle, essayez Docker. Donc pour résumer, au lieu de simplement regarder le fichier .jar, vous :

• regroupez votre fichier jar dans une image Docker
• transférer cette image vers un registre Docker privé
• extrayez et exécutez cette image sur votre plate-forme cible
• ou copiez l'image Docker directement sur votre système de production et exécutez-la.

Comment utiliser Docker Swarm ou Kubernetes pour déployer des microservices Java

Disons que vous décidez d'essayer Docker. Chaque fois que vous déployez un microservice Java, vous créez une image Docker qui regroupe votre fichier .jar. Supposons que vous disposiez de quelques microservices Java et que vous souhaitiez déployer ces services sur plusieurs machines (dans un cluster). La question se pose : comment gérer ce cluster ? Exécuter des conteneurs Docker, vérifier les performances, déployer des mises à jour, faire évoluer le système (brrr) ? Deux réponses possibles à cette question sont Docker Swarm et Kubernetes. Entrer dans les détails des deux options rendrait ce didacticiel déjà long trop long, mais nous pensons qu'il est important de mentionner que les deux options reposent en fin de compte sur l'écriture de fichiers YAML (voir les histoires d'indentation Yaml ) pour gérer votre cluster. Si vous voulez savoir quels sentiments cela suscite dans la pratique, tapez simplement une requête similaire dans la recherche Twitter. Ainsi, le processus de déploiement de vos microservices Java ressemble désormais à ceci :

• Configuration et gestion de Docker Swarm/Kubernetes
• Toutes les étapes pour Docker (voir ci-dessus)
• Écrivez et exécutez YAML jusqu'à ce que vos yeux saignent jusqu'à ce que tout fonctionne.

Comment tester les microservices Java

Disons que vous décidez d'implémenter des microservices en production. Comment pouvons-nous tester l’intégration des n-microservices pendant le développement maintenant ? Comment savoir si l’ensemble du flux de travail fonctionne, et pas seulement certaines parties ? En pratique, vous pouvez utiliser l'une des trois méthodes suivantes :

1. Avec un peu de travail (si vous utilisez des frameworks comme Spring Boot), vous pouvez combiner tous vos microservices en une seule classe de lanceur et charger tous les microservices à l'aide d'une seule classe Wrapper.java - selon que vous disposez ou non de suffisamment de mémoire sur votre machine pour exécutez-les tous vos microservices.
2. Vous pouvez copier les paramètres Docker Swarm ou Kubernetes localement.
3. N'exécutez plus de tests d'intégration localement. Déployez plutôt un environnement DEV/TEST dédié. C’est quelque chose que de nombreuses équipes font lorsqu’elles succombent aux difficultés des configurations de microservices locaux.

De plus, en plus de vos microservices Java, vous aurez probablement également besoin d'un courtier de messages en cours d'exécution (tel qu'ActiveMQ ou RabbitMQ) ou peut-être d'un serveur de messagerie ou de tout autre composant de messagerie dont vos microservices Java ont besoin pour communiquer entre eux. Cela conduit à une sous-estimation significative de la complexité du côté DevOps. Jetez un œil aux bibliothèques de tests de microservices, elles peuvent atténuer cette douleur. Quoi qu'il en soit, cette complexité nous amène aux problèmes généraux des microservices, dont nous parlerons tout de suite. Dans la dernière partie , nous aborderons des questions générales sur les microservices Java.