Retour Atelier Continuous Delivery – Partie 1 – Déploiement avec Apache Tomcat Maven Plugin

Les 13 et 20 octobre derniers a eu lieu le deuxième Tech Event Xebia avec, cette fois, comme sujet le Déploiement Continu sur Tomcat avec Jenkins, Rundeck et Deployit. Pour l’occasion nous avons eu la collaboration spéciale de deux guest stars :

• Olivier Lamy, architecte chez Talend, membre de la fondation Apache et committer sur Tomcat et sur Jenkins
• Vincent Behar, ingénieur Java à Exalead, owner du plugin Rundeck pour Jenkins et cofondateur de Paris Devops, 

Merci à eux pour leur participation à la préparation de l’atelier ainsi qu’à sa présentation.

Flickr est l’exemple le plus évoqué à l’heure actuelle de déploiement continu. Il existe bien d’autres exemples connus comme Outbrain, Wealthfront ou Etsy. Même si le nombre d’entreprises qui arrivent à ce niveau de maturité est encore faible, il est possible qu’à l’avenir cette méthode devienne une technique courante dans les projets avec la progression de l’agilité. Son implémentation oblige, en effet, à accomplir quelques principes du manifeste agile, dont par exemple :

Ainsi qu’à en pousser d’autres :

Quels sont les points forts du déploiement continu ?

• Etre au plus près des attentes du marché (le fameux Time to market) en fournissant aux utilisateurs les fonctionnalités qu’ils attendent dès qu’elles sont prêtes.
• Minimiser le risque d’échec d’un gros déploiement.
• Avoir un retour rapide des utilisateurs réels de l’application sur les nouvelles fonctionnalités de la version.
• Une livraison fréquente permet aux utilisateurs de s’habituer progressivement aux nouveaux environnements ergonomiques.

En revanche, l’implémentation du déploiement continu ne doit pas être sous-estimée. Sa mise en place oblige à une grande rigueur :

• Automatisation de toutes les phases de build, test et déploiement,
• Configuration centralisée du déploiement et exécution sur chaque environnement,
• Une haute disponibilité de l’infrastructure de production afin d’éviter les coupures de service,
• Une couverture des tests exemplaire. Si les tests unitaires, d’intégration et d’acceptance passent, l’application répond aux besoins et peut en théorie partir en production à tout moment.
• Communication fluide entre l’exploitation, les DBAs et les développeurs. Dans la ligne de ce que le mouvement Devops préconise, on doit éviter les fractures organisationnelles et développer un environnement collaboratif en donnant priorité au bon fonctionnement du système.

Notre atelier

Présentation globale de l’architecture

Revenons sur l’atelier. Le but de la soirée, par binôme, est de mettre la main à la pâte et configurer du déploiement continu. Pour ce faire, nous avons présenté comment déployer sur Tomcat l’application web modèle de Spring petclinic sur des instances Amazon EC2. Les méthodes proposées étaient les suivantes :

• Le plugin Tomcat Maven
• Le plugin SSH pour Jenkins
• Rundeck et le plugin Rundeck pour Jenkins
• Deployit, de XebiaLabs

Afin de tester les différents outils, voici l’architecture utilisée:

• Une instance Amazon avec un Nexus pour gérer les artifacts de tous les assistants.
• Un repository xebia-petclinic-X sur GitHub pour chaque équipe/binôme (où chaque équipe avait un numéro X associé)
• Une instance Amazon EC2 avec un Jenkins, un Rundeck et un Deployit par équipe
• Trois instances Amazon EC2 dont deux avaient un Tomcat qu’on a appellé “valid” (ou de production) et le troisième un Tomcat de “dev” (ou d’intégration/qualité)

Cette infrastructure est générée à chaud au début de chaque atelier avec un script écrit en java. Pour vous faire une idée, le nombre de nœuds créés pour chaque atelier a été autour des 45 (20 participants regroupés en binômes). Le démarrage des instances Amazon Linux a été fait avec le package d’AWS SDK pour Java. Pour l’initialisation et configuration de Nexus, Jenkins, Rundeck et Tomcat, nous avons utilisé le package d’Ubuntu Cloud-init. Puisque le serveur Nexus est partagé par tous les utilisateurs de l’atelier, une adresse Elastic-IP d’Amazon lui est assignée à son démarrage. La création automatique de chaque repository github par binôme a été faite avec l’API V2 de GitHub. Pour ceux intéressés à avoir plus des détails sur la création et l’initialisation des instances Amazon pour ce workshop, sachez que dans les prochains jours nous publierons à ce propos un nouveau billet.

Présentation de Apache Tomcat Maven Plugin

La première méthode de déploiement proposée utilise le plugin Apache Tomcat Maven. Olivier Lamy nous a fait une présentation des fonctionnalités de ce plugin qui facilite les opérations sur les wars quand on déploie sur Tomcat. Voici quelques-uns des goals disponibles :

• tomcat:run permet de déployer un war sur un tomcat embarqué. Le plugin délègue à maven le téléchargement automatique des jars pour pouvoir l’exécuter. Cela permet le rechargement à chaud des jsp, css, html …
• tomcat:deploy déploie un war dans un tomcat démarré.

Ainsi que les nouvelles fonctionnalités à venir :

• Support pour tomcat 7
• Un nouveau goal qui permettra de créer un jar standalone pour pouvoir exécuter le war sur tomcat. Le jar inclura la webapp aussi que tous les jars de tomcat nécessaires.
  Par exemple : mvn tomcat7:exec-war génère un jar my-project-exec-war.jar
  jar -jar my-project-exec-war.jar lance le tomcat avec la webapp avec une configuration par défaut. Il est aussi configurable en renseignant des paramètres (-httpPort -ajpPort…)

Durant le workshop, nous avons utilisé le goal « tomcat : deploy » afin de déployer l’application exemple en local, puis sur l’instance Amazon avec le Tomcat de Dev. Pour cela, il suffit de rajouter le plugin tomcat maven au pom.xml du projet comme ci-dessous :

<plugin>
     <groupId>org.apache.tomcat.maven</groupId>
     <artifactId>tomcat6-maven-plugin</artifactId>
     <version>2.0-SNAPSHOT</version>
     <configuration>
          <update>true</update>
     </configuration>
</plugin>

A noter qu’il faut aussi avoir installé Tomcat Manager sur l’instance Tomcat cible puisque le goal utilise le Tomcat Manager de l’instance et un upload HTTP pour déployer le war sur le serveur dont l’url sera spécifiée dans le paramètre -Dmaven.tomcat.url. Le login et le password pour Tomcat Manager devront aussi être passés dans la commande :

mvn tomcat6:deploy -Dtomcat.password=admin -Dtomcat.username=admin -Dmaven.tomcat.url=http://ecX-XX-XX-XXX.eu-west-1.compute.amazonaws.com:8080/manager

Ce goal peut aussi être rattaché à la phase de deploy d’un profil en particulier (dans l’exemple ci-dessous, tdeploy) :

mvn deploy -Ptdeploy

Si vous souhaitez refaire la manipulation chez vous, il vous suffit de cloner le projet, depuis https://github.com/xebia-france-training/xebia-petclinic-lite.

Puis exécuter le goal précédemment donné pour effectuer la manipulation.

Conclusions

Suite à l’exercice de déploiement avec le plugin, nous pouvons faire les conclusions suivantes:

Déploiement avec Tomcat Maven Plugin

Simple à mettre en place Simple à utiliser	Tomcat Manager est déconseillé en production Tomcat Manager ne redémarre pas la JVM : risque de fuite de mémoire Mode léger pour la production (login/password) Il n’est pas très adapté au cluster : impossibilité de déployer sur plusieurs instances en parallèle

Si on compare le déploiement via ce plugin avec les méthodes que nous présenterons dans nos prochains billets (le plugin SSH pour Jenkins, Rundeck ou Deployit), vous verrez qu’il s’éloigne quelque peu des méthodes habituelles d’installation d’un livrable en production. Une mise en production se résume rarement à simplement déployer un war sur un seul serveur Tomcat via HTTP. En effet, l’application pourrait être clusterisée, il pourrait y avoir besoin de copier des fichiers de configuration supplémentaires, ou encore de passer des scripts SQL. Comme vous le verrez après, les autres alternatives se basent sur un script shell qui laisse la porte ouverte à d’autres opérations.

Dans nos prochains billets, nous vous présenterons le déploiement via le plugin SSH pour Jenkins, Rundeck ainsi qu’un dernier article dédié à la création automatique de l’infrastructure utilisée dans ce workshop.