Déploiement en parallèle avec Tomcat

Le déploiement parallèle de Tomcat permet de faire cohabiter plusieurs versions d’une mếme application.

La fonctionnalité est apparue avec Tomcat 7. On peut la visualiser dans le Web Application Manager, avec une colonne Version dans la liste des applications, et un champ Version (for parallel deployment) dans la zone de déploiement de fichier WAR.

Déploiement avec le manager

Le déploiement parallèle n’est proposé que pour le déploiement d’un répertoire ou fichier WAR déjà présent sur le serveur.

Déploiement avec le Tomcat Web Application Manager

Il y a un champ facultatif pour la version. Après le déploiement, cette version apparraît dans la liste des applications.

Liste des applications avec la version

Le déploiement parallèle peut aussi être fait en ligne de commande.

~$ curl -T msg.war "http://alexis:hassler@localhost:8080/manager/text/deploy?path=/msg&update=true&version=0.5"
OK - Deployed application at context path [/msg##0.5]

~$ curl "http://alexis:hassler@localhost:8080/manager/text/list"
OK - Listed applications for virtual host [localhost]
/:running:0:ROOT
/msg:running:0:msg##0.5
/msg:running:0:msg##0.2
/manager:running:0:manager

Déploiement sans le manager

L’ajout d’une version à l’application se fait par le nom du répertoire et/ou du fichier WAR dans le répertoire webapps. Ça se fait en suffixant le nom du fichier avec ##<version>.

apache-tomcat
  ↳ bin
  ↳ conf
  ↳ lib
  ↳ logs
  ↳ temp
  ↳ webapps
    ↳ manager
    ↳ msg##0.1.war
    ↳ msg##0.2.war
    ↳ msg##0.3.war
    ↳ ROOT
  ↳ work

Gestion des requêtes

Lorsque plusieurs versions de la même application sont déployées, elles ont le même contexte.

Tomcat choisit sur quelle version orienter chaque requête selon une logique d’affinité de session. Si une des versions a une session pour le JSESSIONID, alors la requête y est envoyée. Sinon c’est la dernière version est privilégiée.

L’ordre des versions n’est pas documenté mais il n’a rien à voir avec la date du déploiement ou du build. Il semble être simplement alphabétique (testé avec Tomcat 10.1).

Quelques exemples:

  • 2.0 > 1.1 > 1.0

  • 1.2 > 1.1 > 1.12 > 1.0

  • c > b > a

Retrait automatique

Garder une ancienne version peut être utile pour plusieurs raisons:

  • conserver la possibilité d’annuler le déploiement d’une version plus récente et revenir à cette version ancienne,

  • continuer de servir des sessions en cours.

Evidemment, c’est la seconde motivation qui est la plus importante. Et quand toutes les sessions de la version ancienne ont été invalidées, celle-ci peut être retirée.

Tomcat est capable de faire automatiquement cette action, à condition que l’option undeployOldVersions soit activée sur le host.

<Host name="localhost"  appBase="webapps"
      unpackWARs="true" autoDeploy="true"
      undeployOldVersions="true">

Problèmes classiques

Si l’application veut enregistrer des composants JMX, il y a un risque de conflit entre les versions.

En effet, le serveur JMX est au niveau de la JVM et donc commun à toutes les applications et à leurs versions. Si l’application veut enregistrer un MBean, elle doit choisir un nom qui n’entre pas en conflit avec les autres MBeans. C’est rarement fait et loin d’être évident de le faire avec plusieurs instances de la même application.

Références