Les fournisseurs de serveurs d’application ont-ils vraiment compris le déploiement ?

Chez XebiaLabs, nous nous y connaissons en déploiement automatique d’applications Java EE. L’une des choses les plus surprenantes réside dans le fait que «les fournisseurs de serveurs d’application ne semblent pas faire partie des personnes qui maitrisent le mieux le déploiement d’applications».

Dans un article précédent, nous avons décrit ce que nous considérons comme le déploiement d’application J2EE global. Et force est de constater que:

• Déployer va bien au delà d’un simple déploiement d’un EAR ou d’un WAR.
• La plupart des applications ont également besoin d’autres artéfacts comme par exemple du contenu statique pour le serveur web ou encore des fichiers de configuration, utilisés par le code java, au démarrage.
• Il faut également configurer des ressources JEE comme des Datasources JDBC ou des composants JMS (Queues, Topics, Servers).
• A ceci s’ajoute, bien entendu, la configuration du middleware lui-même: création et configuration de clusters de serveurs d’application ou de virtual hosts d’un serveur Apache.
• L’ordre d’exécution des tâches est important afin de réduire (voire de prévenir) la coupure de service de l’application pendant le déploiement et d’en augmenter la vitesse.

Alors posons nous la question. Que nous proposent les fournisseurs de serveurs d’application dans ce domaine ?

Oracle WebLogic Server

Oracle WebLogic Server propose un concept de ‘Deployment’: c’est la chose que vous créez quand vous déployez un EAR, un WAR ou un EJB Jar. Sic ! Vous pouvez l’adapter à l’environnement en fournissant un plan de déploiement. Cependant, rien n’est proposé pour regrouper plusieurs artéfacts JEE dans un seul déploiement ou inclure la création de ressources JEE telle qu’une Datasource.

Dans WebLogic, il y a le concept de ‘SubDeployement’ mais étrangement il n’est pas corrélé à un déploiement. C’est un mécanisme utilisé pour cibler des parties d’un module JMS vers des serveurs JMS ou des serveurs WebLogic. L’artifice proposé par les modules JMS semble destiné seulement à regrouper des ressources JMS. Sans doute qu’un jour un développeur l’a initialement appelé Déploiement sans se souvenir que le concept existait déjà dans WebLogic et il l’a alors renommé SubDeployement. Bien sûr, tout ceci n’est que supputation!

WebLogic propose un grand nombre d’API pour le déploiement: l’historique weblogic.Deployer en ligne de commande, la tâche ANT wldeploy et le WebLogic Scripting Tools, WLST pour les intimes, basé sur Python. Ce dernier est, je pense, le plus complet. Grâce à sa représentation sous forme de système de fichier de la hiérarchie des MBeans, il fournit un moyen très intuitif d’accéder à l’information.

JBoss Application Server

Le déploiement dans JBoss est géré par le Virtual Deployment Framework. C’est un framework basé sur des MBeans qui permet à différents artéfacts (EARs, WARs, EJB JARs, RARs, SARs …) et à différentes ressources (sources de données, paramètres JMS …) d’être déployés sur JBoss. Tout ceci est géré par leurs deployers.

Cependant, la plupart des gens n’invoque pas ces deployers, ni même ‘twiddle‘. Ils préfèrent simplement déposer leurs artéfacts dans le répertoire deploy/ de leur serveur d’application Jboss, puis attendre que le Deployment Scanner le détecte. Ils vérifient ensuite dans le fichier de log que le déploiement est terminé.

Le souci avec cette méthode : le déploiement n’est pas une opération atomique. Quand on automatise un déploiement, on ne veut redémarrer le serveur web qu’après un déploiement réussi du nouveau WAR. Mais écrire un bout de code qui analyse les logs du serveur à la recherche d’un mot clé est tout simplement moche. Une alternative serait de positionner la propriété ScanEnabled du DeploymentScanner à false d’invoquer manuellement le deployer. Non seulement cela complexifie le code, mais il faut également prévoir la copie des fichiers dans le répertoire deploy du serveur JBoss.

Ainsi, il s’avère qu’avec JBoss Application Server, il est difficile d’intégrer des déploiements vers ses serveurs dans un scénario de déploiement plus global. RedHat doit corriger ce problème au plus vite pour que JBoss soit réellement prêt pour les entreprises.

IBM WebSphere Application Server

Et pour le gros monstre JEE de chez ‘Big Blue’ ? Il offre une façon polyvalente et transactionnelle pour déployer des applications et des ressources. Globalement, le langage de script wsadmin permet de contrôler tous les aspects de WebSphere. Par exemple, vous pouvez synchroniser des nœuds explicitement et l’invocation de la méthode (par Jython ou JACL) pour déployer l’application ne rendra la main que lorsque l’opération sera réalisée. Le côté négatif est qu’il est beaucoup plus lent que l’outil similaire WLST proposé par WebLogic (les nombreuses copies de documents XML à travers SOAP doivent y être pour quelque chose) et les API proposées sont plutôt complexes à manipuler (qui peut donner la différences entre un containment path, un configuration id et un object name?)

Bien que WAS ne propose pas de mécanismes pour regrouper les différents artéfacts et ressources liés à un même déploiement, sa nature transactionnelle permet de commiter les différents changements de configuration en une fois. Il peut même gérer la configuration des instances des serveurs IBM HTTP Server ou Apache HTTP Server .

Malgré une vitesse de déploiement lente, rien ne vaut la fiabilité des déploiements de WebSphere !

Conclusion

Les serveurs d’application fournissent chacun un niveau de support différent pour prendre en charge les déploiements des applications d’entreprise. Bien sûr, ils offrent tous le déploiement basique des artéfacts Java EE mais aucun d’entre eux ne propose de regrouper différents artéfacts en un seul déploiement ou de lier des ressources Java EE à ces artéfacts. WebLogic Server est le seul qui essaye de regrouper des ressources (JMS Modules et SubDeployment). Mais ces abstractions ne couvrent qu’une petite partie de toute l’étendue du déploiement Java EE.

La répétition et la prédiction sont très importantes pour une stratégie de déploiement réussie, ce qui peut expliquer la prévisibilité de WebSphere sur le marché. Et finalement, une bonne API est nécessaire pour automatiser votre processus de déploiement: WebLogic et WebSphere l’offrent, JBoss a un sérieux manque dans ce domaine (même avec twiddle !)

Les consultants de Xebia et l’ensemble des développeurs chez XebiaLabs ont quasiment tous écrit dans leurs expériences passées des tonnes de scripts pour automatiser des déploiements et ont dû batailler sur ces questions encore et encore. Nous avons développé Deployit afin de prendre en charge ces différences entre serveurs d’applications et parce que nous croyons que l’automatisation des déploiements est de la plus haute importance du fait du nombre croissant de déploiements dans les entreprises.

—
Traduction libre du billet «Do application server vendors really understand deployment? » publié par Vincent Partington.