Zero Downtime déploiement sur Tomcat7

Image

Une fonctionnalité sympa du serveur d’application / conteneur léger JEE Tomcat7 permet de migrer une application donnée de versions sans interruption de service du point de vue utilisateur.

Pourquoi est-ce si génial?

Chacun a sa petite méthode de migration (pas si top, ni si simple) d’une application Java en production. En voici quelques unes :

  • comme une brute je désactive l’application version 1, la supprime (undeploy), déploie la version 2: j’attends que les utilisateurs gueulent🙂
  • moins brutal, je préviens les utilisateurs du créneau de migration et je fais tout pareil qu’en haut🙂
  • je déploie la version 2 sur un autre serveur d’application et je fais une redirection DNS: tous les utilisateurs ne migreront pas en même temps du fait du temps de propagation sur les serveurs DNS + pertes des sessions HTTP des utilisateurs (à moins d’avoir architecturer l’application pour un fonctionnement en cluster)
  • idem que précédemment mais au lieu du DNS je fais un redirection WEB: pertes de sessions HTTP des utilisateurs
  • idem que précédemment avec un loadbalancer en front du serveur en version 1, faire le switch vers le 2 (pareil en fait que la méthode précédente avec la même conséquence si le loadbalancer ne gère pas les sessions en amont)

 

Sinon on peut faire MIEUX et PLUS SIMPLE

  • Lors de la première mise en production: adopter une nomenclature orientée parallel deploment de Tomcat en renommant son war: myApplication.war en myApplication#001.war
  • Vérifier que le serveur Tomcat a bien la fonctionnalité d’auto déploiement d’activé à priori PAR DEFAUT
#/etc/tomcat7/server.xml file
<Host name="localhost"  appBase="webapps" unpackWARs="true" autoDeploy="true">
  • Déployer la première version en production
    cp myApplication#001.war /var/lib/tomcat7/webapps
  • Lors de la migration, déployer la version 2 en parallèle
cp myApplication#002.war /var/lib/tomcat7/webapps
  • Supprimer la version 1
rm /var/lib/tomcat7/webapps/myApplication#001.war

Cela suppose (hélas) de partir déjà sur de bonnes bases en termes de nommage de la première version pour que par la suite Tomcat face le lien et assure le routage des requêtes pendant les migrations de versions.

Sinon pas trop grave, vous pouvez à un moment propice redéployer la même version à partant d’une bonne base, ça ne sera pas sans interruption de service mais au moins il aura l’avantage de:

  • supprimer le risque de régression… car il s’agira d’une copie parfaite de l’actuel war en production
  • avoir du zero downtime pour les prochaines fois de facto

 

Quelques précautions par contre à prendre du fait du déploiement parallèle de plusieurs versions d’un même projet

  • une politique de cache qui expire rapidement
  • ne pas gérer vous même vos sessions au sein de votre application (soit laisser tomcat le faire, ou faire ça à la manière partagée d’un cluster)
  • faire attention aux fichiers de logs: la raison est évidente (logs mélangés des 2 versions, fichiers lockés…)
  • faire attention si votre application utilise des éléments du système de fichiers
  • ne pas avoir de listener de socket TCP sinon il y’ aura 2 écouteurs, ce qui engendrera forcément de mauvais comportements

 

2 réflexions sur “Zero Downtime déploiement sur Tomcat7

  1. Pingback: My Docker getting started : packaging my java standalone application inside docker | Le blog du petit Zoumana

  2. Pingback: AWS ELB: Zero downtime or Blue Green or Canary deployments! | Le blog du petit Zoumana

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s