Paris JUG de mai : Build, Share & Deploy jusqu’au bout de la nuit (5)
![]() |
Pendant la mise en place des speakers de Deployit, le tirage au sort pour l’invitation de developpez.com à Jazoon par Ellène Dijoux. 5 personnes ont été sélectionnées. Le résultat définitif sera sur la liste Users du JUG.
Vous avez partagés vos fichiers, réalisé les livrables. Il reste maintenant une opération assez pénible : déployer sur les plates-formes où seront les utilisateurs, que ce soit en recette ou en production.
DeployIt : automatiser les déploiement d’application Java
Guillaume Bodet et Benoit Moussaud nous ont présenté Deployit de l’éditeur XebiaLabs. Une présentation plus calme mais toujours très professionnelle.
Ce progiciel commercial est le fruit d’une coopération KLM Air France et capitalise sur des années d’expérience du déploiement d’application Java sur tout types d’environnements.
Dans beaucoup de cas, il ne suffit pas de pousser un ear. Il faut transférer un ensemble de composants applicatifs pour que l’application fonctionne dans son environnement : des configuration de ressource JDBC, des providers de sécurité, des fichiers de configuration, des ressources statiques, des mises à jour pour les CDN (Content Delivery Network). La situation peut s’avérer véritablement complexe sur des plates-formes de production avec des clusters et des fermes de plusieurs machines.
Le produit est bâti sur moteur dans lequel on va déclarer toutes les opérations. Le produit est écrit en Java et déployé sous la forme d’une Web Application. L’IHM est réalisée en Flex, mais il existe aussi des modes de pilotage par ligne de commande et une intégration Maven et Eclipse.
Le moteur embarque des plugins, basés sur une API publique. Les opérations sur les middleware JEE sont fournis de base. Les plugins permettent d’intégrer des composants plus exotiques. Les plugins sont écrits en Java ou en Jython.
Cette API plugin fait partie du modèle économique. Le but est de construire une AppStore pour ces plugins et de permettre un partage de revenus pour les fournisseurs de plugins.
Les composants techniques
Le Configuration Item Repository (ou CIR) est une base de données qui référence toutes les informations sur les environnements. C’est un CMDB dans une organisation ITIL.
Les Runbooks encapsulent primitives sur les middlewares ou les composants techniques cibles.
Au milieu se trouve le Moteur de Résolution. Il scanne l’application, consulte les environnement et calcule un scenario a partir des runbooks. Le moteur les assemble dans un scénario plus complexe.
Le processus
1er concept – l’application : Le truc qu’on veut déployer, c’est à dire une application livrée, un ear, un war et tout le bazar
2ème concept – l’environnement : c’est un ensemble de middlewares, serveurs d’applications, serveurs web … plus ou moins compliqué
3ème concept – le déploiement : il associe les 2 via le moteur de résolution qui calcule ce qu’il faut faire
Autres caractéristiques techniques
Deployit est agentless.
Les opérations se font à distance sans déploiement d’agents sur les cibles en utilisant des protocoles standards (ssh, scp, jmx, jdbc, etc) ou les outils de management intégrés des serveurs d’applications (Twiddle pour JBoss, wsadmin pour WebSphere Application Server, wstl pour Weblogic). Il requiert ssh sur la machine distante. C’est standard sous UNIX/Linux mais peut poser problème sous Windows. Toutefois sous Windows Deployit peut fonctionner sur smb (Samba) et telnet, mais dans des conditions de sécurité dégradées car ces protocoles sont peu sûrs.
Il trace toutes les opérations effectuées.
Il est extensible et customisable via les plugins pour s’adapter aux processus des entreprises car chacune à des processus légèrement différent des autres.
La démo
Benoit Moussaud a décidé de nous faire une démo de l’intégration Maven et non pas de l’IHM.
Le but est de réaliser les étapes suivantes dans un serveur d’intégration continue Hudson : builder une application (le bien connu Pet Clinic), la déployer avec sa DataSource sur deux plates-formes, réaliser un test fonctionnel avec Selenium, un test de performance avec JMeter et reporter le résultat dans Hudson. A la fin des tests les cibles sont nettoyées. Benoit nous montre qu’en définissant le plan de déploiement il est possible de déployer son application assez facilement grâce à des profils défini dans deployit.
Le plugin ajoute Deployit deploy dans la phase intégration test de Maven.
Les étapes à suivre sont décrites dans le plan de déploiement par du XML. Par exemple pour la plate-forme de test fonctionnel avec Selenium : 1 war tomcat 1 machine Associe des ressources middleware type JDBC
Les runbooks indiquent au moteur de résolution que pour déployer le war et faire le test il doit : arrêter Tomcat / attendre / déployer le war / démarrer / Executer Selenium / désinstaller le war et éventuellement retirer la ressource JDBC si elle n’est utilisée par personne / arrêter Tomcat
La deuxième démo est plus compliquée puisqu’il y a un server web Apache et une base MySql en plus, mais c’est le même principe.
Un produit a considérer si vous avez des déploiements réguliers et complexes plutôt que de bidouiller des scripts.
Questions
Et si on veut pas payer ?
Le socle est payant en version complète mais il existe une version Community téléchargeable gratuitement qui n’a pas le support de la sécurité et n’est donc pas utilisable en production. Cette version permet d’évaluer le produit sur des plates-formes moins sensibles et de mettre au point les plugins. Il est très simple à installer pour test.
XebiaLabs étudie la possibilité de passer le noyau Deployit en Open Source Software.
Une question a été posée sur l’atomicité du déploiement. Les ressources ne sont pas transactionnelles. Donc en cas de problème, Deployit revient en arrière en réinstallant la version précédente. Ce qui implique qu’il ne faut jamais faire d’incrémental. On livre tout et le moteur de résolution sautera les étapes inutiles.
Le gros souci est la base. Les scripts de retour en arrière sur les bases de données marchent souvent mal. La recommandation de Guillaume Bodet est d’intégrer dans le processus une image avant de la base de données pour pouvoir restaurer en cas de problème.
La 3ième mi-temps
22h, Fin d’une soirée bien remplie. On range les chaises, on plie le matériel. Il ne nous reste plus qu’à partir en 3ième mi-temps.
Cette fois ci pas de wave. Vous trouverez d’autres comptes rendus là
Précédent : la présentation Maven 3 |
Les photos sont de José Paumard et Claude Falguière.