Déploiement automatisé (Tomcat et cargo-maven2-plugin)

Dans un contexte d'intégration continue il est fréquent de déployer régulièrement l'application sur un serveur d'application.
Pour automatiser ce processus on peut utiliser le plugin Maven 2 cargo-maven2-plugin pour déployer l'application sur Tomcat à l'aide de la configuration suivante:

<!-- DEPENDENCY CONFIG -->
<dependencies>
   <dependency>
     <groupId>${webapp.groupId}</groupId>
     <artifactId>${webapp.artifactId}</artifactId>
     <version>${webapp.version}</version>
     <type>${webapp.type}</type>
   </dependency>
</dependencies>

<profiles>
    <!-- WEB APP TO DEPLOY-->
    <profile>
      <id>MyApp</id>
      <properties>
        <webapp.groupId>sweetdev-ria</webapp.groupId>
        <webapp.artifactId>sweetdev-ria-gettingStarted</webapp.artifactId>
        <webapp.type>war</webapp.type>
        <webapp.version>3.5.1</webapp.version>
       </properties>
    </profile>

   <!-- REMOTE SERVER CONFIG-->
   <profile>
      <id>local</id>
      <properties>
         <tomcat.url>http://localhost:8080/manager</tomcat.url>
         <tomcat.login>tomcat</tomcat.login>
         <tomcat.password>tomcat</tomcat.password>
         <tomcat.ping>http://localhost:8080/</tomcat.ping>
      </properties>
   </profile>

   <!-- TOMCAT SERVER CONFIG-->
   <profile>
      <id>tomcat</id>
      <build>
        <plugins>
          <plugin>
             <groupId>org.codehaus.cargo</groupId>
             <artifactId>cargo-maven2-plugin</artifactId>
             <version>0.3.1</version>

             <executions>
               <execution>
                  <id>deploy-app</id>
                  <phase>install</phase>
                  <goals>
                    <goal>deployer-redeploy</goal>
                  </goals>
               </execution>
             </executions>

             <configuration>
               <container>
                 <containerId>tomcat5x</containerId>
                 <type>remote</type>
               </container>

              <configuration>
                <type>runtime</type>
                <properties>
                  <cargo.remote.username>${tomcat.login}</cargo.remote.username>
                  <cargo.remote.password>${tomcat.password}</cargo.remote.password>
                  <cargo.tomcat.manager.url>${tomcat.url}</cargo.tomcat.manager.url>
                </properties>
              </configuration>

              <deployer>
                <type>remote</type>
                <deployables>
                   <deployable>
                      <groupId>${webapp.groupId}</groupId>
                      <artifactId>${webapp.artifactId}</artifactId>
                      <type>${webapp.type}</type>
                      <pingURL>${tomcat.ping}${webapp.artifactId}-${webapp.version}</pingURL>
                      <pingTimeout>60000</pingTimeout>
                   </deployable>
                </deployables>
              </deployer>

            </configuration>
         </plugin>
      </plugins>
    </build>
  </profile>
</profiles>

Cette configuration est composée des 4 parties suivantes:

  • DEPENDENCY CONFIG : Le plugin cargo-maven2-plugin demande à ce que l'artefact déployé soit défini en temps que dépendance du projet.
  • WEB APP TO DEPLOY : Ce profil permet de définir les variables associés à l'artefact déployé.
  • REMOTE SERVER CONFIG : Ce profil permet de définir les variables associés au serveur cible.
  • TOMCAT SERVER CONFIG : Ce profil permet de définir la configuration du plugin pour déployer l'application sur Tomcat.

L'intérêt de définir plusieurs profils dans lesquels on sépare les responsabilités permet de pouvoir configurer dans un même fichier le déploiement de plusieurs applications sur plusieurs serveurs, seule la ligne de commande change.
Pour exécuter le déploiement de l'application MyApp sur Tomcat il suffit d'exécuter la commande  :

mvn install -PMyApp,local,tomcat

Dans certains cas on peut s'apercevoir que cette commande fonctionne bien la première fois mais pas la seconde!;)
Si on ouvre dans le répertoire webapp de Tomcat, on peut s'apercevoir que la structure de l'application est présente, quasi vide à l'exception d'une ou plusieurs librairies (WEB-INF/lib) et que l'on ne peut pas les supprimer manuellement.
La raison est que le serveur Tomcat garde une référence vers certaines classes ou ressources contenues dans les librairies et ne la supprime pas lorsque l'application est désinstallée.
Les références entre le serveur et les classes applicatives peuvent être induites pour plusieurs raisons : définition des paramètres de commons-logging dans la webapp, le ClassLoader applicatif qui référence de manière bidirectionnelle des librairies serveur et applicatives..etc.

La solution la plus simple pour éviter ce type de problème est de préciser à Tomcat via les paramètres antiJARLocking et antiResourceLocking du context.xml de ne pas garder de référence vers l'applicatif.
Ces paramètres du contexte applicatif peuvent être définis principalement à deux endroits:

Solution 1
Dans le context.xml applicatif qui peut être présent directement dans le WAR de l'application dans le repertoire META-INF:

<Context path="/myApp" docBase="myApp" debug="0"
reloadable="true" antiJARLocking="true" antiResourceLocking="true"/>

Solution 2
Dans le contexte globale à l'ensemble des application définit dans le fichier ${CATALINA_HOME}/conf/context.xml:

<Context  debug="0" reloadable="true" antiJARLocking="true" antiResourceLocking="true">
<!-- Default set of monitored resources -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
</Context>

Dans les deux cas les paramètres antiJARLocking et antiResourceLocking permettent de désinstaller l'application proprement via le plugin cargo-maven2-plugin.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.