CR du séminaire SpringSource "Expert Tomcat" [1/2]

Mardi 20 janvier dernier avait lieu le séminaire « Expert Tomcat » organisé par SpringSource. Une fois n'est pas coutume, il n'a pas été question de développement d'applications Web Java mais de problématiques avancées de production avec au menu : déploiement à grande échelle, optimisation de performances ou bien encore résolution d'incidents de production. Filip Hanik de SpringSource et committer actif sur le projet assurait la présentation.

Voici la première partie du compte-rendu résumant quelques-unes des recettes permettant d'utiliser Tomcat dans un environnement de production. Les slides de l'évènement sont disponibles à cette adresse.

Gestion des instances Tomcat en Production

Séparer l'installation des applicatifs

La première règle d'or à appliquer lors d'une installation de Tomcat est la séparation des fichiers d'installation et des fichiers applicatifs, ce qui permet de :

• mettre à jour Tomcat facilement sans impacter les applications (et inversement on peut revenir à une version antérieure en cas de découverte de bug)
• mettre des droits différents sur les répertoires sur un système Unix, ainsi une équipe projet peut avoir accès en écriture à son répertoire webapps sans pouvoir toucher aux fichiers d'installation

Plus concrètement, dans les scripts de démarrage on peut distinguer deux variables : CATALINA_HOME et CATALINA_BASE : la première définit le répertoire d'installation, la deuxième celui d'exécution. Pour obtenir une instance Tomcat, il suffit de recopier le répertoire conf et de créer les répertoires logs, temp, webapps et work :

Autre bénéfice, le répertoire webapps ne contient pas les applications web de l'installation originale, la nouvelle instance démarre donc en quelques centaines de millisecondes et ne contient que le strict nécessaire.

Il est important de noter que cette séparation installation / applicatif est un pattern appliqué depuis de nombreuses années dans les grands comptes utilisant des serveurs d'application commerciaux et où les contraintes de production sont très fortes. Or, ont voit que des produits OpenSource comme Tomcat sont tout à fait à même de répondre à ces exigences.

Gestion du multi-instance par mutualisation du fichier server.xml

Une autre propriété intéressante dans le cas du multi instances (pour du fail-over par exemple), on peut mutualiser le fichier de configuration server.xml et utiliser des variables de substitution. Ainsi on ne modifiera plus que le fichier de propriétés catalina.properties dans les répertoires des différentes instances.

Dans cet exemple, server.xml est commun et définit des paramètres, ici le port d'écoute :

connector.port=8080

Enfin, on spécifie à Tomcat d'utiliser le fichier server.xml commun en passant le paramètre –config au script catalina.sh. Pour créer un nouveau nœud il suffira de créer une arborescence basique et quelques fichiers de configuration, ce qui est facilement scriptable et donc automatisable. Fin du premier article, dans le prochain nous aborderons la configuration avancée et présenterons le dernier produit de la gamme SpringSource basé sur Tomcat.