DevOps aborde le paradoxe entre des équipes projets qui cherchent à livrer toujours plus fréquemment des nouvelles fonctionnalités d’une part et d’autre part des équipes d’exploitation qui cherchent à stabiliser et fiabiliser les systèmes tout en maitrisant leur coût.

On peut décrire DevOps selon trois axes :

• Aligner l’exploitation sur les enjeux métiers comme l’agilité a déjà aligné le développement sur le métier.
• Aligner le développement sur les réalités de l’exploitation pour rendre possible la mise en production, la disponibilité et la fiabilité des fonctionnalités métier.
• La transformation du métier d’OPS pour gérer des topologies chaque jour plus grosses et plus complexes avec l’adoption d’infrastructure as code et d’outils comme Chef ou Puppet. Les nouveaux OPS sont des programmeurs ! Ils débattent à la machine à café de TDD, de Ruby vs. DSL, de choix d’IDE, de Git vs. SVN, …

DevOps est souvent associé à la mise en place d’un processus de Continuous Delivery qui, dans la mouvance Lean, vise à déployer les fonctionnalités en production au plus vite et de maximiser les feedbacks. Nous reviendrons dans un autre billet sur les processus de Continuous Delivery.

La mise en place d’une culture DevOps touche les humains, les processus et les outils. Nous proposons une démarche englobant ces trois aspects en prenant comme point d’entrée les processus et, de proche en proche, faire évoluer les humains et les outils.

Les processus

Tous les processus impliquant la collaboration des équipes de développement et d’exploitation sont sujets à la mise en place d’une culture « DevOps ». Nous proposons pour la première étape de nous focaliser sur les processus de livraison, de déploiement et de troubleshooting.

Processus de livraison

Le processus de livraison (aka processus de packaging de la release) est la première interaction entre les équipes de développement et de production. Ses défauts causent l’allongement des projets et des interruptions de service. A l’inverse, l’automatisation du processus de livraison concilie « time to market » et diminution des risques en déployant plus fréquemment des changements au périmètre limité.

Nous proposons d’accorder les équipes de développement et d’exploitation sur les points suivants :

• Périmètre du package pour éviter les transformations et manipulations de mise en production : binaires identiques sur tous les environnements, fichiers de configurations épurées, etc.
• Rôles et responsabilités des équipes de développement et d’exploitation dans le packaging : binaires pour les développeurs, scripts et paramètres de configuration gouvernés par l’exploitation, etc.
• Définition des outils et techniques de packaging : tag Subversion/Git, build Maven, repository Maven Nexus, etc.
• Alignement des environnements de développement, d’intégration et de production pour éviter les écarts dev/prod : on doit tester sur un environnement le plus iso-prod possible.

Processus déploiement 

Une fois le packaging clarifié, nous proposons d’automatiser et d’unifier les processus de déploiement du dev à la prod. Les bénéfices sont :

• L’accélération des feedbacks des équipes de Q&A par des déploiements plus fréquents sur les environnements de validation.
• La fiabilisation des déploiements en les testant avant la mise en production.

L’objectif est la banalisation : les déploiements deviennent des « non événements ».

Processus de troubleshooting et de diagnostique

Réussir l’analyse de problèmes en production nécessite une préparation et un entrainement conjoints des équipes d’exploitation et de développement.

Des répétitions impliquant à la fois OPS et DEV permettront de valider :

• Que les applications sont debuggables : clarté des messages de log, clarté des exceptions, indicateurs de monitoring (JMX), etc.
• Que les outils de diagnostique sont installés : activation et collecte de logs, accès sans problèmes de firewall, disponibilité des outils sur les serveurs (curl, screen, jstat, jmap, etc.).
• Que les OPS et les DEV ont les bons outils de collaboration lors de problèmes en production : accès en lecture seule pour les DEV, messagerie instantanée, partage d’écran, micro-casques, etc.

Amélioration continue dev/prod

Les sujets d’amélioration continue transverse développement / exploitation sont gérés à la fois dans la continuité avec des réunions « dev/prod », et lors d’événements particuliers sous forme de points « post mortem » (panne, mise en production importante, etc.). Les sujets abordés relèvent d’enjeux à court, moyen et long terme :

• Monitoring & KPI : mise en place d’indicateurs techniques et métiers de bonne santé des applications (choix des outils, adaptation du code métier, health checks, etc.).
• Gestion des logs et des exceptions : amélioration des messages, outils de concentration et d’analyse de logs.
• Robustesse, tenue à la charge et capacity planning : suppression des points de faiblesse, mise en place de modes dégradés et de mécanismes de protection contre les saturations (e.g. : circuit breaker pattern), plans d’action de test en charge, plan d’ajout de capacité.
• Sécurité : patchs à appliquer, règles de sécurité de l’entreprise, etc.
• Fiabilisation des mises en production : activation progressive (feature toggle) ou partielle (canary testing) de fonctionnalités, etc.
• Processus et outillage : amélioration des processus dev/prod, alignement et partage des outils.
• Suivi du schéma directeur : gestion des montées de version des middlewares, migrations techniques, rationalisation des environnements.
• Evolutions de l’application et de l’infrastructure : refactoring de l’infrastructure, introduction de nouvelles technologies, plan de montée en compétence.

L’organisation : You build it, you run it ?

L’organisation est le sujet le plus complexe à aborder dans la mise en place d’une culture « DevOps ». Certaines entreprises comme Amazon ont intégré les équipes de développement et de production au point d’avoir pour devise « You build it, you run it ».

Un point essentiel est de s’assurer que les objectifs des différents acteurs soient alignés vers une amélioration de la disponibilité et de l’évolutivité des applications. Si les intérêts des uns et des autres sont contradictoires et ne sont pas alignés sur ce même objectif, l’adoption d’une culture « DevOps » touchera vite ses limites.

Nous proposons d’étudier les changement organisationnels au fur et à mesure de la mise en place des principes DevOps dans les processus que nous avons cité en veillant à prendre en compte les réalités de chaque entreprise.

La saison est au Continuous Delivery ! Venez découvrir comment automatiser le déploiement d’une application java web typique sur des serveurs Tomcat via une usine GitHub/Jenkins/Nexus.

Nous verrons plusieurs techniques de déploiement, de la plus simple à la plus sophistiquée :

1. déploiement sur Tomcat avec des commandes shell lancées par Jenkins au lieu de les lancer à la main ;
2. utilisation du tomcat-maven-plugin avec les conseils d’Olivier Lamy, lead developer du plugin et committer Tomcat ;
3. homogénéisation des déploiements du dev à la prod avec Jenkins associé à Rundeck pour gérer des commandes shell. Vincent Behar, committer Jenkins et ‘owner’ du jenkins-rundeck-plugin nous présentera cet outil Open Source en vogue chez les OPS ;
4. DeployIt : l’outil intégré d’automatisation des déploiements made in Xebia.

Pour avoir plus de détails sur le déroulement de l’atelier et pour vous inscrire, nous vous invitons à utiliser la page dédiée sur Eventbrite.

Dans l’esprit DevOps, il faut avoir un mode de déploiement le plus tôt possible identique à celui de la production. L’approche par script convient ainsi à un maximum d’environnements possibles (du test jusqu’à la production).
Pour ce faire, le script sera placé sur le serveur distant et exécuté à distance.

Le but de cet article est de vous proposer une solution pour déployer une application web sur un serveur Tomcat distant à chaque commit sur votre repository. Pour cela, nous allons utiliser le plugin Remote SSH pour Jenkins.

Prérequis

Lors de l’atelier, les différents outils étaient fournis sur des machines virtuelles Linux sur Amazon EC2. Si vous souhaitez refaire les manipulations sur votre poste, vous aurez besoin d’installer :

• un JDK
• Apache Maven
• Nexus
• Jenkins
• Apache Tomcat 6
• le script de déploiement créé pour l’atelier, disponible ici : tomcat-deploy-petclinic.

Il vous faudra donc une machine distante avec un serveur SSH si vous souhaitez réaliser cet exemple.

Téléchargement du projet d’exemple

Nous avons mis à disposition un projet d’exemple xebia-petclinic-lite sous GitHub. Pour tester cet article, vous pouvez cloner ce projet. Nous avons déjà décrit cette partie dans notre précédent article.

git clone https://github.com/xebia-france-training/xebia-petclinic-lite.git

Vous devez avoir un serveur Nexus installé en local. Une fois installé, vous devez changer dans le pom.xml les URLs des repositories avec vos valeurs (le serveur Nexus des Xebia Tech Events n’est actif que pendant les ateliers).

<distributionManagement>
 <repository>
  <id>xebia-tech-event-nexus-releases</id>
  <name>Xebia Tech Event Nexus Releases</name>
  <url>http://votreNexus/content/repositories/releases</url>
 </repository>
 <snapshotRepository>
  <id>xebia-tech-event-nexus-snapshots</id>
  <name>Xebia Tech Event Nexus Snapshots</name>
  <url>http://votreNexus/content/repositories/snapshots</url>
 </snapshotRepository>
</distributionManagement>

Ensuite, un « mvn deploy » permettra d’avoir un projet fonctionnel déployé dans votre repository.

Création du script

Le script shell que nous allons créer doit assurer les fonctions suivantes :

• Arrêter Tomcat,
• Supprimer le war et les dossiers de l’application dans webapps et temp,
• Télécharger une version de l’application depuis Nexus,
• Démarrer Tomcat,
• Effectuer un test de connexion HTTP à la page principale de l’application pour vérifier le bon démarrage de l’application déployée.

Pour le téléchargement du war, nous faisons appel à l’API REST du serveur Nexus. Nous allons utiliser le service /artifact/maven/content, dont voici les paramètres :

• g : Group id de l’artéfact (Obligatoire).
• a : Artifact id de l’artéfact (Obligatoire).
• v : Version de l’artéfact (Obligatoire) Supporte les mots-clés comme « LATEST », « RELEASE » et les version SNAPSHOT ou non (« 1.0-SNAPSHOT », « 1.2.3′ …).
• r : Identifiant du repository Nexus qui contient l’artéfact (Obligatoire). Attention, par défaut, les artéfacts versionnés et les snapshots ne sont pas stockés dans le même repository. Donc pensez à mettre le bon identifiant de repository ici « releases » ou « snapshots » (rechercher des versions SNAPSHOT dans le repository RELEASES ne va pas être simple !). Petite astuce, vous pouvez aller voir dans votre settings.xml de Maven pour connaitre les repositories (normalement, seulement présent sur le serveur d’intégration continue).
• p : Type de packaging de l’artéfact (Optionnel, par défaut il vaut .jar, donc pour un .war, il faut bien penser à le spécifier).
• c : Qualificatif de l’artifact (Optionnel, voir la notion d’identifier dans MAVEN).
• e : Extension de l’artéfact (Optionnel) A VOIR

Ainsi, télécharger la dernière snapshot d’un artefact peut se faire grâce à une simple commande CURL sous Unix, dont voici un exemple :

curl "http://nexus.xebia-tech-event.info:8081/nexus/service/local/artifact/maven/content?g=fr.xebia.demo.petclinict&a=xebia-petclinic-lite&r=snapshots&v=LATESTS&e=war" \
   --silent \
   --show-error  \
   --output "/opt/tomcat/apache-tomcat-6/webapps/xebia-petclinic-lite.war"

Comme dit plus haut, le serveur Nexus du Xebia Tech Event est démarré uniquement pendant les ateliers, inutile donc d’essayer cette URL depuis chez vous !

Pour vérifier le bon démarrage de Tomcat, on peut de nouveau utiliser la commande CURL pour vérifier si l’application est bien déployée. En voici un exemple :

curl --connect-timeout 10 --retry 10 --silent --show-error -w "%{http_code}" -o /dev/null http://localhost:8080/xebia-petclinic-lite

Vous pouvez retrouver le script complet qui nous a servi pendant l’atelier sur tomcat-deploy-petclinic. Seules quelques adaptations seront nécessaires pour utiliser ce script sur vos environnements de production (changement de groupId, d’URL de repository Nexus, etc).

Le plugin Remote SSH pour Jenkins

Notre script est maintenant prêt. Il ne vous reste plus qu’à le transférer vers votre machine distante (par SCP ou FTP, comme bon vous semble). Une fois sur le serveur, vous pouvez le lancer « à la main » pour vérifier qu’il fonctionne.

Dans notre exemple, nous nous authentifions sur les serveurs grâce à des clés privées, mais le reste de l’exercice peut aussi se faire avec un login et un mot de passe si vous le souhaitez.

Le Jenkins Remote SSH Plugin permet de se connecter à un serveur distant et d’y exécuter une série de lignes de commande. Un des avantages majeurs de la solution est qu’elle n’est pas intrusive. En effet, il n’y a pas d’agent spécifique à installer sur la machine, un simple accès SSH suffit. La gestion des clés et mots de passe se trouve ainsi centralisée dans Jenkins.
Lancer le script fait donc parti d’un job Jenkins. On pourra ainsi créer des workflows avec une succession de jobs.

Installation et configuration du plugin

Pour installer le plugin, rendez-vous dans la partie Administrer Jenkins, Gestion des plugins, puis dans l’onglet Disponible. Cochez la ligne devant le plugin, puis cliquez sur le bouton Installer qui se trouve tout en bas de la page.

Une fois le plugin installé, il faut configurer la liste des hôtes que nous voulons utiliser dans nos Builds. Pour cela, rendez vous dans la partie Administrer Jenkins, Configurer le système. Vous avez accès une section SSH Remote hosts dans laquelle nous allons déclarer les hôtes. Les boutons Ajouter et Supprimer permettent de gérer facilement la liste. Ensuite, il n’y a plus qu’à remplir les hôtes avec les informations suivantes :

• Hostname : serveur hébergeant votre Tomcat (Obligatoire),
• Port : d’écoute SSH (Optionnel, 22 par défaut),
• User Name : nom de l’utilisateur qui sera connecté au serveur (Obligatoire),
• Password/Passphrase : si vous utilisez une authentification simple, c’est ici qu’on ajoute le mot de passe, sinon cela peut aussi être la passphrase (Optionnel),
• Keyfile : si vous utilisez une authentification avec clé privée, on ajoute ici le chemin vers la clé qui doit se trouver sur le même serveur que Jenkins (Optionnel).

Petit inconvénient, il est impossible de créer un alias pour la configuration de chaque serveur. De plus, la liste des hôtes est unique pour toute l’instance Jenkins. Si plusieurs projets sont présents sur l’instance, avec des noms d’hôtes relativement similaire, cela peut nuire à la lisibilité.

Exploitation du script

Après avoir installé votre script sur la machine Tomcat et avoir déclaré ce serveur Tomcat dans Jenkins, nous allons maintenant configurer l’invocation du script.
Pour cela, il suffit de créer un projet Free-style dans Jenkins, de cocher l’option Execute shell script on remote host using SSH.
Sélectionnez ensuite l’hôte qui vous intéresse, puis dans la partie Post-build script, ajoutez la commande de lancement de votre script shell (par exemple /usr/local/script/deploy_on_tomcat ).
Vous pouvez lancer le job pour vérifier son fonctionnement.
Nous avons créé un job séparé ici, mais rien ne vous empêche de l’intégrer directement dans votre build Jenkins principal. Si vous déclenchez une intégration continue à chaque commit sur le dépôt de source, vous allez ainsi faire du déploiement continu sur votre serveur.
Si l’on possède plusieurs machines, il faudra par contre créer plusieurs jobs différents (c’est-à-dire créer plusieurs projets Free Style). L’hôte n’est pas paramétrable.

Conclusion

Pour résumer, nous pouvons dresser le bilan suivant de l’utilisation du jenkins-ssh-plugin pour automatiser le déploiement depuis Jenkins sur des serveurs Tomcat :

Avantages

• Simple et rapide à mettre en place,
• Pas d’agent à installer sur les serveurs,
• Gestion centralisée des accès aux machines,
• Se branche facilement sur l’intégration continue pour un déploiement continu en 0 clic,
• Compatible avec un mode de livraison en production (avec un bon script bien robuste, rien n’est impossible !).

Inconvénients

• Liste statique des hôtes
• Tous les hôtes sont à un seul endroit dans la configuration, cela devient compliqué à gérer avec un nombre croissant d’environnements,
• Le job est lié à la machine sur laquelle il exécute le script,
• Impossible de déployer l’application sur plusieurs machines, sauf à créer plusieurs jobs,
• Le script doit être déployé préalablement sur le(s) serveur(s) Tomcat.

• 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.

Au programme :

• Un retour d’expérience sur un gros projet agile distribué (100 personnes, 10 équipes, 4 pays) orienté culture DevOps, process… et (un peu outils).
• Monitoring dans un cadre DevOps : infrastructure, services, business, trend monitoring, alert monitoring, dashboards, wallboards, etc.

Les inscriptions se font sur lanyrd comme d’habitude : http://lanyrd.com/2011/paris-devops-meetup-4/

Notez bien l’adresse :
Xebia
156 boulevard Haussmann à Paris
Immeuble A – 7e étage

Les tâches de déploiement et de configuration des applications deviennent ainsi bien souvent un goulet d’étranglement quand elles ne sont pas un frein à l’activité.
Deployit, de la société XebiaLabs, a été conçu en collaboration avec KLM/Air France pour adresser cette problématique. Il est aujourd’hui mis en oeuvre avec succès par de nombreuses sociétés dans des secteurs très variés.

Les bénéfices de Deployit

• Réduire jusqu’à 95% des erreurs de déploiement et jusqu’à 50% de vos coûts de déploiement classique
• Réduire les temps d’attente des équipes via des déploiements en self-service et continus
• Standardiser les procédures de déploiement entre différents environnements
• Fluidifier les relations entre départements études, intégration/recette et production
• Augmenter contrôle et visibilité sur votre processus de déploiement applicatif
• Accélérer votre time-to-market

Programme du séminaire : le 29 avril de 9h45 à 11h45, 156 bd Haussmann 75008 Paris

• 9h45 : accueil
• 10h : présentation des enjeux du déploiement applicatif et de la solution Deployit
• 10h30 : démonstration produit
• 11h : retour d’expérience client Karavel/Promovacances

Public cible : Directeur Informatique, Responsable des Développements / Etudes, Responsable Intégration / QA / Tests, Responsable Production / Exploitation, Responsable Qualité, Architecte, Chef de projet

Inscription: http://www.xebialabs.com/seminaire-deploiement-automatique

Nous avons profité du passage en Europe de Jyoti Bansal pour organiser avec les équipes d’AppDynamics un événement autour du monitoring de la « vraie vie » .

A l’heure où l’architecture des applications d’entreprise devient de plus en plus complexe et distribuée, l’outillage dans le domaine du monitoring et du troubleshooting est un élément clé du système d’information. Notre objectif est que chacun en retire des idées immédiatement applicables et se forge une vision des problématiques que les systèmes de monitoring gèrent aujourd’hui et traiteront demain.

Après avoir consulté des Dev et des Ops des secteurs Telcos, Finance, Retail et Voyage, nous avons établi un programme reprenant des cas de notre vie quotidienne illustrés dans une application transactionnelle de eCommerce « réaliste » (1) que nous avons déployée en cluster sur 5 serveurs Amazon EC2., que nous soumettrons à diverses déconvenues courantes.

Programme

• 15 minutes de présentation de la nouvelle génération de systèmes de monitoring d’applications Java (AppDynamics, dynaTrace, JXInsight)
• 60 minutes de démonstration de cas concrets de monitoring :
  • Installation et configuration : mise en place du monitoring, auto découverte, déclaration d’indicateurs applicatifs, ajout de nouveaux serveurs au cluster,
  • Mise en place de tableaux de bord pour les équipes d’exploitation mais aussi de marketing et de développement,
  • Monitoring durant les situations de crise : tableaux de bord « sur mesure » temporaires pour le management, le marketing et les équipes de troubleshooting,
  • Monitoring au service du marketing : nous simulerons la mise en place de la sécurisation 3-D Secure des paiements carte bleue en mode A/B Testing,
• La place dans l’infrastructure du système de monitoring : synergies et chevauchement avec les serveurs d’application, les systèmes de gestion de logs, etc
• La vision de Jyoti Bansal sur les tendances du monitoring d’application, ce à quoi nous devons nous attendre
• Les internes des systèmes de monitoring de nouvelles génération :
  • « java agent embarqué » versus « agent autonome » versus « sans agent »,
  • les tableaux de bords, comment faciliter leur développement et leur utilisation à l’heure des widgets Open Social ?
  • scalabilité des systèmes de monitoring à l’heure où le nombre de serveurs s’envole.
• Coktail avec Jyoti et son équipe.

N’hésitez pas à nous proposer des questions ou des cas d’utilisation que nous ajouterons à nos préparations (cleclerc@xebia.fr et plopez@xebia.fr).

Bio

Jyoti Bansal est fondateur, CEO et CTO d’AppDynamics. Il a auparavant été Principal Architect de Wily Introscope.

AppDynamics a été fondé en 2008. Cette solution de monitoring est utilisée par des clients de la génération Internet aux infrastructures avant-gardistes comme NetFlix (1700 JVM sur Amazon EC2) mais aussi des clients plus traditionnels comme l’opérateur télécoms Swisscom, l’assureur Provinzial Insurance ou l’agence de voyage Priceline.com.

Organisation de la soirée

La soirée se déroulera dans les locaux de Xebia au 156, boulevard Haussmann, 75008 Paris, à partir de 19h00.
Les inscriptions peuvent se faire :

• Par mail : info@xebia-training.fr
• Par téléphone : 01.53.89.99.93

(1) Nous avons retenu Spring Travel enrichie par les Spring Payment Services et une brique « Anti Fraude » pour montrer les appels inter applications java. Le code source est disponible sous licence Apache ici .

Est-ce que nos outils de packaging actuels peuvent déployer nos applications?

Dans cet article, je souhaite comparer l’automatisation du déploiement au plus connu des processus automatiques du développement logiciel : le packaging de l’application. En simplifiant, le processus de packaging part du code source pour le transformer en code exécutable. La façon la plus simple pour créer ce code est d’utiliser un script shell qui lance le compilateur, mais ce processus a beaucoup mûri. Grâce à des outils comme Make, cité précédemment, mais aussi à Ant et Maven, l’utilisateur peut spécifier de manière très détaillée tout le processus. Prenons l’exemple de Maven, la plupart des projets n’ont plus besoin de scripter quoique soit. Le fichier POM décrit les composants du projet, les plugins utilisés, et la façon de packager l’application. Et en ce moment même, de nouveaux outils font leur apparition, comme Gradle, qui offre encore un peu plus de flexibilité.

Mais ces outils nous permettent-ils de faire du déploiement automatique? Dans un billet précédent, mon collègue Robert van Loghem a expliqué en quoi le déploiement est un processus complexe qui inclut un certain nombre d’étapes comme l’installation des EAR/WAR, la configuration des datasources et le redémarrage des serveurs.
Bien que Wikipedia inclut la fonction de déploiement vers des systèmes en production, lorsqu’il définit l’automatisation du packaging, les outils actuels n’ont pas intégré ces concepts de packages de déploiement (i.e. les livrables), les environnements cibles (test, recette, production, etc.) ou la modification des valeurs selon l’environnement. En réalité, ils n’ont pas de connaissances liées aux middlewares sur lesquels on déploie et ne proposeront certainement jamais des scenarii de déploiement. Au final, ce qu’offrent ces outils, c’est le moyen de scripter, bien connu des développeurs, et de stocker ces scripts avec les sources à installer. Cela amène irrémédiablement à de nombreux scripts « maison » pour automatiser les déploiements.

Mais ce n’est pas tellement surprenant. Dans Wikipedia, les pré-requis d’un système d’automatisation ne mentionnent pas le Déploiement. Un système de déploiement automatique a pour objectif de déployer du code exécutable sur un environnement cible, alors que le système d’automatisation du packaging ne fait que produire ce code exécutable.

Les pré-requis nécessaires pour que notre outil déploie

Voici une liste de pré-requis que devrait satisfaire un outil de déploiement automatique :

• Avoir nativement les concepts de base du déploiement : packages, environnements, lien entre les middlewares, etc.
• Support inclus pour les middlewares principaux avec une possibilité de l’étendre.
• Support inclus pour les scenarii courants de déploiement avec un moyen de les personnaliser.
• Proposer une séparation des rôles : les développeurs livrent le projet, un groupe d’administrateur définit les environnements et un autre groupe déploie l’application, etc.
• Supporter une charge croissante d’environnements avec plusieurs applications et de nombreux utilisateurs.
• Être capable de faire des déploiements multi-plateformes : des environnements complexes peuvent s’étendre sur de multiples systèmes d’opération et versions.

Les outils d’automatisation de packaging ne répondent pas à ces pré-requis et vouloir les étendre ne fera que complexifier leur utilisation sans pour autant faciliter convenablement les déploiements.
Cela explique l’émergence d’outils de déploiement automatique, qui ont dépassé les anciens outils de scripts « maison ».

Que l’on soit bien d’accord, les outils de déploiement automatique ne remplacent pas les outils d’automatisation des packages. Mais les deux ont leur place dans le paysage des livraisons d’applications. Les outils de packaging produisent le code exécutable et les outils de déploiements s’assurent de rendre ce code disponible pour les utilisateurs finaux !

Dans le prochain article de cette série, nous expliquerons en quoi le déploiement automatique est différent du mécanisme de gestion des livraisons de nouvelles versions.

Mais voilà, comme on l’avait rapidement suggéré précédemment, il existe un scénario légèrement plus compliqué que celui décrit ci-dessus ; il s’agit du cas de mise à jour d’une application vers une nouvelle version. Bien que le déploiement initial d’une application soit forcément important, un certain nombre de raisons me fait penser que le déploiement d’une nouvelle version l’est encore plus.

Livrer une nouvelle version est plus important que le premier déploiement !

Voici quelques raisons qui peuvent vous convaincre de porter plus d’attention à une nouvelle livraison:

• Les mises à jour sont plus fréquentes qu’un déploiement initial. ;-)
• Les mises à jour en production ont lieu alors que les utilisateurs sont déjà en train d’utiliser l’application ; il est préférable que cette dernière reste accessible pendant le déploiement ou, au pire, que la coupure soit la plus brève possible.
• Si une mise à jour échoue, l’ancienne version doit toujours être réinstallable.
• Et le fait qu’une mise à jour soit « routinière », peut tromper la vigilance des différentes personnes, responsables du déploiement. Il faut se méfier de l’excès de confiance. Lorsqu’une application est déployée pour la première fois, chacun est très attentif : les développeurs, les administrateurs des différents composants, les architectes, les responsables de projet, les utilisateurs, etc. Donc, quand un problème arrive, il est traité très rapidement. En revanche, si on souhaite déployer la version 2.1.54 un vendredi après-midi, c’est là que tout peut aller de travers.

En résumé, la mise à jour d’une application est complexe, et être concentré permet de diminuer les risques d’échec.

A présent, partons du scénario initial lorsque l’application est déployée. Ce scénario comprenait un fichier EAR, quelques fichiers statiques (images, css, etc.) et des scripts SQL.
Comment allons-nous mettre à jour cette application pour passer en v1.1 ? Pour simplifier, nous imaginons qu’il n’y a pas eu de changements sur le schéma de base de données entre v1.0 et v1.1.
Deux solutions sont possibles : soit nous mettons à jour juste ce qui est nécessaire, il s’agit alors d’un déploiement incrémental, soit nous supprimons la totalité de v1.0 et déployons proprement v1.1, et dans ce cas on fait un redéploiement complet.

Etapes nécessaires à chaque scénario

Si on choisit de simplement mettre à jour, voici les tâches à accomplir :

1. Supprimer le contenu statique v1.0 du serveur web.
2. Arrêter l’application v1.0.
3. Supprimer l’application v1.0.
4. Déployer l’application v1.1 à partir du fichier EAR.
5. Démarrer l’application v1.1.
6. Copier le contenu statique v1.1 sur le serveur web.

Et un redéploiement complet ressemble à ceci :

1. Arrêter le serveur web.
2. Supprimer le contenu statique v1.0 du serveur web.
3. Supprimer la configuration v1.0 du serveur web.
4. Arrêter le serveur d’applications.
5. Supprimer l’application v1.0.
6. Supprimer la configuration du serveur d’applications nécessaire à v1.0 (source de données, queues, etc.).
7. Créer la configuration du serveur d’applications pour v1.1.
8. Déployer l’application v1.1 à partir du fichier EAR.
9. Démarrer le serveur d’applications.
10. Créer la configuration v1.1 du serveur web.
11. Copier le contenu statique v1.1 sur le serveur web.
12. Démarrer le serveur web.

Si on compare les deux scénarii, on note aisément le nombre de différences :

• Le serveur web est arrêté au début et démarré seulement à la toute fin (étape 1 et 12).
• La configuration du serveur web est supprimée avant d’être recréée (étape 3 et 10).
• Au lieu de simplement arrêter puis démarrer l’application, le serveur d’applications complet est arrêté et démarré (étape 4 et 9).
• La configuration du serveur d’applications est elle aussi supprimée puis recréée (étape 6 et 7).

En supprimant puis recréant la configuration du serveur web et du serveur d’applications, nous avons la certitude de connaitre exactement le résultat qu’on obtiendra. En effet, si des changements ont eu lieu dans la configuration qui n’ont pas été notés, ils seront supprimés et non recréés. Pour ce faire, il faut arrêter les serveurs avant de les redémarrer à la toute fin du déploiement. Par contre, cela rend l’application indisponible, mais vous savez de toutes façons qu’il faudra bientôt mettre en place un cluster pour avoir une haute disponibilité, n’est-ce pas ? ;-)

L’autre point intéressant de ce scénario se trouve entre les étapes 7 et 12. Vous aurez certainement noté qu’elles correspondent exactement au scénario du déploiement initial de votre application. La petite différence se situe au niveau des étapes de création du schéma de la base de données. On peut enfin noter que les étapes 1 à 6 permettent de désinstaller complètement l’application.

Résumons maintenant les avantages et inconvénients des deux scénarii.

Du pour et du contre

Dans le cas du déploiement incrémental, on peut retenir les points suivants :

• Pour : Le déploiement incrémental s’exécute très vite car il fait le strict minimum.
• Contre : Le déploiement incrémental laisse éventuellement des traces de modifications manuelles. Ce point est problématique car la configuration a pu être changée de manière « magique » et sûrement non documentée pour que l’application fonctionne. Si vous décidez de migrer sur un autre serveur, vous oublierez probablement ces petites retouches. Et par-dessus tout, nous pouvons imaginer que si cela a été fait sur un des serveurs, et bien … je vous laisse compléter la phrase. :-)
• Pour : Le déploiement incrémental ne touche pas aux systèmes qui sont normalement OK. Mais encore une fois, si vous craignez de toucher votre système parce que ça pourrait ne plus fonctionner du tout, vous avez du travail. Il faut avoir suffisamment confiance dans les composants de votre environnement pour ne pas avoir peur de faire un changement, de redémarrer le serveur et enfin de prier pour que ça re-fonctionne correctement.
• Contre : Il est plus difficile de faire un retour arrière avec un déploiement incrémental. Pour chaque déploiement incrémental, il est nécessaire de décrire le scénario de retour arrière. En effet, comme le précédent déploiement était aussi incrémental, on ne peut donc pas le relancer. Sans scénario de retour arrière, la seule façon de revenir à v1.3 est de faire un déploiement « propre » de v1.0 est de déployer successivement v1.1, v1.2 et enfin v1.3.

A présent, voyons un peu ce que le redéploiement complet apporte comme solutions mais aussi comme difficultés :

• Pour : Le redéploiement complet efface toutes modifications manuelles, ne laissant que la configuration « bien » documentée en place.
• Pour : Le redéploiement complet est reproductible et prévisible. Grâce aux procédures qui sont systématiquement les mêmes, il n’y a aucune importance à connaitre ni la partie du produit qui a changé, ni l’état actuel de l’environnement cible. Ca sera toujours le même résultat.
• Pour : Le redéploiement complet permet d’avoir une stratégie de retour arrière extrêmement simple. Quand le déploiement d’une nouvelle version échoue, ou que la nouvelle application ne fonctionne pas, il suffit de déployer la version précédente.
• Contre : Conserver l’application disponible pendant le déroulement d’un redéploiement complet est une affaire plus délicate que pour un déploiement incrémental. Pour avoir une application en haute disponibilité, il est indispensable de configurer un cluster.
• Contre : Un redéploiement complet peut s’exécuter lentement si l’environnement cible n’est pas assez rapide, car le nombre d’opérations de configuration est important.

Déploiement incrémental, plus sûr que le redéploiement complet ?

Pour ma part, même si le redéploiement complet est parfois plus difficile et plus long à mettre en œuvre, le fait qu’il soit prévisible et reproductible est un avantage décisif qui fait passer les inconvénients au second plan. Le déploiement incrémental peut sembler être une approche plus simple et plus rapide pour déployer des mises à jour, mais vous sacrifiez ce qui est essentiel pour un scénario de déploiement, le processus de retour arrière. L’unique cas où le déploiement incrémental est indispensable, c’est lorsqu’on met à jour une base de données. Dans tous les autres, il est recommandé d’utiliser le redéploiement complet pour appliquer des changements.

Traduction libre du billet « Incremental deployments vs. full redeployments » publié par Vincent Partington sur blog.xebia.com.

Par audit, nous entendons l’audit des actions importantes réalisées sur une application.

Pourquoi auditer ?

Est-il vraiment utile de générer des informations d’audit dans nos applications ? Sans explications de juriste, quelques exemples suffiront à nous en convaincre :

• Un site web de partage de photos doit pouvoir dire qui a uploadé quelle image, depuis quelle adresse IP et à quelle date.
• L’application d’administration d’un site de e-commerce doit tracer toutes les modifications de prix pour empêcher un employé astucieux de baisser à 1 euro le prix de son téléphone préféré le temps de passer commande.

Pour revenir à des explications plus théoriques, les logs d’audit nous apportent :

• les informations nécessaires à la justice en cas d’infraction,
• la détection d’intrusions,
• la reconstitution des événements en complément des logs d’exceptions pour aider au diagnostique de problèmes.

Nous nous placerons dans le cas le plus fréquent où nous ne développons pas d’outil pour consulter ces informations d’audit et où un accès direct au média de stockage (grep sur fichier texte, sql sur base de données, etc) suffit.

Que faut-il auditer ?

Dans un monde idéal, le contenu des messages serait défini avec les équipes de sécurité. En pratique, nous sommes assez seuls pour les choisir et il ne faut pas dramatiser. Si l’on ne prend pas le sujet à la légère, après quelques itérations, notre bon sens est le plus souvent suffisant.

Les éléments clefs à tracer sont :

• L’heure exacte : il est essentiel que les serveurs soient à l’heure pour corréler les logs des différentes briques du système d’information. Le sujet est aujourd’hui censé être banal pour les équipes système (c.f. NTP) et nous pouvons demander le soutien des équipes sécurité pour obtenir gain de cause.
• L’action réalisée : il s’agit souvent du nom de la méthode métier appelée.
• L’identifiant et/ou la valeur des données métier sensibles manipulées : souvent les id ou le toString() des paramètres d’appel.
• L’auteur de la manipulation : nom de l’utilisateur connecté et son adresse ip (pour plus de détails sur l’adresse ip : XForwardedFilter et Tomcat : Adresse IP de l’internaute, load balancer, reverse proxy et header Http X-Forwarded-For).
• La description succincte des exceptions levées pour analyser les éventuelles attaques.

Pourquoi les logs d’accès des serveurs http ne suffisent pas ?

La première idée serait de se contenter des logs d’accès des serveurs web et des firewalls pour auditer les accès à nos applications ; nous n’aurions alors plus rien à faire.

Hélas, cela n’est pas suffisant car il manque dans les logs http des informations clefs :

• Nous n’avons pas l’identité de l’appelant : on a bien l’adresse ip mais pas le login de l’utilisateur authentifié.
• Nous n’avons pas les id passés en paramètre des opérations à auditer (sauf si on fait du REST) ; en SOAP, nous n’avons même pas le nom de l’opération !
• Nous n’avons pas le détail des exceptions levées par l’application.

API : Framework de log vs. framework dédié

Dans un monde idéal, le framework d’audit ne devrait pas dépendre de la configuration des logs pour ne pas risquer qu’une mauvaise manipulation de ces configurations de logs ne le désactive.

En pratique, les frameworks de logs sont les briques les plus performantes et les plus matures pour traiter les besoins d’écriture d’audit et la probabilité de désactiver l’audit en faisant une mauvaise manipulation sur la configuration des logs est négligeable. Ces raisons nous amènent à utiliser SLF4J avec logback ou log4j pour gérer l’audit.

Nous encapsulerons tout de même le logger avec une couche légère packagée dans la librairie Xebia Spring Security Extras qui ajoutera au message l’identité de l’internaute et son adresse IP (via Spring Security). Cette librairie offre une gestion déclarative de l’audit avec une annotation @Audited, son aspect associé AuditAspect et une classe utilitaire Auditor. Nous ne rentrerons pas dans le débat annotations vs. code ; dans la majeure partie des projets, nous avons pu traiter la plupart de l’audit avec une annotation et seuls quelques cas ont nécessité de passer par du code.

Exemple de gestion de l’audit avec l’annotation @Audited :

@Audited(message = "transferMoney(#{args[0].accountNumber}, #{args[1].accountNumber}, #{args[3]})")
public void transferMoney(Account from, Account to, Amount amount) throws BusinessException { ... }

L’attribut message est un pattern supportant Spring Expression Language définissant l’entrée insérée dans le fichier d’audit ; la date, le nom de l’utilisateur, l’adresse ip et l’exception s’il y en a une sont ajoutés au message.

Fragment de configuration Spring Framework pour utiliser l’annotation @Audited :

<beans ...
   xmlns:security-extras="http://www.xebia.fr/schema/xebia-spring-security-extras"
   xsi:schemaLocation="...
        http://www.xebia.fr/schema/xebia-spring-security-extras http://www.xebia.fr/schema/security/xebia-spring-security-extras.xsd">
   <!-- enable Spring AOP -->
   <aop:aspectj-autoproxy/>
  <!-- activate the AutitAspect -->
  <security-extras:audit-aspect />
   ...
</beans>

Message d’audit généré :

... transferMoney(000652584515, 0000684651684, 187.53) by bdupont coming from 192.168.0.14
... transferMoney(000652584515, 0000684651684, 666666.00) threw '...BusinessException: debit amount greater than account balance'
   by bdupont coming from 192.168.0.14

Exemple de gestion de l’audit avec l’utilitaire Auditor :

public void transferMoney(...) throws BusinessException {
   ...
   Auditor.audit("Tranfer '" + amount + "' from " + fromAccount + " to " + toAccount);
}

Message d’audit généré :

... Transfer '187.53 euros' from Account[000652584515] to Account[0000684651684] by bdupont coming from 192.168.0.14

L’entrée d’audit est ajoutée dans un fichier d’audit géré par le logger spécifique "fr.xebia.audit" (voir cet article pour la configuration du logger).

Tous les détails sur l’annotation @Audited sont sur @Audited Annotation.

Intégration du framework dans une application

Ce framework peut être intégré de différentes façons dans une application :

• Intégration Maven :

  <project ...>
     <dependencies>
        <dependency>
           <groupId>fr.xebia.springframework</groupId>
           <artifactId>xebia-spring-security-extras</artifactId>
           <version>1.1.6</version>
        </dependency>
        ...
     </dependencies>
     ...
  </project>
  

  Cet artifact est déployé sur le Maven Central Repository.

• Téléchargement du jar xebia-spring-security-extras-1.1.6.jar (sources).
• En récupérant le code source disponible sous licence Open Source Apache Software Licence 2 dans le repository GitHub https://github.com/xebia-france/xebia-spring-security-extras.

Stockage : fichier texte vs. base de données

Le stockage des entrées d’audit en base de données permet sûrement une recherche plus fine des données que sur des fichiers mais cela ajoute de la complexité (déploiement, exploitation, backup) ainsi que des risques de pannes et impacte les performances. Les approches JMS présentent des contraintes similaires et l’utilisation de systèmes de logs distants comme rsyslog présentent un défi de fiabilité. Ces difficultés sont accentuées lorsqu’une application génère de gros volumes de logs (plusieurs Go/jour).

Pour ces raisons, nous préférons stocker les messages d’audit dans un simple fichier. Les risques de saturation du système de fichiers sont assez facilement gérables par les équipes d’exploitation, les procédures d’archivage et de consultation très simples (gzip, scp, grep, etc) et il n’y a quasiment jamais de problème de performance, même avec des fichiers de quelques Go par jour.

Y-a-t-il un plus grand risque de perdre les données par de mauvaises manipulations ? Si une application est critique, les exploitants doivent déjà ne pas perdre les fichiers de log du système d’exploitation, des serveurs web et autres firewalls.

Pour la gestion des messages d’audit sous forme de fichier texte, nous aimons logback comme nous l’avons expliqué dans Java en Production – Les fichiers de logs mais il est aussi possible d’utiliser Log4j.

Exemple de configuration Logback pour gérer les messages d’audit émis sur le logger fr.xebia.audit :

<appender name="audit-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
   <file>${LOGS_FOLDER}/my-application-audit.log</file>
   <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <!-- rotate every day -->
      <fileNamePattern>/my-application-audit.%d{yyyyMMdd-HHmm}.log.zip</fileNamePattern>
   </rollingPolicy>
   <encoder>
      <!-- don't output the date or the logger name because the auditing framework handles this -->
      <pattern>%m %throwable{0}%n</pattern>
   </encoder>
</appender>
<!-- route the 'fr.xebia.audit' log messages to the audit-file -->
<logger name="fr.xebia.audit" additivity="false" level="TRACE">
   <appender-ref ref="audit-file" />
</logger>

Exemple équivalent avec log4j (le EnhancedPatternLayout requiert log4j 1.2.16) :

log4j.appender.auditfile=org.apache.log4j.DailyRollingFileAppender
log4j.appender.auditfile.datePattern='-'yyyyMMdd
log4j.appender.auditfile.file=${catalina.base}/logs/my-application-audit.log
log4j.appender.auditfile.layout=org.apache.log4j.EnhancedPatternLayout
log4j.appender.auditfile.layout.conversionPattern=%m %throwable{short}n
log4j.logger.fr.xebia.audit=INFO, auditfile

Que faire des logs d’audit après les avoir générées ?

Nous ne rentrerons pas plus dans les détails de la gestion des logs d’audit après leur génération par nos applications.

Ce sujet complexe présente aussi bien des aspects juridiques que de confidentialité ou encore de fiabilité. Schématiquement, on n’a pas le droit de garder indéfiniment des données personnelles, il faut restreindre leur consultation et empêcher leur modification et leur destruction par accident comme par malveillance.

Des professionnels de l’exploitation et de la sécurité sont beaucoup plus compétents que nous sur ce sujet .

Pour aller plus loin

Si le traitement de l’audit dans les applications vous a intéressé, nous avons aimé lire :

• The Importance of Audit Logs par George Spafford,
• NIST 800-92 Log Management Guide in the Real World et l’ensemble des présentations de Anton Chukavin.

Synthèse

Nous avons vu aujourd’hui une façon simple de gérer l’audit d’applications java en reposant sur le framework de log de l’application (Logback voire Log4j) pour écrire les messages dans de simples fichiers texte avec une surcouche très légère composée d’une annotation @Audited et d’un utilitaire Auditor.

Historique
25/11/2010 : passage à la version 1.1.5 de la librarie xebia-spring-security-extras avec utilisation du namespace de configuration.
20/12/2011 : xebia-spring-security-extras : passage à la version 1.1.6 et aux URLs GitHub

D’accord, l’envers du décor est moins reluisant et il reste une marge de progression. Nous avions proposé dans Les 10 commandements des logs applicatives des suggestions focalisées sur le contenu des fichiers de logs ; voici aujourd’hui des propositions pour gérer les fichiers eux-mêmes. Même si le sujet peut sembler trivial, ces bonnes pratiques peuvent grandement simplifier le quotidien des équipes de production et améliorer les relations tumultueuses entre exploitants et développeurs.

Au risque de surprendre certains, les exemples de ce billet utilisent Logback plutôt que le standard de-facto Log4j car certaines bonnes pratiques que je proposerai sont impossibles à mettre en oeuvre avec Log4j. Aujourd’hui, je préfère utiliser Logback à Log4j pour gérer les logs de mes applications … même si je suis nostalgique du format ‘.properties’ pour la configuration de ces dernières .

Bien que Logback ne soit pas le sujet de ce billet, j’ai ajouté à l’article initial un paragraphe « Pourquoi je préfère Logback à Log4j » pour expliquer ce choix.

Différents fichiers de logs pour différents besoins

On utilise souvent un seul fichier mon-application.log pour écrire toutes les logs : les informations d’audit, les logs d’exception avec des stack traces sans fins aussi bien que les informations de diagnostique/troubleshooting. Ce fichier se remplit de centaines de lignes par minute, et c’est alors la déception pour tous ses utilisateurs :

• l’exploitant est incapable de dire si une application a un problème en regardant les logs sans un astucieux système de ‘grep‘ et d’expressions régulières,
• l’administrateur système et les responsables de la collecte des logs sont incapables de dimensionner les disques pour des logs dont la taille explose au moindre grain de sable à coup de stack traces dont il est pourtant inutile de conserver le détail,
• les équipes de diagnostique/troubleshooting sont noyées dans la masse des informations lorsqu’elles doivent intervenir.

Au final, c’est l’échec de la transmission de l’application du développement à la production et les exploitants prennent les développeurs pour des inconscients. Je ne saurais leur donner tort sur ce problème et voici ma proposition de découpage des fichiers de logs.

Les logs applicatives

Ce fichier ne trace que les dysfonctionnements, il n’est pas censé se remplir quand l’application fonctionne normalement et est archivé pendant plusieurs années par l’exploitant.

Ses caractéristiques sont :

• seuls les messages de dysfonctionnement (ie >= WARN) y apparaissent,
• ce fichier tourne (‘est rotationné’ en franglais) chaque jour pour être archivé,
• les stack traces seront compactes pour éviter de saturer le système de fichiers. Compacter à deux lignes par cause d’une exception est un bon compromis entre le niveau de détail utile au diagnostic et la taille occupée sur disque.

Remarques :

• que faire si l’exploitant utilise l’augmentation de la taille du fichier de logs comme indicateur de disponibilité de l’application ? Cette technique de monitoring me semble très discutable sur le fond et je proposerai dans un autre billet d’utiliser des compteurs JMX pour ce besoin. Cependant, si votre exploitant tient absolument à suivre l’augmentation de la taille d’un fichier de logs, je vous propose de l’orienter vers le fichier d’audit décrit plus bas.
• ajouter le nom de l’instance dans le préfixe de chaque message de logs ? Cette technique est parfois utilisée pour agréger les logs provenant de plusieurs serveurs. Cependant, je préfère que le script de collecte reporte le nom d’instance dans le nom des fichiers collectés. Cela consomme moins de disque et, de toutes façons, la fusion de fichiers de logs en conservant la chronologie est très délicate car toutes les lignes de nos fichiers ne sont pas préfixées (stack traces, sauts de ligne dans les message, etc).

Exemple de fichier logback.xml avec un fichier de logs filtré à WARN, à rotation quotidienne et dont les stack traces sont compactées à 2 lignes par cause d’une exception :

<appender name="log-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
   <file>my-application.log</file>
   <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
      <!-- only log problems, not debugging info -->
      <level>WARN</level>
   </filter>
   <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <!-- rotate every day for log collection and archiving -->
      <fileNamePattern>my-application.%d{yyyyMMdd}.log</fileNamePattern>
   </rollingPolicy>
   <encoder>
      <!-- only log 2 lines of stack trace per cause of an exception -->
      <pattern>%d{yyyy/MM/dd HH:mm:ss,SSS} [%thread] %-5level %logger{36} - %m %throwable{2}%n</pattern>
   </encoder>
</appender>

Les logs de diagnostic/troubleshooting

Ce fichier est destiné aux équipes de diagnostic/troubleshooting qui peuvent ajouter ou retirer des informations de debug selon leurs besoins. Ces logs ne sont pas archivées et doivent être très détaillées sans pour autant saturer le système de fichiers.

Ses caractéristiques sont :

• aucun filtrage sur le niveau de log (TRACE, …),
• reconfiguration à chaud du framework de log pour ajouter/supprimer des informations selon les besoins,
• rotation avec écrasement des fichiers pour éviter de saturer le système de fichiers.

Exemple de fichier logback.xml avec un rechargement de la configuration toutes les 30 secondes et un fichier de logs de troubleshooting

<configuration scan="true" scanPeriod="30 seconds">
  ...
   <appender name="troubleshooting-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
      <file>my-application-troubleshooting.log</file>
      <!-- 10x10Mo files to limit size on disk -->
      <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
         <fileNamePattern>my-application-troubleshooting.%i.log</fileNamePattern>
         <maxIndex>10</maxIndex>
      </rollingPolicy>
      <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
         <maxFileSize>10MB</maxFileSize>
      </triggeringPolicy>
      <encoder>
         <pattern>%d{yyyy/MM/dd HH:mm:ss,SSS} [%thread] %-5level %logger{36} - %m%n</pattern>
      </encoder>
   </appender>
</configuration>

Logs d’audit

Ce fichier est destiné à l’audit de sécurité, on y trace « qui a fait quoi à quelle heure », il grossit donc en permanence et peut dépasser le Go chaque jour.

Ses caractéristiques sont :

• seuls les messages d’audit y apparaissent,
• ce fichier tourne chaque jour pour être archivé.

Remarques :

• Certains estiment que le framework de logs n’a pas vocation à gérer les informations d’audit. Bien que je comprenne la théorie, je trouve en pratique bien plus simple de gérer simultanément les deux pour les raisons suivantes:
• l’audit doit tracer toutes les erreurs pour permettre d’analyser les problèmes de sécurité, il faudrait donc tracer les exceptions à la fois dans les logs et dans l’audit,
• les frameworks de logging sont très efficaces pour gérer l’écriture de gros volumes de messages sur disque,
• bien qu’il existe théoriquement un risque qu’une équipe de diagnostic fasse une erreur de configuration et désactive l’audit, je n’ai jamais entendu parler de ce genre de bourde.
• Faut-il augmenter la fréquence de rotation pour prévenir une dégradation des performances lorsque les fichiers d’audit dépassent le Go chaque jour ? Je ne pense pas : j’ai travaillé récemment sur une application Linux RHEL 5 / JVM Hotspot 6 / Tomcat / Log4j qui générait plus d’un Go de logs d’audit chaque jour. L’impact sur les performances était négligeable et l’augmentation de la fréquence de rotation n’a eu aucun impact. En revanche, en cas d’écriture massive sur disque, il faut collaborer avec l’administrateur système pour qu’il vérifie ses configurations OS et disques (c.f. RAID 1) ; les administrateurs sont habitués à ces problèmes avec les fichiers de logs des bases de données.

Exemple de fichier logback.xml avec un fichier d’audit avec rotation quotidienne qui ne traite que les loggers ayant la racine ‘fr.xebia.audit’ :

<appender name="audit-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
   <file>${LOGS_FOLDER}/my-application-audit.log</file>
   <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <!-- rotate every day -->
      <fileNamePattern>/my-application-audit.%d{yyyyMMdd}.log.zip</fileNamePattern>
   </rollingPolicy>
   <encoder>
      <!-- don't output the date or the logger name because the auditing framework handles this -->
      <pattern>%m %throwable{0}%n</pattern>
   </encoder>
</appender>
<!-- route the 'fr.xebia.audit' log messages to the audit-file -->
<logger name="fr.xebia.audit" additivity="false" level="TRACE">
   <appender-ref ref="audit-file" />
</logger>

Un répertoire dédié pour les fichiers de logs archivés

Une fois nos fichiers bien séparés, nous pouvons encore faciliter le travail des équipes d’exploitation avec une astuce très simple : stocker dans un autre répertoire les fichiers qui ont tourné. Il suffit de déclarer un répertoire logs-to-collect à côté de notre répertoire logs. Les bénéfices sont nombreux :

• Le script de collecte des logs (compression et transfert sur un serveur de backup) est grandement simplifié. Il n’est plus nécessaire d’utiliser un astucieux mécanisme de pattern sur le nom des fichiers pour exclure ceux qui sont en cours d’utilisation. Tous les fichiers du répertoires logs-to-collect peuvent être collectés à n’importe quel moment.

• L’équipe de collecte de logs peut conserver autant de fichiers de logs d’archive sur le serveur sans nuire à la lisibilité du répertoire logs en y laissant des centaines d’entrées.

• Il n’y a plus de risques de perdre les fichiers créés dans des circonstances exceptionnelles (opération de diagnostic, etc) et dont le nom ne correspondrait pas aux patterns du script de collecte, il suffit de déplacer ces fichiers dans le répertoire logs-to-collect.

Remarque : seules les logs applicatives et d’audit ont vocation à être reversées dans ce répertoire. Les logs de diagnostic/troubleshooting ne sont pas archivées et restent donc dans le répertoire logs.

Structure de répertoires avec un répertoire logs-to-collect dédié aux fichiers à archiver

Exemple de configuration avec logback

<appender name="log-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
  <file>logs/my-application.log</file>
  <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    <!-- roll every day in a dedicated non-active folder -->
    <fileNamePattern>logs-to-collect/my-application.%d{yyyyMMdd}.log</fileNamePattern>
  </rollingPolicy>
  ...
</appender>

Compresser les fichiers lors de leur rotation

Dernière astuce pour faire plaisir aux équipes d’exploitation en limitant la consommation d’espace disque : nos frameworks de logs savent maintenant compresser les fichiers (zip ou gzip) lors des rotations. Cette compression n’a en général aucun impact sur les performances de nos applications grâce aux CPU multi-cœurs, cela simplifiera encore le script de collecte des logs.

Pour la recherche dans des fichiers compressés, il faut garder en tête zcat et gzcat qui permettent d’extraire simplement les informations utiles.

Exemple de fichier logback.xml avec un fichier d’audit avec rotation quotidienne qui ne traite que les loggers ayant la racine ‘fr.xebia.audit’ :

<appender name="zipped-archive" class="ch.qos.logback.core.rolling.RollingFileAppender">
   ...
   <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <!-- rotate and zip every day -->
      <fileNamePattern>my-log-file.%d{yyyyMMdd}.log.zip</fileNamePattern>
   </rollingPolicy>
   ...
</appender>

Un fichier de configuration de logs prêt pour la production

Voici un fichier de configuration logback.xml prêt pour la production qui reprend toutes les bonnes pratiques de ce billet; il tient en 50 lignes .

<configuration scan="true">
  <property name="LOGS_FOLDER" value="${catalina.base}/logs" />
  <property name="LOGS_TO_COLLECT_FOLDER" value="${catalina.base}/logs-to-collect" />
   <appender name="log-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
      <file>${LOGS_FOLDER}/my-application.log</file>
      <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
         <level>WARN</level>
      </filter>
      <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
         <fileNamePattern>${LOGS_TO_COLLECT_FOLDER}/my-application.%d{yyyyMMdd}.log</fileNamePattern>
      </rollingPolicy>
      <encoder>
         <pattern>%d{yyyy/MM/dd HH:mm:ss,SSS} [%thread] %-5level %logger{36} - %m %throwable{0}%n</pattern>
      </encoder>
   </appender>
   <appender name="audit-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
      <file>${LOGS_FOLDER}/my-application-audit.log</file>
      <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
         <fileNamePattern>${LOGS_TO_COLLECT_FOLDER}/my-application-audit.%d{yyyyMMdd}.log.gzip</fileNamePattern>
      </rollingPolicy>
      <encoder>
         <pattern>%m %throwable{0}%n</pattern>
      </encoder>
   </appender>
   <appender name="troubleshooting-file" class="ch.qos.logback.core.rolling.RollingFileAppender">
      <file>${LOGS_FOLDER}/my-application-troubleshooting.log</file>
      <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
         <fileNamePattern>${LOGS_FOLDER}/my-application-troubleshooting.%i.log</fileNamePattern>
         <maxIndex>10</maxIndex>
      </rollingPolicy>
      <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
         <maxFileSize>10MB</maxFileSize>
      </triggeringPolicy>
      <encoder>
         <pattern>%d{yyyy/MM/dd HH:mm:ss,SSS} [%thread] %-5level %logger{36} - %m%n</pattern>
      </encoder>
   </appender>
   <logger name="fr.xebia.audit" additivity="false" level="TRACE">
      <appender-ref ref="audit-file" />
   </logger>
   <root level="WARN">
      <appender-ref ref="log-file" />
      <appender-ref ref="troubleshooting-file" />
   </root>
</configuration>

Pourquoi je préfère Logback à Log4j

Au delà du comparatif Reasons to prefer logback over log4j que maintient le projet Logback avec un zest de chauvinisme, je trouve que le compactage des stack traces en préservant les causes d’une exception est vraiment différenciant. Je ne vois pas de solution pour le faire avec Log4j sans hacker la librairie. J’ai proposé le patch « Bug 48902 – log4j-extras – Enhancement : add %throwable{compact} to EnhancedPatternLayout » mais la gestion des causes de l’exception n’a pas été intégrée.

Conservation de la cause d’une exception avec Logback et le pattern « %thread %-5level %logger{36} – %msg %throwable{1}%n »

[main] ERROR fr.xebia.test.LoggerTest - Logged by Logback java.lang.RuntimeException: Ze caller
	at fr.xebia.test.LoggerTest.callingMethod(LoggerTest.java:52)
	at fr.xebia.test.LoggerTest.testLogback(LoggerTest.java:38)
Caused by: java.lang.RuntimeException: Ze cause
	at fr.xebia.test.LoggerTest.nestedMethod(LoggerTest.java:45)
	at fr.xebia.test.LoggerTest.callingMethod(LoggerTest.java:50)

Perte de la cause d’une exception avec Log4j et le pattern « %t %5p %c – %m %throwable{3}%n » :

[main] ERROR  fr.xebia.test.LoggerTest - Logged by Log4j java.lang.RuntimeException: Ze caller
	at fr.xebia.test.LoggerTest.callingMethod(LoggerTest.java:52)
	at fr.xebia.test.LoggerTest.testLog4j(LoggerTest.java:28)

J’apprécie aussi le fichier de configuration de test logback-test.xml, l’activation du rafraichissement de la configuration avec scan="true" et bien d’autres détails de Logback qui pourraient faire l’objet d’un prochain billet.

Pour rappel, nous avions laissé notre utilisateur unique avec un temps mirobolant de 1,7 secondes par requête en moyenne.

Le tableau ci dessous montre que la concurrence est nuisible à nos temps de réponse.

La base une ressource critique.

Première amélioration, quasiment gratuite. En allant chercher dans les problèmes que nous avions mis de coté (il y a quelques semaines sur le blog, mais quelques minutes auparavant lors du Xke , nous pouvons exhumer le traçage de la totalité des requêtes SQL dans les fichiers de log. Cette fonctionnalité est bien connue des utilisateurs d’Hibernate (très pratique pour débugger), mais elle se retrouve malheureusement bien trop souvent en production.

<prop key="hibernate.show_sql">false</prop>

Il suffit alors d’une simple modification dans la configuration d’Hibernate, d’un redéploiement, et miracle, les temps s’améliorent déjà un peu.

• hibernate.show_sql à false
• Temps moyen de 8,2 s à 7,6 s pour 5 utilisateurs
• 1 point pour l’équipe qui a trouvé

Après cette correction facile, attaquons nous à plus complexe.

Si la montée en charge induit une augmentation du temps de réponse, c’est que les utilisateurs sont en concurrence sur un certain type de ressource, ou bien qu’ils mettent la machine à genoux. Un rapide coup d’oeil dans VisualVm nous montre que la CPU et la mémoire ne sont pas saturées, on a donc à faire à une contention applicative.

Celles ci peuvent être de deux types :

• une concurrence applicative, mal gérée avec les outils fournis par java.concurrent.util
• une contention sur des ressources externes, comme un pool de connexions JDBC dans une DataSource.

Comme nous étions déjà sur Hibernate dans la correction précédente, continuons à creuser le sillon. Et profitons en pour dégainer un nouvel outil de notre couteau suisse de diagnostic : JMX.
Pour vérifier si nos connexions JDBC sont bloquantes, utilisons l’api de monitoring de Java. Une fois de plus, utilisons notre VisualVm, qui propose une interface graphique d’affichage des MBeans.
Nous sommes chanceux, nos GO ont utilisé la dataSource standard de Tomcat, elle est donc exposée Catalina:type=DataSource,class=javax.sql.DataSource,name="jdbc/petclinicMySQL"

En procédant par sondage rapide (à l’aide de la fonction ‘refresh’ du MBean), on constate rapidement que les valeurs maxActive et numActive se rejoignent autour de la valeur 3. Pas la peine d’en dire beaucoup plus… Comme d’habitude, la documentation va nous confirmer ce que nous pouvions supposer à la lecture de ces valeurs. maxActive nous donne le nombre maximal de connexion JDBC, alors que numActive nous donne celles qui sont utilisées à l’instant t. Ce qui signifie que lorsque les 3 connexions sont prises, les process suivant se mettent en attente, pendant un temps fixé par maxWait soit 3 secondes. Le goulet d’étranglement est évident. Il suffit donc de le fluidifier.

Ce paramétrage se trouve dans la configuration du serveur tomcat, dans le fichier server.xml. Nous allons agir sur deux paramètres : le maxActive, que nous allons positionner à 30 connexions (ce qui est plus que raisonnable) et sur le maxWait afin de ne pas attendre en vain une connexion qui ne viendra jamais.

<GlobalNamingResources>
    <Resource name="jdbc/petclinicMySQL" auth="Container" type="javax.sql.DataSource" driverClassName="org.gjt.mm.mysql.Driver" url="jdbc:mysql://localhost:3306/petclinic_light?autoReconnect=true" username="petclinic" password="petclinic" maxActive="30" maxIdle="10" removeAbandoned="true" removeAbandonedTimeout="60" logAbandoned="true" maxWait="60"/>
</GlobalNamingResources>

Les résultats sont immédiats et nous passons à un temps moyens de 7,2 s :

• Paramétrage de la datasource
• Temps moyen de 7,6 s à 7,2 s pour 5 utilisateurs
• 2 points pour l’équipe qui a trouvé

Ca coince toujours. Où le temps est il consommé ?

Pas la peine d’envisager de passer à plus d’utilisateurs tant que le temps moyen de requête est aussi catastrophique. Si l’on s’intéresse plus en détail aux résultats de JMeter, on constate que la requête Owner detail est la plus consommatrice. Sûrement quelque chose à optimiser de ce côté là.
On ne va pas déroger aux bonnes habitudes prises, on retourne dans VisualVm. Et quand quelque chose coince au niveau applicatif, on réalise un ensemble de ThreadDump. Comme nous sommes avides de nouveauté, nous allons laisser les commandes Unix vi et grep aux dinosaures et utiliser les possibilités de VisualVm, à savoir le plugin Tda.

Pour mettre en évidence notre problème, nous allons tout d’abord restreindre les scenarii JMeter à la seule et unique requête Owner Details. Ensuite, nous allons réaliser une série de ThreadDump très rapproché (de 5 à 10 en quelques secondes). Nous allons ensuite utiliser une des possibilités de TDA, à savoir la détection des Thread longue durée Long Running Thread. TDA va tenter d’identifier les threads ‘bloqués’ dans la même méthode au travers de n ThreadDump.
Comme auparavant, nous ne nous occuperons que des catalina-exec-xx RUNNABLE. Et nous avons de la chance, puisque sur nos cinq utilisateurs, nous trouvons 2 threads bloqués au même point, dans la même méthode (vous l’aurez compris, la détection de thread longue durée est principalement basée sur un ‘coup de sonde’ statistique).

Un petit tour dans le code, dans la classe incriminée.

/**
     <strong> Custom handler for rendering images.
     </strong>
     <strong> @param petId
     </strong>            the ID of the pet whose visits to display
     <strong> @param response to output the image bytes
     </strong> @throws IOException
     */
    @RequestMapping(value = "/owners/*/pets/{petId}/image", method = RequestMethod.GET)
    public void petImageHandler(@PathVariable int petId, HttpServletResponse response) throws IOException {
        int imgId = petId % 6;
        InputStream in = Thread.currentThread().getContextClassLoader().getResourceAsStream("img/pet-" + imgId + ".jpg");
        response.setContentType("image/jpeg");
        OutputStream out = response.getOutputStream();
        IoUtils.copy(in, out);
        clean();
    }

A priori, rien de très suspect dans la façon de servir des images stockées côté serveur (le but de l’exercice n’étant pas d’éliminer le problème, en changeant le comportement de l’application et en déplaçant ces images côté apache).
Si on revient à nos ThreadDump, nous constatons que nous pouvons encore descendre dans le code, à l’intérieur de la classe IoUtils.

    public static void copy(InputStream in, OutputStream out) throws IOException {
        OutputStream bufferedOutputStream = new BufferedOutputStream(out);
        byte[] buffer = new byte[512];
        int length;
        while ((length = in.read(buffer)) >= 0) {
            bufferedOutputStream.write(buffer, 0, length);
        }
        bufferedOutputStream.close();
    }

A priori, si les copies d’InputStream / Outputstream étaient à ce point sous performantes, cela se saurait. Mais ne mésestimons pas la fourberie de nos poseurs de bombes.

En y regardant de plus près, on constate en effet que nous avons une belle implémentation maison de la méthode write, inspirée de celle du ByteArrayOutputstream.

public synchronized void write(int b) {
            int newcount = count + 1;
            if (newcount > buf.length) {
                buf = Arrays.copyOf(buf, (buf.length << 1) / 2 + 3);
            }
            buf[count] = (byte) b;
            count = newcount;
        }

Et là où le ByteArrayOutputstream se redimensionne de manière intelligente pour accélérer la copie

    public synchronized void write(int b) {
	int newcount = count + 1;
	if (newcount > buf.length) {
            buf = Arrays.copyOf(buf, Math.max(buf.length << 1, newcount));
	}
	buf[count] = (byte)b;
	count = newcount;
    }

, l’implémentation maison reste définitivement bloquée et recopie les octets 2 à 2…

Si nous remplaçons cette implémentation par java.io.BufferedOutputstream, nous devrions avoir de bien meilleurs résultats.

Et en effet cette fois, c’est spectaculaire. Pour nos cinq utilisateurs, nous passons à un temps moyen de 1,4 s avec une très remarquée dégringolade du temps moyen de ownersDetail qui passe de 32 s à 3,7 s.

• Suppression d’un java.io maison
• Temps moyen de 7,2 s à 1,4 s pour 5 utilisateurs
• 3 points pour l’équipe qui a trouvé

Il va bientôt être temps de passer à un nombre d’utilisateurs « raisonnable ».

Cette soirée gratuite vous permettra d’appréhender les bonnes pratiques que se doivent de respecter les Directions Etudes et Développement pour rendre leurs applications Java/J2EE prêtes pour la production.

Elle se déroulera dans les locaux de Xebia : 156, boulevard Haussmann, 75008 Paris.
Les inscriptions peuvent se faire :

• Par mail : info@xebia-training.fr
• Par téléphone : 01.53.89.99.93
• En ligne sur le site de Xebia Training

Les technologies Java ont été massivement adoptées par les DSI pour la réalisation de leurs applications critiques. Porteuses de valeur et d’innovation, elles posent régulièrement problème au niveau des départements Exploitation/Production. Instabilité chronique, manque de capacité à monter en charge, difficultés de diagnostiques en cas de dysfonctionnement, déploiement chaotique sont autant de maux fréquemment rencontrés par les entreprises utilisatrices.

Les bonnes pratiques que se doivent de respecter les Directions Etudes et Développement pour rendre leurs applications Java/J2EE prêtes pour la production s’articulent autour des axes suivants :

Les bonnes pratiques pour le déploiement

Le déploiement est le baptême du feu d’une application en production. Comment réussir cette épreuve ?

• Complexité des composants à déployer : simplicité rime avec fiabilité,
• Les paramètres de configuration : éviter l’anarchie,
• Traçabilité et build automatisés : maitriser sa plateforme.

Les bonnes pratiques de robustesse

Dans l’adversité, une application robuste assure un service minimum plutôt que de s’arrêter :

• Dépendances inter-application : fail fast est il synonyme de fragilité ?
• Prévention des saturations et des effets “domino” : l’art du code défensif,
• Modes dégradés : les négociation technico-fonctionnelles.

Les bonnes pratiques pour la supervision et le monitoring

Une application en production doit exposer son état aux équipes d’exploitation et faciliter la détection de problèmes :

• Indicateurs de bon fonctionnement d’une application : ne pas se noyer dans les chiffre,
• Comment exposer les indicateurs de performances ? Fichier de log versus page JSP versus Java Management eXtension (JMX) ?

Les bonnes pratiques de log

Grande source d’incompréhension entre les départements études et exploitation, les logs d’application Java ? Quels formats de messages ?

• Codes erreurs chers aux exploitants, exceptions chainées et stacktraces familières aux développeurs, quel compromis ?
• Des logs de troubleshooting extrêmement verbeuses aux logs d’audit sécurité à conserver plus d’un an en passant par celles de perfs et celles de diagnostique, comment organiser les logs ?

Les bonnes pratiques organisationnelles

Avoir une application prête pour la production ne se limite pas à des bonnes pratiques techniques, la collaboration des départements études et exploitation est essentielle :

• Prendre en considération les réalités de production dans les développements : une amélioration continue,
• Les incidents : comment s’y préparer pour qu’ils ne se transforment pas en longues indisponibilité.

BONUS

Les bonnes pratiques de robustesse

• Les mécanismes de ré-essai

Plus d’excuse pour ne pas l’essayer : la nouvelle version de Deployit, solution d’automatisation des déploiements J2EE vient de sortir. Les deux principales nouveautés sont :

• le support du serveur Tomcat : déploiement des archives de type WAR directement ou à travers l’application Manager et la création des DataSources JDBC dans le context.
• l’exécution de scripts SQL lors du déploiement.

Les autres serveurs d’application n’ont pas été oubliés.

• Oracle Weblogic : gestion plus complète des services JMS
• IBM WebSphere : support indifférent d’Apache ou d’IHS, possibilité d’indiquer l’ordre de chargement pour les EAR et WAR, des déploiements accélérés en gardant ouverte la connexion vers wsadmin

et coté système d’exploitation, support du protocole telnet/smb pour les machines de type Windows.

Retrouvez toutes ces nouvelles fonctionnalités dans Deployit Personal Edition. Cette version gratuite possède toutes les fonctionnalités de la version Enterprise, exception faite des aspects sécurité. Elle inclut une licence permettant à un utilisateur unique et identifié d’utiliser l’outil, sans limitations. Deployit Personal Edition inclut en standard des plugins pour Tomcat, IBM WebSphere AS, Oracle WebLogic Server et JBoss AS. Cette version peut être téléchargée gratuitement avec sa documentation et des tutoriels permettant de comprendre son fonctionnement. Cliquer sur le lien suivant : http://www.xebialabs.com/deployit-personal-edition-request.

• Le catalogue numérique.
• Le catalogue PDF.

Xebia Training se positionne logiquement dans la continuité de Xebia, tant sur la qualité de son offre de formation technique que méthodologique (méthodes agiles), en proposant des formations haut de gamme animées uniquement par les référents de leur domaine.

Avec pour principe premier le refus de tout compromis sur la qualité du formateur et du contenu, Xebia Training fait systématiquement intervenir des acteurs de références dans leurs domaines respectifs.

Nos formations, savant équilibre entre théorie et travaux pratiques, sont destinées à un large public soucieux d’acquérir les meilleures pratiques de notre industrie.

Après une première passe qui nous a permis de calibrer les logs de manière un peu plus pertinente, il est temps, toujours sans l’aide du code source, de mettre les mains sous le capot de Tomcat (6.0.20).

Et pour cela, rien de mieux que de jeter de nouveau un œil à notre VisualVm.

Tant de threads pour un seul utilisateur.

Pour (re)commencer, penchons nous sur nos threads, juste après le démarrage du serveur (et donc avant la première connexion d’un utilisateur)

Lorsque l’on démarre un serveur Tomcat, un certain nombre de threads sont affectés à sa ‘tuyauterie’ interne (connecteurs RMI, JMX). Mais de là à avoir 165 threads, il y a certainement un souci quelque part !
Creusons un peu, et entrons dans le détail de ces threads en utilisant l’onglet Threads.

Hormis les threads ‘connecteurs’ de Tomcat, on voit apparaître 150 threads catalina-exec. Ces threads sont en charge des traitements des requêtes HTTP, via le HTTP-8080-acceptor. Nous avons donc, « à froid » 150 unités d’œuvre prêtes à traiter nos requêtes. Sachant que pour l’instant nos tests se limitent à un utilisateur, on sent que nous sommes très légèrement surarmés par rapport à nos besoins.
Tomcat ne devrait-il pas gérer automatiquement ces problématiques de montée ou descente en charge ?
Allons faire un petit tour dans la documentation, du côté du connecteur HTTP.

Si nous recherchons le paramètre minSpareThreads dans nos fichiers de configuration, nous le trouvons dans server.xml. Repassons le à une valeur plus réaliste de 10 threads, sachant que Tomcat montera automatiquement en charge si besoin.
Cela n’a pas d’impact visible sur les performances, mais au moins, les ThreadDumps deviennent lisibles (obfusquer les ThreadDumps était le but recherché de ce paramétrage).
Autre paramètre qui a interpellé les connaisseurs de Tomcat, la classe de l’Executor. org.apache.catalina.core.extended.PrestartingThreadExecutor n’est pas une classe courante. D’habitude, on utilise plutôt le StandardThreadExecutor. Une fois encore, on peut remercier nos buggers en chef : PrestartingThreadExecutor est une classe custom, qui démarre automatiquement tous les threads HTTP. De nouveau, l’impact sur les performances est négligeable pour un utilisateur, mais mieux vaut laisser Tomcat gérer toutes les problématiques de vie du serveur d’application. Sans vouloir leur faire offense, nos maîtres de cérémonie n’ont pas le niveau des équipes Apache rodées à l’exercice depuis de très nombreuses années
Dernier paramètre « malin » introduit au niveau de Tomcat, le paramètre -Xss. Celui-ci peut être découvert via l’overview de VisualVm. -Xmx, -Xms sont des paramètres classiques (nous reviendrons dessus) que grand nombre de développeurs connaissent. Mais -Xss ? Comme d’habitude, notre meilleure arme est la documentation de Sun.

-Xssn
    Set thread stack size.

Avons nous réellement besoin d’une taille de stack de 1024 Ko ? Difficile à dire, surtout a priori. Mais une fois encore, le plus simple est de faire confiance à Tomcat, quitte à devoir intervenir a posteriori. Nous ne sommes plus à un redémarrage près.

Maintenant que notre application est déployée et paramétrée de manière à peu près correcte, il est temps de rentrer « dans le dur » : mettre les mains dans le cambouis et explorer le code source.

Fuite mémoire, threads dump, ça explose de tous les côtés.

Dès que nous avons eu le code source entre les mains, plusieurs stratégies se sont dégagées :

• la première consiste à conserver un seul utilisateur dans les scripts JMeter et à le pousser à faire plus d’itérations,
• la seconde consiste à mettre plus d’utilisateurs JMeter en parallèle.

Toujours dans le but de rester très didactique, nous allons appliquer la première stratégie. Qui trouve rapidement sa limite :

Aux environs de la 70ème itération, la heap used tangente la heap max, le Garbage Collector est déclenché plusieurs dizaines de fois par seconde de manière totalement inefficace, et la JVM finit par faire un joli OutOfMemory. Les symptômes classiques de la fuite mémoire.

Comment faire pour la trouver ?
C’est à la fois simple et complexe : depuis la JVM 6, il est très facile, grâce à VisualVm de réaliser des « photographies » exhaustives de la mémoire de la JVM, les célèbres heap dumps. Malheureusement, ce n’est possible que sur les JVM locales.
Conformons nous donc à l’énoncé et n’installons pas notre Tomcat en local. La solution consiste à utiliser la commande jmap.
Commençons par générer un histogramme, que nous allons filtrer.
jmap -histo <pid_jvm> | grep org.spring
Notre premier candidat arrive en 16ème position dans l’histogramme :
16: 14000 560000 org.springframework.samples.petclinic.Vet
14 000 vétérinaires, voilà qui est surprenant… De là à dire que notre fuite tourne autour de cet objet métier, il n’y a qu’un pas. Malheureusement, à part en allant dans le code à la pioche, il va être difficile de colmater la fuite avec aussi peu d’information. De nouveau, jmap va nous rendre service, cette fois en générant un heap dump.
jmap -dump:format=b,file=/tmp/dump.hprof <pid_jvm>
Pour exploiter ce dump, nous avons choisi d’utiliser l’outil Eclipse Mat. Dès l’ouverture, Mat nous propose de rechercher les leak suspects
Et là, le diagnostic est assez évident.

Un type d’objet monopolise à lui seul 92 % de la mémoire. Il ne reste plus qu’à creuser dans le heap dump pour déceler l’allocation coupable.
Passons donc à la vue dominator tree. En dépliant progressivement la pile mémoire (en cliquant sur l’objet qui a la plus grande retained heap), on constate que la mémoire est occupée par de très nombreuses occurences de org.springframework.samples.petclinic.util.CacheFilter$CacheEntry

Maintenant que nous avons un coupable, il est temps, pour la première fois, d’ouvrir notre code source sous Eclipse. En faisant une simple recherche de classe sur notre coupable désigné, nous arrivons au code suivant :

HttpSession session = request.getSession();
Map<String, CacheEntry> cache = (Map<String, CacheEntry>) session.getAttribute("pages.cache");
if (cache == null){
    cache = new Hashtable<String, CacheEntry>();
    session.setAttribute("pages.cache", cache);
}
...
//Return cached content if available
String path = context.getRealPath("") + request.getRequestURI() + request.getQueryString();
CacheEntry cacheEntry = cache.get(path);
if (cacheEntry != null) {
    response.setContentType(cacheEntry.t);
} else {
    //Else, fetch it
    cacheEntry = new CacheEntry();
    CacheResponseWrapper wrapper = new CacheResponseWrapper(response);
    chain.doFilter(request, wrapper);
    byte[] buf = cacheEntry.buf;
    InputStream in = wrapper.getContentAsInputStream();
    OutputStream out = cacheEntry.c;
    int length;
    while((length = in.read(buf)) >= 0) {
        out.write(buf, 0, length);
    }
cacheEntry.t = wrapper.getContentType();
cache.put(path, cacheEntry);
}

Chaque page est donc mise en cache dans la session de l’utilisateur. Le timeout du cache étant fixé à l’infini, on voit de manière assez évidente que chaque fois que notre JMeter lance une campagne de test, il ouvre une nouvelle Session dans laquelle l’ensemble des pages vues est gardée en mémoire (avec un taux de réutilisation proche de zéro).
L’utilisation des ressources mémoire de notre JVM est ici particulièrement mauvaise.
Deux solutions sont envisageables :

• basculer le cache dans un scope application. Mais dans ce cas, attention, la taille de celui-ci peut vite exploser et l’utilisation d’un filtre qui cache systématiquement tout le contenu de la réponse peut rapidement échapper à tout contrôle.
• supprimer purement et simplement ce cache dont le taux de hit est ridiculement bas. C’est la solution que nous choisirons ici, car c’est la plus économique (une ligne à commenter dans le web.xml).

Cette correction ne devrait toutefois pas affecter notre nombre élevé de Vets trouvés via l’histogramme… Nous y reviendrons probablement.

Ne reste alors plus qu’à re-construire (via Maven) et relivrer l’application pour voir le résultat.

Cette fois, le gain de performance ne se mesure pas directement dans JMeter. Les temps de réponse de l’application sont sensiblement identiques à ce qu’ils étaient avant nos interventions.

En revanche, nous avons largement gagné en performance dans deux domaines :

• le plus immédiat, celui du ressenti utilisateur : plus la peine de rebooter notre serveur tous les 70 scenarii, et ça toutes les équipes d’exploitation vous le diront (sauf les mauvais élèves qui ont bêtement automatisé leurs redémarrages), c’est un énorme gain.
• celui plus égoïste, d’avoir des traces propres et peu nombreuses, donc beaucoup plus exploitables.

Pour finir, les points attribués :

• Fuite mémoire de CacheFilter en session
• Passage de la barre des 70 scenarii pour 1 utilisateur
• 2 points pour l’équipe qui a trouvé

Comme l’a très bien pressenti l’un de nos lecteurs (voir les commentaires sur l’article précédent), nous ne sommes pas encore au bout de nos surprises

Cette version est gratuite et possède toutes les fonctionnalités de la version Enterprise, exception faite des aspects sécurité. Elle inclut une licence permettant à un utilisateur unique et identifié d’utiliser l’outil, sans limitations. Deployit Personal Edition inclut en standard des plugins pour IBM WebSphere AS, Oracle WebLogic Server et JBoss AS. Cette version peut être téléchargée gratuitement avec sa documentation et des tutoriels permettant de comprendre son fonctionnement.

Par ailleurs, avec Deployit Personal Edition, vous avez tout à disposition pour développer vos propres plugins : la documentation de l’API de plugin, les tutoriels et le code source des plugins existants. Enfin, en plus du support technique fourni via le web, notre équipe support peut être contactée gratuitement pendant 90 jours !

Si Deployit Personal Edition permet de bénéficier des avantages de Deployit (y compris en Production), il conviendra d’opter pour la version Enterprise incluant ses fonctionnalités de sécurité, son support technique complet et sa licence multi-utilisateurs dans le cadre d’un environnement plus complexe d’Entreprise.

Deployit Personal Edition peut être obtenue en cliquant sur le lien suivant : http://www.xebialabs.com/deployit-personal-edition-request.

Un peu d’histoire

Tout commence en 1997 avec la création d’Apache JServ. A l’époque, il s’agit d’un serveur de Servlet qui supporte uniquement le protocole AJP créé pour l’occasion. Dans l’architecture initiale, c’est Apache 1.1 qui fournit le serveur web et transfère les requêtes par socket au moteur de Servlet. C’est la naissance du protocole AJP dans sa première version implémentée par le mod_jserv. L’Apache JServ Protocol fonctionne au départ comme un proxy qui redirige le flux vers JServ. Le protocole est en texte clair et utilise un caractère en début de ligne pour distinguer les différents éléments de la requête.

Rapidement, le protocole initial est considéré comme trop limité car il fonctionne uniquement en loopback et possède une authentification pauvre. En 1998, le protocole AJP 1.1 permet à JServ de tourner sur une autre machine que le serveur web et d’assurer une authentification forte basée sur md5. Avec le développement de JServ appparaît un problème de performance important : le coût d’ouverture d’une socket et la vitesse des réseaux. Ils sont considérés à l’époque comme les principaux goulets d’étranglement. Pour résoudre ces problèmes, le protocole passe à la version 1.2 dont vous trouverez le draft initial ici. AJP 1.2 est un protocole binaire orienté paquets qui permet de recycler la ou les sockets connectées à JServ. Le passage au binaire permet aussi d’améliorer les performances car il diminue la taille des données qui transitent et simplifie le traitement.

En 1999, Sun offre son implémentation de référence des Servlets à la fondation Apache. C’est le point de départ des projets Tomcat et Ant. Commence alors une période de transition qui finira par l’abandon d’Apache JServ. Pendant cette transition, AJP sera porté sur Tomcat qui bénéficiera d’emblée d’une facilité d’interconnexion avec Apache. Aux alentours de 2000, le mod_jk est développé pour étendre AJP qui pourra supporter le transport des données SSL. C’est la version 1.3 que l’on retrouve aujourd’hui supportée par les dernières générations de Tomcat. Après toutes ces années de développement, le mod_jk est maintenu par le projet Tomcat Connectors et n’a jamais été intégré aux projets Apache.

La création d’AJP résulte donc de la simplicité et de la rapidité de développement souhaitées par les auteurs. Il fallait aller vite, et implémenter un proxy pleinement compatible HTTP aurait été trop long. Le module mod_proxy existe depuis 1996 dans Apache 1.1. Mais il s’agissait d’une fonctionnalité expérimentale qui n’offrait ni performance ni stabilité. A la sortie d’Apache 2, le proxy a même été dé-scopé car il ne fonctionnait plus du tout. Les développeurs vont pourtant rapidement le corriger et le réintégrer comme solution pour faire des reverse proxies. Pour la sortie d’Apache 2.2, le mod_proxy est entièrement réécrit pour supporter le load-balancing. Il offre, pour la première fois dans Apache, une solution capable de concurrencer le mod_jk en performance et en scalabilité. Cerise sur le gâteau, Apache a décidé de supporter nativement le protocole AJP en ajoutant un mod_proxy_ajp à la solution mod_proxy.

Installation

mod_proxy

Le mod_proxy fait partie de la distribution standard d’Apache HTTPD. Il est livré avec le mod_proxy_http, le mod_proxy_ajp et le mod_proxy_balancer. Il suffit donc de s’assurer que ces modules sont bien chargés au démarrage d’Apache.

mod_jk

Si mod_jk était autrefois très délicat à installer avec la compilation du code sur un serveur similaire au serveur cible, la situation s’est grandement simplifiée. Le projet Apache Tomcat Connector fournit désormais les binaires pour les principales plateformes (Linux, Windows, Free BSD, Mac, Solaris, AIX, etc). Il faut donc télécharger le binaire du module et le copier dans le répertoire contenant les modules Apache.

Configuration

Pour mieux comparer les deux solutions, nous avons choisi de prendre comme exemple l’utilisation d’Apache en front desservant deux Tomcat en load-balancing. Nous ne nous intéresserons ici qu’à la configuration d’Apache HTTPD. La configuration AJP de Tomcat étant déjà largement documentée sur le web et celle via HTTP dans nos articles précédents, nous n’aborderons pas ces problématiques.

mod_proxy_http & mod_proxy_balancer

La configuration du mod_proxy consiste d’abord à s’assurer que les modules soient bien chargés avec les directives LoadModule. Nous activons ensuite le server-status ainsi que le balancer-manager pour obtenir une interface de surveillance / administration du load-balancer. Enfin, nous avons configuré le Proxy balancer nommé my-application-cluster pour contenir nos 2 serveurs Tomcat. La dernière ligne de configuration active le reverse proxy pour que les requêtes sur /my-application soient redirigées vers le /my-application du load-balancer.

Configuration avec mod_proxy_http & mod_proxy_balancer – httpd.conf

# LOAD MODULES
LoadModule proxy_module libexec/apache2/mod_proxy.so
LoadModule proxy_http_module libexec/apache2/mod_proxy_http.so
LoadModule proxy_balancer_module libexec/apache2/mod_proxy_balancer.so
# STATUS AND MONITORING
# Display proxy balancer status in /server-status page
ProxyStatus On
<Location /server-status>
    SetHandler server-info
    Order deny,allow
    Deny from all
    Allow from localhost
</Location>
<Location /balancer-manager>
    SetHandler balancer-manager
    Order Deny,Allow
    Deny from all
    Allow from localhost
</Location>
# APPLICATIONS CONFIGURATION
<Proxy balancer://my-application-cluster>
   BalancerMember      http://node-1:8080 route=node-1 disablereuse=On
   # ...
   BalancerMember      http://node-n:8081 route=node-n disablereuse=On
</Proxy>
ProxyPreserveHost On
ProxyPass /my-application balancer://my-application-cluster/my-application stickysession=JSESSIONID

Vous pouvez le constater, la configuration est parfaitement intégrée à la configuration standard d’Apache HTTPD. Les équipes de production n’auront à priori pas de grandes difficultés à prendre en main ce type de configuration qui nécessite seulement de savoir parcourir la documentation Apache déjà bien connue des administrateurs.

mod_jk

La première étape consiste à configurer le serveur Apache pour qu’il utilise le mod_jk. Tout commence par le chargement du module avec la directive LoadModule. Ensuite nous fournissons le chemin du deuxième fichier de configuration définissant les workers. La directive JkMount permet ensuite d’associer un worker du mod_jk à un pattern d’url du serveur. Pour chaque requête dont l’URL correspond au pattern, Apache va déléguer le traitement au mod_jk. Nous montons d’abord le worker jkstatus sur /jkmanager en autorisant l’accès uniquement depuis le système local. C’est ensuite au tour du loadbalancer qui servira notre application.

Configuration avec mod_jk – httpd.conf

# LOAD MODULES
LoadModule jk_module libexec/apache2/mod_jk.so
# MOD_JK CONFIGURATION FILE
JkWorkersFile /etc/apache2/other/workers.properties
# MOD_JK PROPRIETARY LOG FILE
JkLogFile     /var/log/apache2/mod_jk.log
# NEEDED ON MAC SNOW LEOPARD
JkShmFile     /var/log/apache2/
# STATUS AND MONITORING
JkMount /jkmanager/* jkstatus
<Location /jkmanager>
    Order deny,allow
    Deny from all
    Allow from localhost
</Location>
# APPLICATIONS CONFIGURATION
JkMount /my-application/* loadbalancer

Il faut maintenant configurer le mod_jk proprement dit dans son fichier de configuration spécifique. Il s’agit d’une liste de propriétés commençant toujours par worker.. La propriété worker.list fournit les noms des workers actifs. Le nom est ensuite utilisé pour paramétrer le worker avec des clés de la forme worker.nomWorker.parametre. Le premier worker activé jkstatus utilise le type spécial status qui correspond à l’interface de suivi et de gestion du mod_jk. Le deuxième worker loadbalancer est en fait chargé de répartir les sessions entre le worker1 et le worker2 via le type lb. Ce sont finalement les workers 1 à n qui assurent le transport des requêtes sur AJP1.3 vers le port 8009 d’un Tomcat distant.
Configuration avec mod_jk – workers.properties

# WORKERS AND PSEUDO WORKER
worker.list=jkstatus, loadbalancer
# STATUS AND MANAGEMENT PSEUDO WORKER
worker.jkstatus.type=status
# WORKER 1 TO N
worker.worker1.type=ajp13
worker.worker1.host=node-1
worker.worker1.port=8009
# ...
worker.worker2.port=8009
worker.worker2.host=node-n
worker.worker2.type=ajp13
# LOAD BALANCER PSEUDO WORKER
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=worker1,worker2

Avec ses deux fichiers de configurations séparés et la syntaxe « rustique » du worker.properties, la configuration est définitivement le point faible du mod_jk. L’un des seuls avantages réside dans le nombre impressionnant de paramètres supportés qui permet un paramétrage fin si le besoin s’en fait sentir. Si seulement nous n’étions pas forcés à tant de verbosité !

Interfaces graphiques

Les deux modules fournissent des interfaces web pour assurer la supervision du load-balancer. Cette fois, le mod_proxy se contente de fournir des statistiques réduites dans une interface minimaliste. L’interface liste principalement le statut de chaque nœud du load-balancer ainsi que la quantité de données envoyée et reçue par nœud.

Outre le suivi des statistiques du load-balancer, le Balancer Manager permet aussi de faire des modifications à chaud, éditer les workers, les passer en offline, voire même changer la méthode de répartition utilisée.

De son côté, le mod_jk prouve sa maturité avec son interface rustique elle aussi, mais plus voire trop complète. Elle est composée de plusieurs pages dont une page d’accueil similaire en tout point à l’interface du mod_proxy. L’avantage réside dans la fourniture d’une page détaillant l’état complet pour chaque nœud.

Mais le mod_jk ne se contente pas de cela : il fournit aussi une page permettant de modifier à chaud la configuration du load-balancer. Il est parfaitement envisageable pour le déploiement en production d’une nouvelle version de l’application de couper les nœuds un à un au moment de leur mise à jour puis de les réactiver sans interruption du service.

Attention toutefois, car les modifications faites par ce biais sont uniquement enregistrées en mémoire, la nouvelle configuration sera perdue au prochain redémarrage d’Apache.

La mince différence vient probablement de la jeunesse de la solution de load-balancing du mod_proxy face à la longue expérience de production du mod_jk. Mais elle ne saurait justifier une préférence pour l’un des deux modules, qui sur ce point sont très proches.

LoadBalancing et gestion d’erreur

Outre la configuration et l’interface graphique, les deux solutions disposent de quelques fonctions avancées notamment en ce qui concerne la gestion d’erreur et la gestion des sockets réseaux. Les deux modules utilisent des pools de connexion rangés par Thread du serveur Apache et par membres du cluster.
Avec le mod_proxy, il est possible de choisir parmi trois algorithmes de répartition de charge :

• Par requête : la charge est répartie pour chaque requête entrante en fonction de la session si elle existe.
• Par trafic réseau : les requêtes sont envoyées vers le membre du cluster ayant reçu le moins de trafic.
• Par taux d’occupation : la charge est répartie en fonction du nombre de requêtes en cours de traitement ou en attente.

En ce qui concerne la gestion d’erreur, il n’y a pas grand chose à dire car il n’y a pas grand chose de fait. Si un timeout claque, un certain nombre de tentatives de reconnexion seront réalisées jusqu’à ce que le noeud soit marqué en erreur et n’en décolle plus.

C’est sur la gestion d’erreur que le mod_jk possède une plus grande sophistication que son récent concurrent.
Tout d’abord le protocole AJP fournit un mécanisme de health check (CPing/CPong) qui permet de tester l’état du lien entre le serveur frontal et un membre du cluster. Cependant, c’est beaucoup plus limité que les heart beat des load balancer hardware, il n’est pas possible de tester une url pour détecter des indisponibilités applicatives (échec de démarrage de la web app, web app KO à cause de l’indisponibilité d’un backend clef).
D’autre part, le module fait une distinction entre les erreurs locales temporaires qui sont sans impact particulier, un code d’erreur HTTP par exemple, et les erreurs globales qui indiquent que le serveur est clairement en erreur et ne recevra plus de nouvelles requêtes. Il existe un système d’escalade qui, en cas de répétition trop fréquente d’erreurs locales sur un noeud se charge de le passer en erreur globale. Le module se charge de réactiver le noeud en mode recovery après un délai paramétré.

Côté répartition de charge, mod_jk apporte un dernier algorithme de répartition reposant sur le nombre de sessions HTTP en cours par serveur. Cette méthode est relativement récente puisqu’elle est apparue dans la version 1.2.20 du mod_jk, actuellement en version 1.2.29. Elle est recommandée pour les applications chargeant fortement la session et de ce fait, supportant un nombre limité de sessions par serveur ; ce cas d’utilisation est assez marginal.
Dans les deux modules, l’algorithme de répartition est pondéré par un facteur nommé « lbfactor », qui permet d’appliquer des quotas de travail aux serveurs. Ce système s’avère utile si les serveurs sont de puissances différentes par exemple.

Le mod_jk marque ici un petit point sur le mod_proxy grâce à sa gestion d’erreur plus fine. Attention aux effets de bord, le retry sur timeout en a surpris plus d’un et l’éviction de serveurs tomcat pour cause de répétition d’erreur est un beau sujet de déni de service

Pour le reste, le mod_proxy colle au fonctionnement du mod_jk, ce qui ne manquera pas de faciliter son utilisation aux habitués du mod_jk.

Exploitation et diagnostic des problèmes

mod_proxy_http présente sur mod_jk le très grand avantage d’utiliser un protocole standard, HTTP, connu de tous les acteurs d’un système d’information alors que mod_jk repose sur le protocole AJP que quasiment personne ne connait. Les administrateurs systèmes et réseaux sont habitués à HTTP et notamment à ses connections persistantes (aka HTTP keepAlive) ; ils savent ajuster leurs algorithmes de load balancing, les timeouts des firewalls et le dimensionnement des piles tcp/ip des serveurs (ulimit, tcp_keepalive_intvl, tcp_tw_bucket, etc).

Un autre atout de mod_proxy est la facilité de diagnostic. N’importe quel acteur du système d’information peut utiliser curl, wget, telnet, elinks voire wireshark pour troubleshooter un problème de communication HTTP; ce n’est pas le cas avec le protocole AJP qui n’est pas human readable et encore moins human writable. Choisir AJP mérite de former les administrateurs systèmes et réseaux et de prévoir des outils de tests permettant de requêter un connecteur AJP mais ce n’est hélas que très rarement fait.

En cas de problème réseau avec HTTP comme avec AJP, n’oubliez pas que désactiver les connections persistantes simplifie grandement les investigations et n’a rien de scandaleux en 2010 (cf HAProxy) ; c’est « disablereuse=On » pour mod_proxy_http et « JkOptions +DisableReuse » pour mod_jk

Conclusion

Avec sa simplicité de configuration, sa répartition de charge calquée sur le mod_jk, le mod_proxy conviendra parfaitement dans la grande majorité des cas. Il s’accommode de clusters répartissant la charge sur plusieurs noeuds ou bien en tant que simple reverse proxy. La cerise sur le gateau étant l’utilisation du protocole HTTP qui permet de garantir la portabilité des services et facilite grandement l’analyse du trafic.

A nos yeux, avec l’intégration native de mod_proxy_http et mod_proxy_balancer à Apache, il n’y a plus de justification à ajouter le module additionnel mod_jk ni d’introduire le protocole méconnu AJP. Les optimisations d’AJP ne sont plus de mise aujourd’hui et ne justifient donc pas l’utilisation d’un mod_jk.

Il reste, dans les deux cas, quelques efforts à faire pour permettre de plus facilement monter des serveurs à chaud dans un cluster. Pour la haute disponibilité sans perte, il faudra mettre en place un cluster Tomcat assurant la réplication des sessions utilisateur entre les serveurs. Encore faut-il en avoir vraiment besoin …

Attention, la recommandation de Tomcat est encore le mod_jk et, il est important de garder fonctionnel ce qui marche déjà. Donc, quoiqu’il arrive, si vous avez déjà une solution fonctionnelle avec le mod_jk, inutile de migrer. Pour ce qui est de l’interface et de la gestion d’erreur, nous parions sur l’avenir du mod_proxy qui est en développement intensif et bénéficie des corrections de bug de son ainé. Reste un nouveau venu dans le paysage développé par Jboss qui attire déjà notre attention c’est le mod_cluster actuellement, il n’est utilisable qu’avec Jboss AS. L’avantage de cette nouvelle solution en devenir est de suivre le cycle de vie des applications via un protocole spécifique MCMP reposant tout de même sur HTTP.

Chez XebiaLabs, nous nous y connaissons en déploiement automatique d’applications Java EE. L’une des choses les plus surprenantes réside dans le fait que «les fournisseurs de serveurs d’application ne semblent pas faire partie des personnes qui maitrisent le mieux le déploiement d’applications».

Dans un article précédent, nous avons décrit ce que nous considérons comme le déploiement d’application J2EE global. Et force est de constater que:

• Déployer va bien au delà d’un simple déploiement d’un EAR ou d’un WAR.
• La plupart des applications ont également besoin d’autres artéfacts comme par exemple du contenu statique pour le serveur web ou encore des fichiers de configuration, utilisés par le code java, au démarrage.
• Il faut également configurer des ressources JEE comme des Datasources JDBC ou des composants JMS (Queues, Topics, Servers).
• A ceci s’ajoute, bien entendu, la configuration du middleware lui-même: création et configuration de clusters de serveurs d’application ou de virtual hosts d’un serveur Apache.
• L’ordre d’exécution des tâches est important afin de réduire (voire de prévenir) la coupure de service de l’application pendant le déploiement et d’en augmenter la vitesse.

Alors posons nous la question. Que nous proposent les fournisseurs de serveurs d’application dans ce domaine ?

Oracle WebLogic Server

Oracle WebLogic Server propose un concept de ‘Deployment’: c’est la chose que vous créez quand vous déployez un EAR, un WAR ou un EJB Jar. Sic ! Vous pouvez l’adapter à l’environnement en fournissant un plan de déploiement. Cependant, rien n’est proposé pour regrouper plusieurs artéfacts JEE dans un seul déploiement ou inclure la création de ressources JEE telle qu’une Datasource.

Dans WebLogic, il y a le concept de ‘SubDeployement’ mais étrangement il n’est pas corrélé à un déploiement. C’est un mécanisme utilisé pour cibler des parties d’un module JMS vers des serveurs JMS ou des serveurs WebLogic. L’artifice proposé par les modules JMS semble destiné seulement à regrouper des ressources JMS. Sans doute qu’un jour un développeur l’a initialement appelé Déploiement sans se souvenir que le concept existait déjà dans WebLogic et il l’a alors renommé SubDeployement. Bien sûr, tout ceci n’est que supputation!

WebLogic propose un grand nombre d’API pour le déploiement: l’historique weblogic.Deployer en ligne de commande, la tâche ANT wldeploy et le WebLogic Scripting Tools, WLST pour les intimes, basé sur Python. Ce dernier est, je pense, le plus complet. Grâce à sa représentation sous forme de système de fichier de la hiérarchie des MBeans, il fournit un moyen très intuitif d’accéder à l’information.

JBoss Application Server

Le déploiement dans JBoss est géré par le Virtual Deployment Framework. C’est un framework basé sur des MBeans qui permet à différents artéfacts (EARs, WARs, EJB JARs, RARs, SARs …) et à différentes ressources (sources de données, paramètres JMS …) d’être déployés sur JBoss. Tout ceci est géré par leurs deployers.

Cependant, la plupart des gens n’invoque pas ces deployers, ni même ‘twiddle‘. Ils préfèrent simplement déposer leurs artéfacts dans le répertoire deploy/ de leur serveur d’application Jboss, puis attendre que le Deployment Scanner le détecte. Ils vérifient ensuite dans le fichier de log que le déploiement est terminé.

Le souci avec cette méthode : le déploiement n’est pas une opération atomique. Quand on automatise un déploiement, on ne veut redémarrer le serveur web qu’après un déploiement réussi du nouveau WAR. Mais écrire un bout de code qui analyse les logs du serveur à la recherche d’un mot clé est tout simplement moche. Une alternative serait de positionner la propriété ScanEnabled du DeploymentScanner à false d’invoquer manuellement le deployer. Non seulement cela complexifie le code, mais il faut également prévoir la copie des fichiers dans le répertoire deploy du serveur JBoss.

Ainsi, il s’avère qu’avec JBoss Application Server, il est difficile d’intégrer des déploiements vers ses serveurs dans un scénario de déploiement plus global. RedHat doit corriger ce problème au plus vite pour que JBoss soit réellement prêt pour les entreprises.

IBM WebSphere Application Server

Et pour le gros monstre JEE de chez ‘Big Blue’ ? Il offre une façon polyvalente et transactionnelle pour déployer des applications et des ressources. Globalement, le langage de script wsadmin permet de contrôler tous les aspects de WebSphere. Par exemple, vous pouvez synchroniser des nœuds explicitement et l’invocation de la méthode (par Jython ou JACL) pour déployer l’application ne rendra la main que lorsque l’opération sera réalisée. Le côté négatif est qu’il est beaucoup plus lent que l’outil similaire WLST proposé par WebLogic (les nombreuses copies de documents XML à travers SOAP doivent y être pour quelque chose) et les API proposées sont plutôt complexes à manipuler (qui peut donner la différences entre un containment path, un configuration id et un object name?)

Bien que WAS ne propose pas de mécanismes pour regrouper les différents artéfacts et ressources liés à un même déploiement, sa nature transactionnelle permet de commiter les différents changements de configuration en une fois. Il peut même gérer la configuration des instances des serveurs IBM HTTP Server ou Apache HTTP Server .

Malgré une vitesse de déploiement lente, rien ne vaut la fiabilité des déploiements de WebSphere !

Conclusion

Les serveurs d’application fournissent chacun un niveau de support différent pour prendre en charge les déploiements des applications d’entreprise. Bien sûr, ils offrent tous le déploiement basique des artéfacts Java EE mais aucun d’entre eux ne propose de regrouper différents artéfacts en un seul déploiement ou de lier des ressources Java EE à ces artéfacts. WebLogic Server est le seul qui essaye de regrouper des ressources (JMS Modules et SubDeployment). Mais ces abstractions ne couvrent qu’une petite partie de toute l’étendue du déploiement Java EE.

La répétition et la prédiction sont très importantes pour une stratégie de déploiement réussie, ce qui peut expliquer la prévisibilité de WebSphere sur le marché. Et finalement, une bonne API est nécessaire pour automatiser votre processus de déploiement: WebLogic et WebSphere l’offrent, JBoss a un sérieux manque dans ce domaine (même avec twiddle !)

Les consultants de Xebia et l’ensemble des développeurs chez XebiaLabs ont quasiment tous écrit dans leurs expériences passées des tonnes de scripts pour automatiser des déploiements et ont dû batailler sur ces questions encore et encore. Nous avons développé Deployit afin de prendre en charge ces différences entre serveurs d’applications et parce que nous croyons que l’automatisation des déploiements est de la plus haute importance du fait du nombre croissant de déploiements dans les entreprises.

–
Traduction libre du billet «Do application server vendors really understand deployment? » publié par Vincent Partington.

SOA

• SOA Manifesto : pragmatisme utopique ?
• WADL devient une Submission W3C

Le coin de la technique

• Play! Framework 1.0
• Mise à jour de VisualVM en 1.2
• Comment concevoir un datacenter, … par Google
• Ca bouge dans la communauté Groovy/Grails
• Votre application web est elle vulnérable ?
• Artifactory : évolutions et mode SaaS

SOA

SOA Manifesto : pragmatisme utopique ?

La communauté SOA vient de publier son SOA Manifesto. Les valeurs sont très consensuelles, on pourrait même les trouver trop lisses quand on a vécu un naufrage SOA (avec l’oubli des objectifs métier, sa perfection naïve initiale, ses services faussement partagés qui finalement ne satisfont même pas le premier consommateur et autres ESB passe-plats).

Saluons tout de même cette initiative. SOA est une réalité. Les projets utopistes sont aujourd’hui minoritaires face à tous les projets qui intègrent des web services pour interconnecter les applications.
Le Manifeste SOA en français :
Valeur métier plutôt que stratégie technique,
Objectifs stratégiques plutôt que bénéfices spécifiques à un projet,
Interopérabilité intrinsèque plutôt qu’intégration propriétaire,
Services partagés plutôt qu’implémentation spécifique à un besoin particulier,
Flexibilité plutôt qu’optimisation,
Amélioration incrémentale plutôt que recherche de la perfection initiale.

Et rassurons-nous, ce n’est pas un manifesto qui empêchera les zélotes SOA de se déchirer. La guerre SOAP versus REST bat (toujours) son plein .

Ils parlent du SOA Manifesto : InfoQ SOA Manifesto, Stefan Tilkov’s Weblog : Comments on SOA Manifesto.

Allez, je retourne à mes web services Contract First avec CXF .

WADL devient une Submission W3C

Marc Hadley, auteur de la spécification WADL et spec-lead de la JSR-311 (JAX-RS), a annoncé que WADL venait d’être accepté en tant que Submission W3C.

Cette spécification portée par Sun a pour but de définir un format XML de description de services REST. Il s’agit donc d’un équivalent à WSDL pour REST. Alors que REST-*, porté par JBoss, a récemment relancé le débat sur la tendance récurrente à vouloir intégrer dans REST les fonctionnalités des très controversés WS-*, la soumission de WADL au W3C fait réapparaître la question de l’intérêt de définir des contrats pour des services REST.

Joe Gregorio s’opposait vivement à l’initiative WADL il y a deux ans déjà. Il reprochait principalement :

• l’insuffisance de WADL pour définir élégamment tous les types de services REST
• la fragilité du client qui ne fonctionne plus lorsque le contrat change comme c’est déjà le cas avec WSDL
• le manque de réalisme de l’approche WADL2Java qui ne permettrait pas la pleine exploitation de REST. Il préférait donc une approche d’écriture du client REST manuelle, en se basant sur un socle commun.

Toutefois, l’approche « REST avec un contrat » est séduisante pour les applications d’entreprise dont les services sont souvent aussi nombreux que les consommateurs variés.
C’est dans cette logique que de nombreux projets lèvent les ambiguïtés de leurs services REST en préférant XSD à JSON. Les URL et paramètres d’appel restant alors décrits uniquement dans une documentation annexe.

Par ailleurs, on peut regretter que WADL n’ait pas mieux adressé que WSDL des problèmes aussi important que le versioning des services alors qu’un projet comme Apache Thrift a su être innovant sur le sujet.

La soumission de WADL au W3C n’implique donc pas forcément son succès à venir. La disponibilité en masse d’outils et de frameworks permettant de gérer ce format pourrait en revanche attirer une partie des adeptes de SOAP.

Le coin de la technique

Play! Framework 1.0

The Server Side nous annonce la sortie de Play! Framework en version 1.0.

Play! est un framework web de haute productivité (tout comme Grails ou Spring Roo) qui simplifie la création et le développement d’applications Web en langage Java. Ce framework full stack inclut tout une batterie de composants tels que Groovy (pour le templating), Apache Mina mais aussi Hibernate. Quant à l’architecture de vos projets Play!, elle sera de type RESTful.

Cette vidéo nous donne un bon aperçu du produit, surtout en ce qui concerne le fameux Fix the bug and hit reload ! c’est à dire pas de compilation, de déploiement ou de redémarrage serveur suite à la modification de vos classes Java, juste un rafraîchissement de votre navigateur pour voir vos modifications.

A noter que l’équipe travaille déjà sur la version 1.1 et, entre autres, sur le support de Scala

Pour les liens utiles, la documentation complète du produit se trouve sur cette page. Le téléchargement se passe par ici. Et, comme le rappelle TSS, n’oubliez pas la présentation Play! framework in practice à Devoxx, en tous cas nous y serons !

Mise à jour de VisualVM en 1.2

8 mois après la sortie de la version 1.1, l’équipe nous gratifie d’une nouvelle version de son outil de monitoring de JVM. Avec un passage de 1.1.1 à 1.2, il ne faut pas s’attendre à de grandes révolutions. Une liste de 31 bugs corrigés, suivie de quelques nouvelles fonctionnalités notables:

• Un sampling profiler CPU et mémoire
• Support de plusieurs instances de JStatd
• Amélioration de l’API de génération de graphes
• Sauvegarde d’un snapshot de l’application dans un fichier nps pouvant-être utilisé plus tard pour analyse

Nous vous passons les améliorations de GUI et le support des proxys qui peut toujours s’avérer utile pour les analyses à distance. La vraie grande nouveauté c’est le plugin permettant de profiler l’application par sampling. Il ne faut pas s’attendre à la précision des outils instrumentant l’application comme JXInsight. Cependant, cela permettra une analyse assez poussée sans impact sur les performances.

Comment concevoir un datacenter, … par Google

Lors de la conférence Ladis 2009 (Large Scale Distributed Systems and Middleware), Jeff Dean, du groupe infrastructure chez Google, a présenté les manières de concevoir un système distribué.

Il passe en revue différentes problématiques :

• Infrastructure
• Stockage
• Clustering
• Échange de données sur le réseau
• Communication entre applications
• Construction d’application sur de telles infrastructures

Il est intéressant de voir les problématiques posées et les solutions proposées, sur des problématiques que nous avons trop tendance à oublier en tant que développeurs. Citons entre autres :

• Latence réseau : un critère important, car difficile à optimiser
• Bande passante du réseau
• Capacité de stockage (mémoire et disque)

Il est donc très important même pour un développeur d’avoir ces chiffres en tête.

Par retour d’expérience, Jeff Dean montre les joies d’interagir avec du matériel physique. Les applications ne doivent pas supposer que le matériel est infaillible, il y a différentes erreurs que nos applications doivent gérer. Quand on voit les nombres d’occurrences de ce type de problème et leur nature, leur gestion par l’application n’est pas aussi triviale qu’il y parait :

• Problème DNS
• Plantage de serveur
• Perte de connections
• …

Cette présentation est très riche, et elle permet de voir les tenants et aboutissants d’une bonne infrastructure mais aussi les impacts que cela peut avoir dans nos développements de tous les jours.

Les contraintes que s’est imposé Google en terme de disponibilité, dimensionnement, … ont amené plusieurs innovations technologiques en terme d’infrastructure qui ont des impacts sur le développement applicatif :

• Protocol Buffer
• MapReduce
• Google File System
• Big Table

Les lecteurs intéressés par les innovations mises en place par Google sur ses infrastructures noteront que Gregor Hohpe (auteur de Enterprise Integration Patterns) présentera à Devoxx une session Distributed Programming the Google Way.

Ca bouge dans la communauté Groovy/Grails

Pour commencer, on peut noter la longue présentation de Grails faite par Graeme Rocher sur InfoQ. Le « papa » de Grails revient sur de nombreux points relatifs à ce très bon framework permettant de créer des applications web rapidement en bénéficiant de la puissance de Java, Groovy, Hibernate, Spring…

Ensuite, et c’est la rançon du succès, il y a beaucoup de discussions et d’interrogations autour des besoins auxquels répondent Groovy et Grails. Sur son blog, Peter Delahunty précise par exemple que, pour lui, Grails n’est l’arme absolue que si on a une bonne connaissance des technologies sous-jacentes (Spring, Hibernate…). Il ne faut pas débuter par Grails sans s’attendre à bloquer sur des problèmes relatifs à ces technologies.

Cet article va dans le même sens et rappelle qu’à partir du moment où l’on parle de « la magie Groovy » il faut être conscient que des choses qui n’ont rien de magique (cela reste du code !) se passent. Les « dynamic finders », le MOP (Meta Object Protocol) et la magie des closures font rêver mais s’expliquent bel et bien ! Ensuite, il y est noté que la proximité de Groovy et Java fait que de nombreuses personnes pensent que l’on peut passer de Java à Groovy sans formation particulière. Si l’on ne comprend pas les principes de ces choses magiques et que l’on se contente de les accepter comme tels, on s’expose tôt ou tard à des retours de flamme sévères qui se matérialisent généralement sous la forme de StackTraces incompréhensibles. Enfin, le manque de support professionnel pour Groovy/Grails est évoqué. Sur ce point, je pense que l’auteur se trompe. On note en effet que Springsource semble fournir un support commercial pour ces technologies. Mais, il y a peu, Groovy et Grails n’étaient pas encore dans le giron de Springsource et l’on devait « se contenter » du support de la communauté. Néanmoins, celui-ci a toujours été assez réactif et de bon niveau.

Toujours concernant Groovy, on peut noter la version Community Edition de l’IDE IntelliJ, tout récemment publiée, semble bien lotie au niveau du support de ce langage. Malheureusement, le support de Grails, lui, n’est pas présent dans cette version.

Votre application web est elle vulnérable ?

Le Web Application Security Consortium (WASC) estime que 87% des applications de la toile sont vulnérables. Tout le monde ne peut pas s’offrir les services d’un expert en sécurité, et un développeur ne peut pas écrire du code sécurisé s’il ne connaît ou ne comprends pas les risques auxquels il s’expose. C’est pour cette raison que DeveloperWorks revient sur les principales failles de sécurité qui nous guettent, et quelques outils simples pour analyser notre code.
Les points de faiblesse les plus connus sont :

• le cross site scripting : le pirate injecte, via un autre site (de type forum par exemple), un script (de type javascript) vers le site visé. Ce script lui permet de récupérer des informations de connexion, des cookies…
• l’injection de SQL : le pirate saisit du code SQL dans un formulaire web. Celui-ci est poussé jusqu’à la base, exécuté et donne (le plus souvent) accès à la base ‘en direct’ au pirate (l’un des exemples le plus connus est l’injection de OR 1=1- dans un formulaire d’authentification, qui retourne alors toujours TRUE).

Et l’on reparle de l’OWASP, qui propose un outil open source pour détecter ces erreurs de conception : WebScarab. WebScarab s’utilise comme un proxy HTTP (qui se place entre votre browser et votre serveur d’applications, par simple redirection des ports). Ensuite, un simple fichier .txt permet d’injecter votre site avec quelques-uns des plus célèbres cas de cross site scripting ou d’injection SQL. Un autre outil open source est présenté, d’un fonctionnement similaire, Paros Proxy.
Reste ensuite à détecter les faux positifs, opération généralement manuelle.

On notera que la section Ressources de l’article original est richement fournie, et permet de réellement comprendre les risques auxquels sont exposées les applications accessibles sur internet.

Saurez-vous trouver les failles du site de test Webgoat ?

Artifactory : évolutions et mode SaaS

Artifactory est un repository Maven dont la principale particularité est de s’appuyer sur Java Content Repository (JCR) pour assurer le stockage des artefacts. Le choix de JCR plutôt qu’un simple système de fichiers n’avait pas fait l’unanimité car il rend les tâches courantes d’administration plus délicates. En effet, lorsque l’on veut supprimer, remplacer ou déplacer un ensemble d’artefacts, l’action est triviale lorsque le système de fichier est utilisé alors qu’elle devient plus complexe avec JCR, qui n’est pas aussi directement manipulable.

Conscient de ce problème JFrog, l’éditeur derrière Artifactory, a peu à peu intégré un certain nombre de fonctionnalités permettant d’effectuer ces tâches courantes d’administration des artefacts directement depuis l’interface Web. Ainsi, la dernière version du projet permet même le déplacement d’artefacts entre plusieurs repository.

Début septembre, JFrog a également lancé ArtifactoryOnline, un service d’hébergement de repository Maven Artifactory en mode SaaS (Software as a Service). Ce type d’offre répond clairement à un besoin puisque la présence d’un repository Maven est souhaitable pour de nombreux cas d’utilisation et que cette infrastructure nécessite du temps et du matériel dont ne disposent pas toujours les équipes de taille réduite.

Par ces innovations, le repository Maven de JFrog saura sûrement séduire les utilisateurs déçus par les solutions concurrentes que sont Nexus et Archiva.

Article mis à jour le 26/10/2009 à 21h25

Michel, qui a l’habitude de ce genre d’exclamation vis-à-vis de l’organisation des réseaux d’entreprise, explique calmement que toutes les requêtes partant d’un navigateur doivent d’abord passer par un serveur HTTP avant d’être redirigées vers le serveur d’applications. « Il est donc aussi nécessaire de configurer Apache ! », dit-il. « Mais je développe une application Java, j’ai juste besoin de déployer sur un serveur d’applications et hop, terminé ! » répondez vous. Et Michel d’expliquer sur un ton très sérieux : « Écoute fiston, appuyer sur le bouton de déploiement de ta console d’administration est juste une petite étape parmi toutes celles qui permettent de réaliser un vrai déploiement. »

Rendre l’application accessible à l’utilisateur final

Avant de parler des différentes étapes du déploiement, il est important de comprendre quel est l’objectif d’un déploiement. De façon élémentaire, le but d’un déploiement est de « rendre une application, dans une version donnée, disponible pour les utilisateurs finaux ». En d’autres termes, l’utilisateur ouvre son navigateur, tape www.app.com et voit l’application fonctionner.

Alors, que faut-il faire pour qu’une application fonctionne? Pour comprendre les composantes du déploiement, le plus simple est de suivre la requête depuis le navigateur de l’utilisateur à travers tous les composants matériels et logiciels par lesquels elle transite.
« La destination de la requête est tout d’abord résolue en s’adressant à un serveur DNS (ou à un mécanisme équivalent). La requête est alors routée vers sa destination ; elle est filtrée par un premier firewall, arrive sur le serveur HTTP chargé de la répartition de charge, traverse un nouveau firewall, atteint le serveur d’applications puis enfin l’application à proprement parler, exécutée sur le serveur, qui elle-même interroge une base de données pour récupérer les informations demandées par l’utilisateur. »
Sur cet exemple simple, il y a au moins 5 composants en action pour rendre disponible l’application ; nous devons non seulement configurer ces 5 composants mais aussi y placer certaines données et s’assurer au besoin qu’ils (re-)démarrent dans un ordre correct.

Voici typiquement les étapes nécessaires au premier déploiement d’une telle application sur un environnement de production :

• (a) Exécuter les ordres SQL de création de tables sur la base de données
• (b) Configurer la source de données JDBC dans le serveur d’applications
• (c) Configurer les ports HTTP et les Virtual Hosts dans le serveur d’applications pour que l’application soit accessible par les requêtes HTTP
• (d) Installer l’application sur le serveur d’applications
• (e) Démarrer l’application
• (f) Configurer le firewall, en ouvrant les ports utiles à la communication entre le serveur HTTP et le serveur d’applications
• (g) Configurer le serveur HTTP, pour router vers le serveur d’applications les requêtes arrivant sur www.app.com et qui ne se terminent pas, par exemple, par .js, .html, .jpg
• (h) Déposer le contenu HTML statique (fichiers js, fichiers css, images, etc.) sur le serveur HTTP
• (i) (re-)Démarrer le serveur HTTP pour prendre en compte la nouvelle configuration
• (j) Configurer le firewall externe, pour permettre les accès de www.app.com vers le bon serveur HTTP

Bien sûr, dans un environnement plus complexe, on ajoute quelques étapes à la liste. Par exemple, dans un environnement clusterisé avec haute disponibilité, tout doit être fait au moins deux fois. Pour les déploiements de versions ultérieures de la même application, certaines étapes pourront de surcroît être négligées.

Des tâches nombreuses et variées

Les étapes décrites dans la section précédentes permettent de « mettre à disposition des utilisateurs » une application à l’architecture élémentaire. D’une façon plus générale, on peut distinguer plusieurs grandes catégories d’opérations à réaliser pour finaliser un déploiement :

• Installer l’application (Étape d)
  C’est la partie principale du déploiement, où la logique métier est installée sur le serveur, le plus souvent sous la forme d’un fichier EAR ou WAR.
• Configurer les ressources externes (Étape b)
  L’application peut avoir besoin d’interagir avec d’autres systèmes, comme une base de données, un mainframe ou un middleware de message. Les ressources externes sont le plus souvent utilisées par l’application pour obtenir ou diffuser des données. L’accès à ces ressources est généralement configuré au niveau du serveur d’applications.
• Configurer les composants intermédiaires (Étape a, c, f, g, h, j)
  Ce sont les composants qui permettent d’atteindre l’application, et de l’exécuter (par exemple, un cluster de serveurs d’applications, des instances de serveurs HTTP, des firewalls, etc.).
• Démarrer/Arrêter les composants (Étape e, i)
  Pour s’assurer que chaque composant fonctionne correctement, il peut être nécessaire de le (re-)démarrer.
• Et respecter l’ordre dans les points précédents

Pour être sûr que l’application démarre correctement, sans erreurs, un certain ordre doit être maintenu. Exemple : Si vous installez l’application (Étape d) et la démarrez avant d’avoir configuré la source de données (Étape b), l’application risque de ne pas se lancer correctement. Ceci devient encore plus important lorsque vous déployez une nouvelle version de votre application dans un environnement clusterisé.

Il y a une catégorie supplémentaire pour les organisations qui valident leurs applications successivement sur plusieurs environnements (Développement, Test, Intégration, Production) :

• Configurer l’application installée sur des environnements différents
  Un déploiement doit assurer la configuration spécifique à l’environnement. Exemple : Quand vous installez une application sur l’environnement de développement, il faut récupérer les données de la base de développement. De la même façon, pour l’environnement de tests, il est nécessaire d’avoir les données de tests et ainsi de suite.

L’EAR, la partie émergée de l’iceberg

Beaucoup pensent qu’installer un EAR sur un serveur d’applications équivaut à déployer l’application. Bien sûr, le bouton dans la console d’administration indique : « Déployer l’application », mais il ne s’agit que de la partie concernant le serveur d’applications à proprement parler ; cette vision étroite du déploiement n’est généralement opérationnelle que sur un environnement simplifié, comme celui de développement ou sur le poste de travail du développeur. Dès qu’une application doit être installée sur un environnement plus complexe, cette vision ne suffit plus et il devient nécessaire de réaliser un grand nombre d’opérations complémentaires pour véritablement « mettre l’application à disposition des utilisateurs ».

Parce que de ce point de vue le déploiement n’est pas une opération triviale, beaucoup cherchent à l’automatiser.
Exécuter manuellement toutes les étapes est en effet à la fois complexe et risqué, particulièrement sur les environnements les plus critiques. Et ce, d’autant plus que, souvent, les responsabilités et les gouvernances de chaque module de l’infrastructure reposent entre les mains de personnes, d’équipes, voire de départements différents.
Malheureusement, cet effort d’automatisation aboutit souvent à un ou plusieurs jeux de scripts à la gouvernance floue et dont le coût de maintenance semble souvent prohibitif. Les solutions du marché n’abordent souvent qu’un sous-ensemble de la problématique (on pense à Phurnace ou BuildForge, qui restent concentrés sur le serveur d’applications, ou à d’autres solutions qui sont souvent de simples ordonnanceurs de scripts).
Avec les serveurs d’intégration continue, on peut mettre en œuvre des déploiements automatiques, qui permettent de tester la chaîne complète de la compilation jusqu’aux tests de charge (cf. Build Pipelines). Et si l’on veut aller encore plus loin, c’est-à-dire déployer automatiquement sur l’environnement de production, on peut se pencher sur le logiciel DeployIt, développé par mes collègues Hollandais.

Je parlerai, plus en détail, dans un prochain article du déploiement automatique et nous pourrons déterminer par nous-même si c’est une solution « Insane » comme le pense le livre blanc Enterprise CI Maturity Model de la société anthillpro ou une solution réelle pour améliorer la fiabilité comme le pense DeployIt.

Samedi matin, j’ai assisté à la session sur la gestion de source dans un environnement distribué. Après une mise au point sur la différence entre gestion de configuration et gestion de source, nous avons entamé la discussion sur l’outil très utilisé dans le développement Open Source dénommé GIT. Cet outil fonctionne en mode décentralisé : il n’y a pas un unique serveur de sources, mais chaque développeur fonctionne à la fois en mode serveur et en mode client. Le développeur peut, par exemple, versionner très souvent ses sources sur son serveur local, mais décider de ne valider ses changements qu’en une seule fois sur le serveur de référence (il peut même signer sa validation !).
Le cas d’un projet partagé entre la France et l’Australie m’a particulièrement intéressé. Le responsable avait mis en place un serveur intermédiaire GIT sur chaque site pour éviter les échanges réseau trop nombreux avec un serveur central. Une synchronisation régulière permettait aux deux sites d’être à jour. Il s’était rendu compte au bout d’un certain temps que cela était en réalité inutile, car la qualité du réseau faisait qu’on pouvait se permettre de n’avoir qu’un seul serveur. En revanche, si cela est peut-être vrai pour l’Australie, ce ne l’est pas forcément pour tous les pays.
Avec GIT, chaque copie du repository est une nouvelle branche ; un développeur en local, c’est une branche. Le fonctionnement des branches est un vrai casse-tête pour des outils comme Subversion, et cette approche propose finalement un peu de simplicité. Mais pour le moment, les serveurs d’Intégration Continue ne font pas la différence entre modes centralisé et décentralisé. Rien n’est proposé aujourd’hui pour mieux profiter d’un monde distribué…

Après un ravitaillement en café et jus d’orange, j’ai suivi Vincent Massol, de XWiki pour savoir comment améliorer notre façon de faire une release avec Maven. Arnaud Heritier faisait parti de la session et après une présentation du processus pour XWiki, ils ont démarré le codage d’une extension au plugin dependency. L’objectif était d’ajouter un goal pour récupérer les différences entre les versions des dépendances entre deux releases. Il faudra être attentif aux prochaines sorties de ce plugin, il y aura peut-être une nouvelle fonction.
Le constat, finalement, était qu’il y avait encore beaucoup d’étapes manuelles lors de la release d’une version et qu’à part développer ses propres MOJOs, Maven était assez loin du compte. Mais ça avance comme le montre le plugin versions, dont Arnaud Heritier nous a vanté les mérites.

L’après-midi, trois sessions nous attendaient mais je souhaite ne parler que de la dernière sur la configuration et le déploiement, les autres étant déjà traitées sur différents blogs. Un problème récurrent se pose sur chaque projet, celui de la modification des valeurs selon l’environnement sur lequel on déploie. On utilise, par exemple, des fichiers de propriétés qui sont remplacés au moment du packaging. Si on s’est trompé dans les propriétés ou si la valeur n’est connue que de la personne qui déploie, il faut dézipper le fichier, changer la valeur et refaire le package. Bonjour la galère !
Deux ingénieurs de ThoughtWorks nous ont présenté leur petit dernier : Escape. Sous ce nom très commun se cache une application Java dans laquelle on peut sauvegarder les valeurs des propriétés de chaque application dans un environnement donné. Ces valeurs peuvent être cryptées. Pour y accéder, une simple interface REST permet d’interroger la base et de récupérer la valeur : l’url http://mymachine:8080/environnements/dev/citcon/city, par exemple, renvoie la valeur de city pour l’environnement de dev sur l’application citcon. Je trouve ce projet simple et efficace pour améliorer la gestion des propriétés de nos applications. La mise en œuvre demandera un peu d’effort pour disposer d’un serveur central mais cela en vaut certainement la peine pour s’affranchir de cette partie de la configuration.

La conférence s’est terminée par un tour des participants sur leur « AA moment » (ie. ce qu’ils ont préférés!) et une distribution de livres sur l’intégration continue.
J’en ai gagné un, écrit par Paul M. Duvall, qui était juste à côté de moi, et me l’a dédicacé. Et c’est aussi ce qui rendait cette journée franchement sympathique et réussie; mon « AA moment » a été de mettre enfin un visage sur des auteurs de blogs ou des contributeurs open source, et surtout pouvoir converser de visu.

Intervenants :

• M. Guillaume Bodet, Directeur Technique, Xebia

Informations utiles :

• Adresse : L’Atelier – 14, Rue Bergère – 75009 Paris
• Date : Jeudi 8 Octobre 2009 à 9h00
• Durée : 2H00
• Inscription: http://www.atelier.fr/inscriptionEvenement.php?artid=38668

Erreurs humaines, interventions « pompier », manque de prédictibilité, complexité des guides et procédures de mise en production, manque d’évolutivité des scripts, frictions entre les départements Etudes et Production, mises à jour des middleware et des applicatifs coûteuses sont autant de maux que rencontrent les utilisateurs des technologies Java/J2EE.

Fort de nos 8 ans d’expérience dans la conception, la mise en place et la gestion d’applications et d’infrastructures basées sur Java/J2EE chez plus de 200 clients en Europe, Xebia a créé DeployIT, une offre logicielle, exclusivement dédiée aux déploiements Java/J2EE.

DeployIT permet de sécuriser et de réduire les coûts des déploiements des applications et des infrastructures Java/J2EE, jugés de plus en plus périlleux, coûteux et aléatoires.

Xebia Labs propose donc une plateforme logicielle incluant les spécificités des applications et infrastructures Java/J2EE, adossée à une approche méthodologique éprouvée, offrant les avantages suivants :

• Réduction des risques d’échecs des déploiements liés aux trop nombreuses interventions humaines.
• Réduction des coûts liés au développement et à la maintenance de scripts coûteux et hétérogènes.
• Suppression des interventions « pompier » des équipes de développement pour aider les cellules d’exploitation à mettre en production.
• Réduction du Time to Market des nouvelles applications ainsi que de leurs évolutions fonctionnelles.
• Standardisation autour d’un outil commun des départements Etudes et Production.
• Garantie des SLA par une professionnalisation de la filière de déploiement.

Pour avoir plus d’informations sur cette solution, n’hésitez pas à contacter Luc Legardeur au 01 42 91 27 93 ou par mail : llegardeur@xebia.fr.

Une conférence est l’occasion de discuter avec les ingénieurs des difficultés que nous rencontrons à utiliser leurs produits. J’ai profité de ma participation à SpringOne 2009 pour échanger avec Mark Thomas sur le suivi de l’adresse IP des internautes dans les logs d’audit d’applications web. Mark Thomas est des principaux committer du projet Tomcat et de SpringSource tc Server.

Le problème se présente lorsqu’un serveur Tomcat est précédé d’un reverse proxy (e.g. mod_proxy, Squid Cache, etc) ou d’un load balancer (Nortel Alteon, F5 Big-IP, etc) : La méthode HttpServletRequest.getRemoteAddr() ne retourne plus l’adresse IP de l’internaute mais celle du composant réseau qui précède le serveur Tomcat.

Cette perte d’information a été compensée par les reverse-proxy en ajoutant un header http X-Forwarded-For à toutes les requêtes qu’ils font transiter. Bien que ce header ne soit pas standard (son nom commence d’ailleurs par « X- »), il est devenu un standard de facto utilisé par la très grande majorité des reverse proxy et load balancers (paramètre xforward=enable pour les Alteon d’après Command Reference ; propriété Insert XForwarded For de la GUI du profile http ou règle when HTTP_REQUEST { HTTP::header insert "X-Forwarded-For" [IP::client_addr] } pour les Big-IP d’après F5 Dev Central : Using « X-Forwarded-For » in Apache or PHP ).

Cependant, les implémentations de l’API Servlet ne sont pas tenues de prendre en compte ce paramètre dans la méthode request.getRemoteAddr() dont la javadoc stipule bien Returns the Internet Protocol (IP) address of the client or last proxy that sent the request. . Tomcat est d’ailleurs autant concerné que ses concurrents Websphere ou Weblogic, pour ne citer qu’eux.

Toutes les couches sont impactées : l’Access Log Tomcat dont les patterns common et combined utilisent le remote host name (%h) et les frameworks de sécurité et d’audit comme Spring Security (cf WebAuthenticationDetails.getRemoteAddress()) ou CAS Inskektr ClientInfo).

Access Log Tomcat et Apache Httpd : modification du pattern de log

Pour corriger l’access log Tomcat, il est possible de configurer l’utilisation du header X-Forwarded-For plutôt que de l’ip distante dans le pattern de log (pratique relativement bien documenté).

...
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log."
       suffix=".txt" pattern="%{X-Forwarded-For}i %l %u %t %r %s %b" resolveHosts="false" />
...

Si les serveurs Apache Httpd sont précédés d’un load balancer, la modification est très similaire, mod_log_config permet de définir les informations affichées dans l’accès log. On modifie la pattern de log pour utiliser le header http X-Forwarded-For ( %{X-Forwarded-For}i ) plutôt que le remote host ( %h) :

LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %b" common
CustomLog logs/access_log common

La prise en compte du header X-Forwarded-For dans Apache Httpd sera bientôt simplifiée avec la récente introduction dans le trunk du module mod_remoteip qui permettra de prendre en compte ce header avec une simple configuration RemoteIPHeader X-Forwarded-For ; il ne sera plus nécessaire de manipuler le pattern des logs.

Frameworks Java : extension des applications ou du moteur de servlet

S’il est simple de prendre en compte le paramètre X-Forwarded-For dans les access log Tomcat et Apache Httpd, il est sensiblement plus complexe de l’intégrer dans les frameworks de sécurité et d’audit. Ces briques sont souvent des librairies tierces et modifier leur code est fastidieux voire impossible si elles sont ‘close source’. Il est donc nécessaire de se placer en amont de ces frameworks pour modifier le comportement de la méthode ServletRequest.getRemoteAddr().

Servlet API : XForwardedForFilter

La première solution est de développer un Servlet Filter que l’on déploie dans chaque web application.

• Avantage : Simple à implémenter grâce aux interfaces Filter, HttpServletRequest et à l’HttpServletRequestWrapper qui est destiné à faciliter ce type de développement, ce Filter est utilisable aussi bien avec Tomcat qu’avec Glassfish, JBoss, Jetty, WebSphere, Weblogic ou tout autre moteur de servlet.
• Inconvénient : lourd à déployer sur toutes les web applications.
• Exemple d’implémentation: XForwardedFilter (XForwardedFilter.java) gère les headers X-Forwarded-For et X-Forwarded-Proto

Pour installer cette solution :

1. Télécharger xebia-servlet-extras-1.0.2.jar, compiler XForwardedForFilter.java et déployer le jar sous WEB_APP_HOME/WEB-INF/lib ou ajouter la dépendance maven fr.xebia.web.extras:xebia-servlet-extras:1.0.2 à votre pom.xml (doc).
2. Déclarer dans web.xml le filter XForwardedFilter :

...
   <filter>
      <filter-name>XForwardedForFilter</filter-name>
      <filter-class>fr.xebia.servlet.filter.XForwardedFilter</filter-class>
   </filter>
   <filter-mapping>
      <filter-name>XForwardedFilter</filter-name>
      <url-pattern>/*</url-pattern>
      <dispatcher>REQUEST</dispatcher>
   </filter-mapping>
   ...

1. Tester le résultat avec x-forwarded-for_as_remote-addr.jsp, le résultat devrait ressembler à x-forwarded-for_as_remote-addr.jpeg.

Extension Tomcat : RemoteIpValve

La deuxième solution est d’ajouter une extension au serveur Tomcat pour en modifier le comportement ; il ne s’agit plus alors de Servlet Filter et d’HttpServletRequest mais de Valve et de Request :

• Avantage : solution centralisée gérée par l’administrateur Tomcat sans intrusion dans les web applications. Cette solution permet de traiter dans le même temps l’AccessLogValve.
• Inconvénient : intégré à Tomcat seulement depuis la version 6.0.24 ; pour les version antérieures, il faut déployer un jar additionnel.
• Exemple d’implémentation : RemoteIpValve.java gère les headers X-Forwarded-For et X-Forwarded-Proto
• RemoteIpValve.java a été intégré au projet Tomcat Bug 47330 – proposal : port of mod_remoteip in Tomcat as RemoteIpValve et est documentée sur GoogleCode : RemoteIpValve

Pour installer cette RemoteIpValve :

1. Pour les versions de Tomcat antérieures à la 6.0.24, télécharger xebia-tomcat-extras-1.0.0.jar, compiler RemoteIpValve.java et déployer le jar sous TOMCAT_HOME/lib.
2. Déclarer la RemoteIpValve dans server.xml :

...
   <Valve className="org.apache.catalina.connector.RemoteIpValve" />
   <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log."
      suffix=".txt" pattern="common" resolveHosts="false" />
   ...

1. Tester le résultat avec x-forwarded-for_as_remote-addr.jsp, le résultat devrait ressembler à x-forwarded-for_as_remote-addr.jpeg.

Mark Thomas reconnaît l’intérêt de faciliter le développement d’extensions pour Tomcat et la tâche devrait grandement se simplifier avec le projet Convert current Tomcat valves to Servlet Filters for The Apache Software Foundation du Google Summer of Code 2009. Cette évolution ouvre la perspective de développer des filtres d’infrastructure similaires aux modules écrits en C pour Httpd mais avec la souplesse du langage Java.

Pour aller plus loin

• Apache Httpd mod_proxy : Reverse Proxy Request Headers
• Squid Cache : forwarded_for configuration parameter
• Xebia-france Google Code : RemoteIpValve

2009/05/17 : Ajout des paramètres de configuration des Alteon et BIG-IP pour activer l’insertion du header x-forwarded-for
2009/07/12 : Mise à jour du paragraphe sur la Valve tomcat pour utiliser la RemoteIpValve
2009/07/17 : Mise à jour du paragraphe sur le servlet filter XForwardedFilter
2009/10/13 : Montée de version de xebia-servlet-extras en version 1.0.1 pour corriger le bug soulevé par Alexandre Victoor
2009/11/08 : Ajout de la remarque préliminaire : la valve et le filtre ont été intégrés dans le projet Tomcat.
2010/01/24 : Mise à jour de l’article pour prendre en compte la disponibilité de la RemoteIpValve dans la distribution standard Tomcat depuis la version 6.0.24.
2010/01/31 : Montée de version de xebia-servlet-extras en version 1.0.2 pour corriger Issue 4 – XForwardedFilter : request.secure and request.scheme are not forced to « false » and « http » if X-Forwarded-Proto=http.