Conseils de déploiement de fichiers de guerre par rapport à un pot exécutable avec un conteneur intégré
Il semble y avoir une tendance actuelle dans l'espace Java pour s'éloigner du déploiement d'applications Java Web vers un conteneur de servlets Java Java (ou serveur d'applications) sous la forme d'un fichier war (ou fichier ear) et empaquetez plutôt l'application sous la forme d'un fichier exécutable avec un servlet intégré/serveur HTTP comme jetty. Et je le dis plus encore dans la façon dont les nouveaux frameworks influencent la façon dont de nouvelles applications sont développées et déployées plutôt que la façon dont les applications sont livrées aux utilisateurs finaux (car, par exemple, je comprends pourquoi Jenkins utilise un conteneur intégré, très facile à saisir et à utiliser). Exemples de cadres adoptant l'option jar exécutable: Dropwizard , Spring Boot , et Play (enfin, il ne fonctionne pas sur un conteneur de servlet mais le serveur HTTP est intégré).
Ma question est, venant d'un environnement où nous avons déployé nos applications (jusqu'à présent principalement Struts2) sur un seul serveur d'applications Tomcat, quelles modifications, meilleures pratiques ou considérations doivent être apportées si nous prévoyons d'utiliser une approche de conteneur intégré ? Actuellement, nous avons environ 10 applications locales exécutées sur un seul serveur Tomcat et pour ces petites applications, la possibilité de partager des ressources et d'être gérées sur un serveur est agréable. Nos applications ne sont pas destinées à être distribuées aux utilisateurs finaux pour s'exécuter dans leur environnement. Cependant, si nous décidons de tirer parti d'un nouveau cadre Java framework, cette approche devrait-elle changer? Le passage aux fichiers exécutables est-il stimulé par l'utilisation croissante des déploiements cloud (par exemple, Heroku)?
Si vous avez de l'expérience dans la gestion de plusieurs applications dans le style de déploiement Play par rapport au déploiement de fichiers de guerre traditionnel sur un seul serveur d'applications, veuillez partager vos idées.
Une question intéressante. C'est juste mon point de vue sur le sujet, alors prenez tout avec un grain de sel. J'ai occasionnellement déployé et géré des applications en utilisant à la fois des conteneurs de servlets et des serveurs intégrés. Je suis sûr qu'il existe encore de nombreuses bonnes raisons d'utiliser des conteneurs de servlets, mais je vais essayer de me concentrer sur les raisons pour lesquelles ils sont moins populaires aujourd'hui.
Version courte: les conteneurs de servlets sont parfaits pour gérer plusieurs applications sur un seul hôte, mais ne semblent pas très utiles pour gérer une seule application. Avec les environnements cloud, une seule application par machine virtuelle semble préférable et plus courante. Les frameworks modernes veulent être compatibles avec le cloud, d'où le passage aux serveurs embarqués.
Je pense donc que les services cloud sont la principale raison de l'abandon des conteneurs de servlets. Tout comme les conteneurs de servlets vous permettent de gérer les applications, les services cloud vous permettent de gérer les machines virtuelles, les instances, le stockage de données et bien plus encore. Cela semble plus compliqué, mais avec les environnements cloud, il y a eu un passage aux machines à application unique. Cela signifie que vous pouvez souvent traiter la machine entière comme si c'était l'application the. Chaque application s'exécute sur une machine de taille appropriée. Les instances cloud peuvent apparaître et disparaître à tout moment, ce qui est idéal pour la mise à l'échelle. Si une application a besoin de plus de ressources, vous créez plus d'instances.
Les serveurs dédiés, en revanche, sont généralement puissants mais de taille fixe, vous exécutez donc plusieurs applications sur une seule machine pour maximiser l'utilisation des ressources. Gérer des dizaines d'applications - chacune avec ses propres configurations, serveurs Web, routes et connexions, etc. - n'est pas amusant, donc l'utilisation d'un conteneur de servlet vous aide à garder tout ce qui est gérable et sain d'esprit. Il est cependant plus difficile à mettre à l'échelle. Les conteneurs de servlets dans le cloud ne semblent pas très utiles. Ils devraient être configurés pour chaque petite instance, sans fournir beaucoup de valeur car ils ne gèrent qu'une seule application.
De plus, les nuages sont cool et les choses non-cloud sont ennuyeuses (si l'on en croit encore le battage médiatique). De nombreux frameworks essaient d'être évolutifs par défaut, de sorte qu'ils peuvent facilement être déployés sur les clouds. Les serveurs intégrés sont rapides à déployer et à exécuter, ils semblent donc être une solution raisonnable. Les conteneurs de servlets sont généralement toujours pris en charge mais nécessitent une configuration plus compliquée.
Quelques autres points:
- Le serveur intégré pourrait être optimisé pour le framework ou mieux intégré aux outils des frameworks (comme la console de jeu par exemple).
- Tous les environnements cloud ne sont pas fournis avec des images de machine personnalisables. Au lieu d'écrire des scripts d'initialisation pour télécharger et configurer des conteneurs de servlets, l'utilisation d'un logiciel dédié pour les déploiements d'applications cloud est beaucoup plus simple.
- Je n'ai pas encore trouvé de configuration Tomcat qui ne vous salue pas avec erreur d'espace perm gen tous les redéploiements de votre application. Prendre un peu plus de temps pour (re) démarrer les serveurs intégrés ne pose aucun problème lorsque vous pouvez basculer presque instantanément entre les instances de production et de production sans aucun temps d'arrêt.
- Comme déjà mentionné dans la question, il est très pratique pour l'utilisateur final de simplement exécuter l'application.
- Les serveurs intégrés sont portables et pratiques pour le développement. Aujourd'hui, tout est rapide, les prototypes et MVP doivent être créés et livrés le plus rapidement possible. Personne ne veut passer trop de temps à mettre en place un environnement pour chaque développeur.