Comment les spécificités du travail avec les serveurs d'applications changent à l'aide de l'exemple OpenLiberty

Bonjour, Habr!

Le discours de Sebastian Dashner lors d'une rencontre Java au bureau d'IBM à Moscou (a trouvé un record d'une performance similaire) m'a incité à commencer ma connaissance des serveurs d'applications légers, en particulier, avec OpenLiberty. Et puis j'ai pensé:

1. Quels sont les avantages d'un serveur d'applications léger?
2. Comment la spécificité du travail change-t-elle lors de leur utilisation?
3. Pourquoi emballer un serveur d'applications dans un conteneur?

En répondant à ces questions, j'ai remarqué qu'il y avait peu d'informations publiques sur ce sujet, j'ai donc décidé de les collecter et de les systématiser ici.

Je poste les résultats sous la coupe.

Quels sont les avantages d'un serveur d'applications léger?

Auparavant, les serveurs d'applications Java EE d'entreprise (tels que JBoss AS, Oracle WebLogic, IBM WebSphere AS) étaient considérés comme une conception lourde et encombrante, en particulier en ce qui concerne les temps de démarrage et de déploiement. Mais la technologie cloud capture une part de plus en plus importante de l'industrie et les exigences des serveurs d'applications évoluent.

Et maintenant, au lieu de serveurs d'applications d'entreprise complets, viennent des serveurs d'applications rapides, modulaires et petits, concentrés sur une tâche spécifique: Thorntail , Payara Micro - les jeunes frères WildFly et Payara; Meecrowave est un serveur léger JAX-RS + CDI + JSON, KumuluzEE est un serveur qui vous permet d'étendre Java EE en utilisant Node.js, Go et autres.

Cette liste comprend également OpenLiberty - un serveur d'applications open source (distribué selon EPL-1.0) qui prend en charge les dernières normes Java EE / Microprofile, sur lesquelles WebSphere Liberty fonctionne.


Voyons quels avantages nous pouvons obtenir en déployant l'application dans un conteneur avec OpenLiberty. (Vous devez avoir installé n'importe quelle version de java, des étapes supplémentaires doivent être effectuées dans le répertoire wlp)

Vitesse:

La vitesse est l'indicateur le plus important pour une application cloud, car pour qu'une application cloud puisse évoluer rapidement, gérer et faire face à la charge croissante, elle doit être lancée en quelques secondes. Un serveur d'applications léger peut le faire. Pour vérifier, téléchargez le serveur OpenLiberty et exécutez bin / server run ( liste complète des commandes ):

$ bin/server run  defaultServer (Open Liberty 19.0.0.6/wlp-1.0.29.cl190620190617-1530)  Java HotSpot(TM) 64-Bit Server VM  1.8.0_212-b10 (ru_US) [AUDIT ] CWWKE0001I:  defaultServer . [AUDIT ] CWWKZ0058I:   dropins  . [AUDIT ] CWWKF0012I:     : [el-3.0, jsp-2.3, servlet-3.1]. [AUDIT ] CWWKF0011I:  defaultServer      .  defaultServer   1,709 . 

Modularité et flexibilité

La plupart des applications n'ont pas besoin de Java EE dans son ensemble, mais nécessitent un ensemble dédié de normes, le plus souvent utilisé dans les applications d'entreprise. Grâce à OSGI, nous pouvons choisir l'ensemble de normes Java EE et / ou MicroProfile dont nous avons besoin, en ignorant tout le reste.

Par exemple, déclarez JAX-RS depuis Java EE et mpHealth depuis Microprofile en ajoutant quelques lignes au bloc featureManager usr / servers / serverName /server.xml

 <?xml version="1.0" encoding="UTF-8"?> <server description="new server"> <!-- Enable features --> <featureManager> <feature>jsp-2.3</feature> <feature>mpHealth-1.0</feature> <feature>jaxrs-2.1</feature> </featureManager> <!-- To access this server from a remote client add a host attribute to the following element, eg host="*" --> <httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443" /> <!-- Automatically expand WAR files and EAR files --> <applicationManager autoExpand="true"/> </server> 

Mise à jour dynamique

Pendant le développement, le code du programme et la configuration changent constamment.
Le serveur d'applications est configuré pour surveiller les modifications et, si nécessaire, reconfigure et déploie l'application à la volée. Par exemple, une réaction aux changements récents:

 [AUDIT ] CWWKG0016I:    . [AUDIT ] CWWKG0017I:      0,475 . [AUDIT ] CWWKF0012I:     : [cdi-2.0, jaxrs-2.1, jaxrsClient-2.1, jndi-1.0, json-1.0, jsonp-1.1, mpHealth-1.0, servlet-4.0]. [AUDIT ] CWWKF0013I:     : [servlet-3.1]. [AUDIT ] CWWKF0008I:     0,476 . 

Taille et assemblage de l'image

La taille des serveurs d'applications a considérablement diminué et vous permet désormais de déployer
chaque application sur un serveur d'applications distinct pour les emballer dans des conteneurs, ce qui donne la plus grande flexibilité. De plus, puisque l'image est constituée de couches, lors du réassemblage et de la distribution d'artefacts, seule la couche d'application est copiée, le système d'exploitation, le runtime et le serveur d'applications sont mis en cache.

Dockerhub a des images prédéfinies contenant un serveur OpenLiberty préconfiguré. Nous allons utiliser l'un d'eux et créer un Dockerfile:

 FROM open-liberty COPY usr/servers/defaultServer /opt/ol/wlp/usr/servers/defaultServer ENTRYPOINT ["/opt/ol/wlp/bin/server", "run"] CMD ["defaultServer"] 

Assemblons l'image:

 docker build -t app . 

Exécutez-le comme un conteneur:

 docker run -d --name app -p 9080:9080 app 

Vérifiez le résultat http: // localhost: 9080 / health /



Pour arrêter le conteneur:

 docker stop app 

Il existe de nombreux autres scénarios d'utilisation du conteneur, et en général, c'est une occasion pour des articles individuels, alors revenons aux questions.

Comment évolue la spécificité du travail?

Paquet de paquet

L'image du conteneur ne doit être collectée qu'une seule fois, puis exécutée dans tous les environnements. Par conséquent, il est recommandé de collecter chaque application avec le serveur d'applications. Cela simplifie le cycle de vie et le déploiement des applications et s'intègre parfaitement dans le monde moderne de la technologie des conteneurs.

Assemblage

Désormais, il n'est plus nécessaire de regrouper différents blocs techniques dans des archives distinctes. Toute la logique métier, ainsi que les services Web et les fonctionnalités de bout en bout, sont regroupés dans un seul fichier de guerre. Cela simplifie considérablement l'installation du projet, ainsi que la procédure d'assemblage. Vous n'avez plus besoin de regrouper l'application dans plusieurs niveaux de hiérarchie, puis de la décompresser à nouveau dans une instance de serveur.

Lancement

Le serveur d'applications et l'application elle-même sont ajoutés à l'image pendant le processus de génération. La configuration potentielle des sources de données, des lecteurs ou des modules de serveur est également spécifiée pendant le processus de construction en ajoutant des fichiers de configuration spécialisés. Toutes les différences de configuration doivent être gérées non pas de l'intérieur de l'application, mais de l'extérieur. Par conséquent, l'application ne doit pas être déployée dans un conteneur déjà en cours d'exécution, mais doit y être ajoutée au stade de l'assemblage d'images dans le répertoire de déploiement automatique afin de la lancer au démarrage du conteneur.

Extension de fonctionnalité

Les conteneurs, les systèmes de déploiement et de mise à l'échelle, les services de surveillance et les grilles de services nous ont permis de configurer la détection, la surveillance, la gestion, l'authentification, la mise à l'échelle, le traçage, la stabilité au-dessus de l'application, transférant de manière transparente une grande quantité de logique à un autre niveau, facilitant l'application et simplifiant son développement.

Pourquoi emballer un serveur d'applications dans un conteneur?

Tout d'abord, en emballant un serveur d'applications dans un conteneur, vous donnez à chaque équipe la possibilité de configurer indépendamment son serveur d'applications et de se concentrer sur la mise en œuvre des fonctions, ce qui fait gagner du temps aux développeurs sur les opérations manuelles, les middlewares et diverses approbations.

En prime, vous avez la possibilité de profiter pleinement des avantages des conteneurs et de tous les outils construits autour d'eux. L'application est facile à gérer et à mettre à l'échelle, à mettre à jour et à automatiser l'assemblage et le déploiement des artefacts avec aucun temps d'arrêt.