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.

Public Cloud, Private Cloud, Hybrid Cloud, Infrastructure as a Service, Platform as a Service, Software as a Service, …

Nous vous invitons le 23 Novembre 2011 à 19h30 à décrypter ces mots à la mode avec Sacha Labourey, CEO et fondateur CloudBees, ex CTO JBoss.
Après une présentation du Cloud Computing et (brièvement) de l’offre CloudBees, Sacha Labourey répondra à vos questions.

Voici notre première série :

• Pourquoi le cloud est-il arrivé ?
• Quels bénéfices attendre du cloud ? Pour les départements études / développement ? Pour les départements exploitation / production ?
• A quel rythme les organisations vont-elle être impactées par le cloud ? Les changements à court terme ? Les transformations à long terme ?
• Comment préparer son organisation à l’arrivée du cloud ? Côté développement ? Côté exploitation ?

Sans oublier nos questions provocatrices :

• Le cloud, est-ce la mort du métier d’administrateur système ?
• Le PaaS est magique ? Les middlewares sont devenus zero-administration et self-tuning ?
• Rupture totale ou évolution dans la lignée de tendances comme la virtualisation ?

La soirée terminera par un cocktail pendant lequel des consultants CloudBees et Xebia pourront vous faire des démonstrations.

L’inscription sur EventBrite est ici. Retrouvez les événements Xebia sur blog.xebia.fr/tech-event.

Les vidéos de la soirées :

• Vidéo de la présentation de Sacha Labourey sur le Cloud
• Questions-Réponses sur le Cloud avec Sacha Labourey et Cyrille Le Clerc – Épisode 1
• Questions-Réponses sur le Cloud avec Sacha Labourey et Cyrille Le Clerc – Épisode 2
• Questions-Réponses sur le Cloud avec Sacha Labourey et Cyrille Le Clerc – Épisode 3
• Questions-Réponses sur le Cloud avec Sacha Labourey et Cyrille Le Clerc – Épisode 4

Au lieu de penser à ouvrir votre Nexus sur Internet ou encore à créer votre propre repository sur Google Code ou autre, nous vous proposons de directement déployer sur le Maven Central Repository, ce qui, en plus de vous épargner l’installation d’un repository, facilitera l’utilisation de votre artefact.

Le but de ce billet est de décrire la marche à suivre pour la publication d’un artefact en passant par le repository de Sonatype. Ce dernier étant un repository approuvé pour tout projet OSS comme c’est le cas du repository Apache (pour les projets Apache) et celui du Codehaus (pour les projets Codehaus). Le fait de passer par Sonatype vous garantit d’une part, un processus de validation structurant qui impose un ensemble de points de contrôle (licence, copyright, traçabilité, etc.) augmentant ainsi la qualité des métadonnées, et d’autre part une synchronisation rapide avec le Maven Central Repository.

Il s’agit également de vous faire profiter de notre expérience sur le sujet avec le déploiement de quelques artefacts tels que mindmap-maven-plugin, xebia-management-extras, xebia-spring-security-extras et xebia-servlet-extras.

Ce qui est présenté par la suite est basé principalement sur le guide officiel fourni par Sonatype: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

Choix de la licence du projet

Chacun appliquera sur son code la licence qui lui convient. C’est à la fois un choix « tactique » pour cibler ses utilisateurs et « philosophique » selon ses convictions. Pour résumer ce sujet qui mériterait un billet complet, il y a deux grandes familles de licences :

• les licences « business friendly » (Apache Software Licence, MIT, BSD, etc) qui facilitent l’intégration dans toute programme (y compris « close source » et commercial)
• les licences « business unfriendly » (GPL, Aferro GPL, etc) qui sont qualifiées de virales et ne permettent pas l’intégration dans des logiciels « close source »

Pour aller plus loin sur le sujet, nous vous recommandons 451 Chaos Group – 06/2011 : The trend towards permissive licensing et notre récent billet Réponses au Quizz Licences Open Source.

Application de la licence sur les fichiers de son projet

• Tous les fichiers doivent porter le header de la licence
• Un fichier LICENSE (exemple) à la racine doit être reporté dans les artefacts générés
• Un fichier NOTICE (exemple) à la racine doit mentionner les copyrights des dépendances

Si vous êtes dans le cas d’une licence APV2, vous pouvez toujours vous référer à ce lien : Applying the license to new software.

Le apache-rat-plugin permet de vérifier la conformité du projet et peut casser le build dans le cas contraire.

Exemple de déclaration des ressources dans un pom maven pour intégrer les fichiers LICENSE et NOTICE dans les artefacts:

<project ...>
 ...
 <resources>
  <resource>
   <directory>${basedir}/src/main/resources</directory>
   <filtering>true</filtering>
  </resource>
  <resource>
   <directory>${basedir}</directory>
   <targetPath>META-INF</targetPath>
   <includes>
    <include>LICENSE</include>
    <include>NOTICE</include>
   </includes>
  </resource>
 </resources>
 ...
</project>

Exemple d’utilisation du apache-rat-plugin dans un pom maven:

<project ...>
   ...
   <plugin>
    <groupId>org.apache.rat</groupId>
    <artifactId>apache-rat-plugin</artifactId>
    <version>0.7</version>
    <executions>
     <execution>
      <phase>verify</phase>
      <goals>
       <goal>check</goal>
      </goals>
     </execution>
    </executions>
   </plugin>
   ...
</project>

Mise en conformité du pom maven

Le fichier pom.xml doit obligatoirement porter les informations suivantes:

• <modelVersion>
• <groupId>
• <artifactId>
• <version>
• <packaging>
• <name>
• <description>
• <url>
• <licenses>
• <scm><url>
• <scm><connection>
• <developers>

Pour faciliter le déploiement des artifacts sur le repository http://oss.sonatype.org qui sert de bac à sable de validation, le plus simple est de référencer le pom parent « org.sonatype.oss:oss-parent » fourni par sonatype. Exemple :

<project...>
  <parent>
    <groupId>org.sonatype.oss</groupId>
    <artifactId>oss-parent</artifactId>
    <version>7</version>
  </parent>
  ...
</project>

(?) De plus, il est fortement recommandé que le pom.xml ne référence pas de repository (cf. Why Putting Repositories in your POMs is a Bad Idea)

Signature des artefacts avec GPG

Les artefacts publiés sur repo1.maven.org doivent être signés.

Le pom parent org.sonatype.oss:oss-parent utilise le maven-gpg-plugin qui se base sur l’implémentation GnuPG du standard OpenPGP pour la signature des artefacts. Pour s’appuyer dessus, vous devez :

• Installer un client GPG (e.g. Mac GNU Privacy Guard)
• Créer votre paire de clés GPG (privée/publique) (cf GPG Quick Start par Paul Heinlein)
• Distribuer votre clé publique sur un serveur de clé PGP:

gpg --keyserver hkp://pool.sks-keyservers.net --send-keys your_public_key_ID

• Tester votre clé avec maven-gpg-plugin:

mvn package gpg:sign -Dgpg.passphrase=PASSPHRASE

Création d’un compte sur oss.sonatype.org

La création d’un compte pour déployer sur oss.sonatype.org se fait en créant un compte https://issues.sonatype.org/ .

Création d’un ticket Jira de demande d’autorisation : obligatoire pour la première publication

Il vous faut faire une demande à Sonatype en créant un ticket Jira de demande de publication d’artefact dans lequel on précise :

• Summary : description rapide du projet
• GroupId : groupId du projet Maven. Ce groupe doit reprendre le nom de domaine du projet (e.g. : fr.xebia, com.googlecode.myproject, etc.)
• Project URL : l’url du projet (e.g. http://xebia-france.googlecode.com/
• SCM URL : l’url du gestionnaire de source (e.g. http://xebia-france.googlecode.com/svn/)
• Nexus Username : le ou les logins de connexion au JIRA : https://issues.sonatype.org/
• Already Sync To Central : indique si des versions de l’artefact ont déjà été déployées sur le Maven Central Repository (si oui, Sonatype les réintégrera dans le fichier maven-metadata.xml)
• Description : toute information complémentaire

Exemple de demande :  OSSRH-995 : Managements extras : jmx-ification of util.concurrent / dbcp / jms, @Profiled annotation, etc

Déploiement des snapshots et des staging releases avec maven

Compléter l’élément SCM avec les informations de votre repository

• Subversion:

<project>
  ...
  <scm>
    <connection>scm:svn:http://host_name/svn/path_to_project/trunk/</connection>
    <developerConnection>scm:svn:https://host_name/svn/path_to_project/trunk/</developerConnection>
    <url>http://host_name/svn/path_to_project/</url>
  </scm>
  ...
</project>

• Github:

<project>
  ...
  <scm>
    <connection>scm:git:git@github.com:user/project_name.git</connection>
    <developerConnection>scm:git:git@github.com:user/project_name.git</developerConnection>
    <url>git@github.com:user/project_name.git</url>
  </scm>
  ...
</project>

Configurer le fichier settings.xml

• Accès au repository nexus de sonatype:

<settings>
  ...
  <servers>
    <server>
      <id>sonatype-nexus-snapshots</id>
      <username>your_jira_id</username>
      <password>your_jira_pwd</password>
    </server>
    <server>
      <id>sonatype-nexus-staging</id>
      <username>your_jira_id</username>
      <password>your_jira_pwd</password>
    </server>
  </servers>
  ...
</settings>

• Accès au repository du code source

<settings>
  ...
  <servers>
    <server>
      <id>host_name_of_your_scm_url</id>
      <username>user_name</username>
      <password>password</password>
    </server>
  ...
</settings>

Préparer la release: Création d’un nouveau tag sur le repository du code source

mvn release:prepare -Dresume=false (alternativement mvn release:clean release:prepare)

Déployer le nouveau tag dans le staging repository

mvn release:perform -Darguments=-Dgpg.passphrase=<<PASSPHRASE>>

Publication de votre artefact : utilisation de nexus-maven-plugin

Ajouter org.sonatype.plugins dans la section <pluginGroups> du fichier settings.xml

<settings>
  ...
  <pluginGroups>
    <pluginGroup>org.sonatype.plugins</pluginGroup>
  </pluginGroups>
  ...
</settings>

Afficher la liste des staging repositories : un staging repository par artefact

mvn nexus:staging-list

Ce qui vous permettra d’obtenir la liste des repositories ouverts et clôturés si il en existe :

Clôturer un staging repository

mvn nexus:staging-close

Sélectionnez à partir de la liste le repository à clôturer et suivre les instructions:

Publier l’artefact : action irréversible (aucun update ou delete ne sera possible)

mvn nexus:staging-promote

Sélectionnez le repository à publier:

Vous pouvez maintenant retrouver votre actefact sur le releases repository de Sonatype en attendant la synchronisation avec le repo1.maven.org qui vous permettra après quelques heures de le voir à partir du Maven Central Repository Browser

Activer la synchronisation avec le repository central repo1.maven.org

Pour une première publication, vous avez besoin de compléter le ticket JIRA précédemment créé par un commentaire afin de communiquer à Sonatype que votre staging repository est passé en « released ». Après étude, Sonatype activera la synchronisation centrale et fermera votre ticket.

Désormais, vos futures publications seront synchronisées automatiquement (pas besoin de création de ticket JIRA pour les prochaines releases).

Et l’impact du clash entre Sonatype et la Fondation Apache dans tout ça ?

La Fondation Apache et la société Sonatype sont en grand froid en ce moment (Maven Dev Mailing List : PMC change explanation). Nous ne polémiquerons pas sur le sujet. Nous n’avons pas vu d’impact sur la publication d’artefacts sur la Maven Central Repository (maven.org est géré par Sonatype, et non par la Fondation Apache).

Pour la partie « transactions & eXtreme Transaction Processing (XTP) » qui est une caractéristique remarquable des datagrids et que nous n’avons hélas pas eu le temps d’aborder, je vais voir avec Olivier Malassi si nous pouvons trouver une autre date.

Merci encore à tous ceux qui sont venus, merci pour toutes les questions et remarques qui ont permis d’enrichir la soirée. J’espère que vous avez passé un aussi bon moment que moi.

Merci encore à tous ceux qui sont venus, merci aux organisateurs. Et pour tous ceux qui ne sont pas venus à Cracovie, nous vous recommandons cette très belle conférence !

Here is the « NoSQL and In Memory Data Grids from a developer perspective » presentation we made at GeeCon 2011.

Thanks to all the people who came to listen to us, thanks to the organization team and for those who didn’t come to Krakow, we recommend you this wonderful conference!

Je présenterai lundi 23 Mai au Paris NoSQL User Group un retour d’expérience sur un projet de grille de données inter-continentale avec Oracle Coherence.

Au programme

• Valeur ajoutée d’une In Memory Data Grid (IMDG) dans une application d’informatique de gestion
• Intégration d’une IMDG dans une application existante :
  • Adaptation d’impédance : « modèle relationnel » versus « modèle hashtable / key-value store ».
  • Réutilisation des services métiers et asynchronisme des écritures en SGBD.
• Patterns de programmation avec une IMDG :
  • Modélisation des données, Domain Driven Design et traitements au cœur des données.
  • Search = code !
• Évolutivité d’une IMDG : « alter table add column » versus « versionning des structures de données ».
• Réplication inter-continentale :
  • Mise en œuvre du théorème CAP : l’abaissement de la consistance.
  • Techniques de réplication et de résolution des collisions.
• Conclusion – Maturité des In Memory Data Grids :
  • Quelle place dans le Système d’Information ? Entrepôts de données durable ou représentations optimisées de données stockées ailleurs ?
  • Technologie réservée à une élite chevronnée ou accessible à tous ?

Logistique

• L’heure : lundi 23 mai à 19h00.
• L’adresse : OCTO Technology, 50 avenue des champs E lysées, 75008 Paris.
• L’annonce sur le site du Paris NoSql User Group In Memory Data Grids – Retour d’expérience Oracle Coherence.
• Inscriptions : nous vérifions mais il ne semble pas y avoir de mécanisme d’inscription.

• Réponse 1 : Comment des éditeurs commerciaux peuvent-ils distribuer des programmes « close source » pour Linux alors que Linux utilise la licence « business unfriendly » GPL qui est censée être « contaminante » ?
• Réponse 2 : Comment CentOS peut-il distribuer gratuitement une version de Linux qui reprend quasiment toute la distribution payante Red Hat Enterprise Linux ?
• Réponse 3 : Pourquoi ai-je le droit de distribuer un logiciel « close source » qui embarque une JVM OpenJDK alors que celle-ci utilise la licence « contaminante » dérivée de la GPL ? Ai-je ce droit sur toutes les plateformes ? Y compris sur les terminaux mobiles ?
• Réponse 4 : L’Affero General Public License (aka Affero GPL) étend la notion de distribution de la licence GPL à la distribution sur le réseau. Quel est l’impact sur des sites web accessibles sur Internet ? Citer une librairie Java très connue licenciée sous AGPL ? Utilisez-vous iText ?

Comment des éditeurs commerciaux peuvent-ils distribuer des programmes « close source » pour Linux alors que Linux utilise la licence « business unfriendly » GPL qui est censée être « contaminante » ?

L’essentiel du code source de Linux est distribué sous la licence business unfriendly GPL qui est contaminante et requiert donc que le code qui lui est linké soit distribué sous une licence compatible GPL avec le code source disponible.

Cependant, pour s’exécuter sur Linux, un programme n’a pas besoin d’être compilé et/ou linké à ce code contaminant ; il lui suffit d’être compilé et linké sur les API POSIX / « Portable Operating System Interface for Unix » (e.g. cpio.h) qui ont une licence non contaminante BSD (en plus de licences LGPL et GPL) ou sur des librairies aux licences non contaminantes comme glibc (licence LGPL). Quant au compilateur GCC, il ne contamine pas non plus avec sa GCC Runtime Library Exception.

Comment CentOS peut-il distribuer gratuitement une version de Linux qui reprend quasiment toute la distribution payante Red Hat Enterprise Linux ?

Comme Noel Rocher (Red Hat / JBoss) nous l’a expliqué, Red Hat tient à disposition de ses clients RHEL le code source de l’OS ; c’est conforme à la licence GPL de Linux. En revanche, les logos et les termes Red Hat, RHEL, etc sont sous copyright Red Hat.

Il suffit aux membres du projet CentOS d’acheter une licence RHEL, de demander le source et de faire disparaitre les logos et termes copyrightés (RHEL, Red Hat, etc) pour constituer une version qu’ils ont le droit de distribuer gratuitement.

Il est donc possible d’obtenir une quasi-RHEL gratuitement mais on perd alors le support et les services que Red Hat propose à ses clients.

Pourquoi ai-je le droit de distribuer un logiciel « close source » qui embarque une JVM OpenJDK alors que celle-ci utilise la licence « contaminante » dérivée de la GPL ? Ai-je ce droit sur toutes les plateformes ? Y compris sur les terminaux mobiles ?

La JVM OpenJDK est disponible sous GNU General Public License, version 2, with the Classpath Exception. Le classpath exception protège le code qui s’exécute sur la JVM de la contamination habituelle des licences GPL. Une application peut donc être livrée avec une JVM OpenJDK sans être contaminée et donc sans devoir rendre son code source disponible sous licence compatible GPL.

Cela ressemble presque plus à une licence LGPL qu’à une licence GPL.

Pour ce qui est du monde mobile, Oracle (à l’époque Sun) n’a pas posé de classpath exception à la JVM ME (aka Mobile Edition). De ce fait, une application qui embarque une JVM ME open source d’Oracle est contaminée et doit proposer son code source sous licence compatible GPL. Cette disposition a incité les fabricants de téléphones mobiles et systèmes embarqués qui utilisaient Java ME à continuer à utiliser des JVM ME commerciale.

En revanche, rien n’interdit de bénéficier de la classpath exception en utilisant un Open JDK sur téléphone mobile ou tout autre embedded device. Le OpenJDK : Zero – Assembler Project travaille justement à porter OpenJDK sur les processeurs ARM qui sont communément utilisés dans les smartphones.

L’Affero General Public License (aka Affero GPL) étend la notion de distribution de la licence GPL à la distribution sur le réseau. Quel est l’impact sur des sites web accessibles sur Internet ? Citer une librairie Java très connue licenciée sous AGPL ? Utilisez-vous iText ?

L’Affero General Public License a été introduite en complément de la GPL pour combler l’oubli des Application Service Providers.

Cette licence stipule que la distribution ne se limite pas à la forme de binaires comme le définit la licence GPL mais concerne aussi la fourniture en mode service de ce logiciel au travers d’un réseau.

De ce fait, exposer un logiciel à des clients sous forme de services web relève d’une distribution aux yeux de l’Affero GPL. Par conséquent, une application web visible sur internet qui embarque une librairie Affero GPL est contaminée et doit rendre tout son code source disponible sous licence compatible AGPL !

Avis aux utilisateurs d’iText : la librairie est passée en dual licensing Affero GPL / commercial depuis la version 5. Si vous voulez continuer à bénéficier de la business friendly Mozilla Public License, il faut rester sur la version 2.1.7 d’iText (merci à Bertrand Dechoux pour l’historique).

A partir de mercredi prochain se déroulera à Cracovie en Pologne la conférence GeeCon qui s’affirme année après année comme un rendez-vous incontournable de la communauté Java en Europe de l’Est. Cyrille Le Clerc et Michaël Figuière y présenteront une session titrée « NoSQL & DataGrid from a Developer Perspective« , qui aura pour but d’offrir une vision claire des spécificités de ces deux technologies afin de faciliter leur choix et leur intégration au sein d’un projet.

Les bases de données NoSQL et les DataGrids sont encore rarement étudiées simultanément, aussi nous aurons très probablement l’occasion de vous reparler de ce sujet à l’avenir !

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 .

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.

Qu’est ce qu’un KawaCamp ? C’est un BarCamp dédié aux sujets qui gravitent autour de l’écosystème Java ! Et qu’est-ce qu’un BarCamp alors ? Pour résumer voici la définition de Wikipedia. Nous allons nous retrouver entre passionnés pour discuter de sujets qui nous tiennent à coeur autour de tables rondes/ateliers durant lesquels chacun participe et donne son point de vue.

Les sujets sont choisis grâce aux centres d’intérêts que chacun exprime sur la page d’inscription. Cette session s’oriente vers les sujets d’actualité avec beaucoup de HTML5 et d’Android sans oublier NoSQL, TDD, Agilité, …

Si vous aimez les discussions passionnées autour d’un verre, le KawaCamp vous comblera en organisant nos débats !

Informations pratiques :

• La page d’inscription : Kawa Camp Paris 2.
• Les organisateurs : Luc Bizeul et Philippe Antoine.
• La date : Jeudi 27 Mai 2010 à partir de 19h00.
• L’adresse : Xebia – 156 boulevard Haussmann, 75008 Paris.

Ils en parlent :

• FrAndroid – Barcamp : KawaCampParis2 .
• Le Calendrier des JDuchess.

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.

Pourquoi utilisons nous SSL ? Qu’est ce qu’une communication sécurisée ?

Il est souvent nécessaire de protéger les accès à différents services d’une application web. C’est le cas par exemple des formulaires d’authentification. Il faut donc sécuriser tout ou partie des services de l’application. Mais qu’est-ce qu’une application sécurisée ? La sécurité informatique repose sur quatre grande règles: confidentialité, intégrité, disponibilité et non répudiation. Si votre application respecte ces 4 règles, alors elle est sécurisée.

La plupart du temps, SSL est utilisé pour adresser la confidentialité et l’intégrité des communications web échangées entre le client et le serveur. Schématiquement, SSL encapsule le protocole HTTP dans un canal sécurisé. Le canal utilise un chiffrage fort qui garantie la confidentialité de la communication. Pour garantir que les données ne sont ni modifiées ni rejouées par un tiers, SSL signe et numérote les messages échangés. De plus, SSL supporte l’utilisation de certificats qui vont permettre de garantir l’identité des interlocuteurs. S’il est possible d’utiliser un certificat client pour authentifier l’utilisateur, dans la grande majorité des cas, seul le serveur possède son certificat. La mise en place de certificats clients à grande échelle, via une PKI par exemple, est un sujet à part entière que nous n’aborderons pas ici.
Dans le schéma ci-dessous, les communications provenant d’Internet sont sécurisées grâce à l’utilisation de SSL. Les communications provenant des autres serveurs de la « zone de confiance » du data center n’utilisent pas SSL. Certains estiment que cette dispense vient du fait que tous les messages doivent passer en clair dans la zone de confiance pour que les outils de sécurité puissent surveiller tout ce qui transite ; d’autres avanceront que SSL est inutile car d’autres techniques de sécurisation sont utilisées (audit de la couche réseau, gestion des permissions sur les serveurs, etc). Quelle que soit la motivation, il est fréquent de ne pas utiliser SSL pour les communications internes ; cela simplifie le tuning et le dimensionnement de nos applications.

Comment savoir en Java si une requête HTTP est sécurisée ou utilise SSL ?

L’API Servlet offre une méthode générique ServletRequest.isSecure() est ServletRequest.getScheme() qui indique le protocole utilisé : http, https, etc

Comment forcer l’utilisation de communications sécurisées (SSL) en Java

Les frameworks web communément utilisés en Java permettent de forcer de façon déclarative l’utilisation d’un canal sécurisé (ie. https) pour les requêtes entrantes. Dans les faits, ils interdisent l’accès à la ressource via un canal non sécurisé en retournant l’erreur HTTP 403. Ils peuvent aussi forcer la redirection sur HTTPS.

Spring Security

Spring Security utilise l’attribut requires-channel="https" qui est hélas légèrement trompeur puisqu’il repose sur la méthode ServletRequest.isSecure() plutôt que sur ServletRequest.getScheme() et ne vérifie donc pas l’utilisation du protocole https mais le fait que la requête est secure pour le moteur de servlet.

<beans
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sec="http://www.springframework.org/schema/security"
   xsi:schemaLocation="
    http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.xsd
   ">
   <sec:http auto-config="true">
      <sec:intercept-url pattern="/services/**" requires-channel="https" access="IS_AUTHENTICATED_FULLY" />
   </sec:http>
</beans>

Configuration Spring Security forçant SSL

API Servlet

L’API Servlet offre une approche déclarative similaire dans le fichier web.xml avec l’instruction <transport-guarantee>CONFIDENTIAL</transport-guarantee> qui repose elle aussi sur ServletRequest.isSecure().

<web-app
   xmlns="http://java.sun.com/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
   version="2.5">
   ...
   <security-constraint>
      <web-resource-collection>
         <web-resource-name>restricted web services</web-resource-name>
         <url-pattern>/services/*</url-pattern>
      </web-resource-collection>
      <user-data-constraint>
         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
      </user-data-constraint>
   </security-constraint>
   ...
</web-app>

Configuration web.xml forçant SSL

Comment transmettre au moteur de servlet l’information qu’une requête est sécurisée (SSL) ?

Puisqu’il existe deux ports standards respectivement réservés au HTTP et au HTTPS, le standard des serveurs J2EE est d’utiliser une approche multi-canaux dans laquelle un port est réservé au canal sécurisé via HTTPS et l’autre non sécurisé via HTTP.
Avec la généralisation des proxy, des load-balancers et des cartes accélératrices SSL, il est maintenant fréquent que les requêtes HTTPS soient décryptées bien avant les serveurs JavaEE sur lesquels elles arrivent en clair.

Il existe alors deux approches pour différencier les requêtes HTTP et HTTPS :

• S’inspirer de la différenciation de ports utilisés par HTTPS et HTTP en faisant emprunter des canaux différents aux requêtes sécurisées et non sécurisées, même après le décryptage des premières.
• S’inspirer de l’ajout par les proxys du header X-Forwarded-For pour propager l’adresse IP de l’appelant (cf Tomcat : Adresse IP de l’internaute, load balancer, reverse proxy et header Http X-Forwarded-For) et introduire un header X-Forwarded-Proto pour indiquer le protocole utilisé.

Configuration multi-canaux : utiliser des connecteurs/ports différents

L’approche historique de Tomcat pour différencier les requêtes qui sont entrées en HTTPS de celles qui sont entrées en HTTP est de définir plusieurs connecteurs. Cette approche permet aussi bien de gérer l’encryption SSL dans Tomcat que, depuis la version 6, de la faire en amont dans le serveur web ou un load balancer hardware par exemple. Dans ce deuxième cas, un connecteur est configuré pour recevoir des communications en HTTP tout en valorisant request.isSecure() à true et request.getScheme() à https.

Hélas, cette configuration rend la gestion de requêtes sécurisées non SSL (<Connector ... secure="true" scheme="http" />) très délicate, car la spécification Servlet stipule que le conteneur doit émettre un cookie de session ‘secure’ si la requête HTTP à l’occasion de laquelle la session a été créée est ‘request.secure = true’.
Le problème vient du fait que des clients HTTP comme Jakarta Commons Http Client traitent automatiquement les connections non SSL comme non sécurisées et ne renvoient donc pas le cookie JSESSIONID pour les appels non SSL même si celui ci a été défini comme secure par le conteneur. La définition de requêtes comme sécurisée mais non SSL est alors incompatible avec l’utilisation de sessions http avec une erreur très difficile à diagnostiquer. Du fait de ce problème, nous ne traiterons pas dans ce billet de la configuration Tomcat multi-canaux pour gérer les requêtes sécurisées qui n’utilisent pas SSL.

Exemple de configuration Tomcat multi-connecteurs pour dissocier les requêtes HTTP de requêtes HTTPS :

<server>
   ...
   <Service name="Catalina">
      <!-- Connecteur pour les requêtes non SSL -->
      <Connector ... scheme="http" />
      <!-- Connecteur pour les requêtes SSL -->
      <Connector ... secure="true" scheme="https" />
      ...
</server>

Extrait de server.xml utilisant les attributs secure et scheme pour différencier les requêtes SSL

Configuration mono-canal avec header HTTP : utiliser le header X-Forwarded-Proto

Une autre approche, disponible dès le prochain Tomcat 6.0.21, est d’utiliser un header http pour indiquer si le protocole était http ou https. Ce header est communément nommé X-Forwarded-Proto: https|http (Microsoft Internet Security and Acceleration Server utilise Front-End-HTTPS:on|off). Ce header est souvent associé au header X-Forwarded-For déjà utilisé par les load balancers et proxys pour transmettre l’adresse IP de l’appelant.

Pour prévenir tout ‘spoofing‘ des requêtes, il faut s’assurer que les points d’entrée HTTP/HTTPS de la plate-forme écrasent la valeur de ce header http X-Forwarded-Proto avec le protocole utilisé (http ou https) ; il s’agit de supprimer les headers nommés X-Forwarded-Proto s’ils existent et d’en insérer un nouveau ; omettre l’étape de suppression des headers X-Forwarded-Proto éventuellement existants serait une faille de sécurité.

Gestion du header X-Forwarded-Proto avec une valve Tomcat

La solution la plus simple pour gérer le header X-Forwarded-Proto sur un serveur Tomcat est de déclarer la valve RemoteIpValve dans le serveur Tomcat :

1. En attendant Tomcat 6.0.21 qui embarquera la RemoteIpValve, télécharger xebia-tomcat-extras-1.0.0.jar ou compiler RemoteIpValve.java et déployer le jar sous TOMCAT_HOME/lib.
2. Déclarer la RemoteIpValve (doc) dans server.xml. Cette valve doit être déclarée avant les autres valves qui s’appuient sur le protocole ou l’adresse IP de l’internaute. Il est possible de déclarer aussi la SecuredRemoteAddressValve (doc, également incluse dans xebia-tomcat-extras-1.0.0.jar) pour bénéficier du mécanisme de requête sécurisée non SSL :

<Server ...>
   ...
   <Service name="Catalina">
      <Connector ... />
      <Engine ...>
         <!-- Process x-Forwarded-For to get remote address and X-Forwarded-Proto to identify SSL requests -->
         <Valve className="org.apache.catalina.connector.RemoteIpValve" protocolHeader="X-Forwarded-Proto" />
         <!-- Flag as secure all requests coming from private network IP address blocks. Must be declared after RemoteIpValve -->
         <Valve className="org.apache.catalina.connector.SecuredRemoteAddressValve" />
         <!-- AccessLogValve must be declared after RemoteIpValve to get the remote address and the scheme https/http -->
         <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" pattern="common" prefix="access_log."
            resolveHosts="false" suffix=".txt" />
         ...
         </Host>
      </Engine>
   </Service>
</Server>

Gestion de SSL et des communications sécurisées avec des valves Tomcat

Gestion du header X-Forwarded-Proto avec un filtre Servlet API

Si vous ne pouvez pas changer la configuration Tomcat ou si vous utilisez un autre moteur de servlet (Glassfish, Websphere, Weblogic, etc), il est possible de gérer le header X-Forwarded-For grâce à un Servlet Filter de l’application web :

1. Télécharger xebia-servlet-extras-1.0.2.jar, compiler XForwardedFilter.java ou ajouter la dépendance maven fr.xebia.web.extras:xebia-servlet-extras:1.0.2 à votre pom.xml (doc).
2. Déclarer XForwardedFilter (doc) dans web.xml Cet filtre doit être déclaré avant les autres filtres qui s’appuient sur le protocole ou l’adresse IP de l’internaute. Il est possible de déclarer aussi le SecuredRemoteAddressFilter (doc, intégré dans xebia-servlet-extras-1.0.2.jar) pour gérer les requêtes sécurisées non SSL :

<web-app ...>
   ...
   <filter>
      <filter-name>XForwardedFilter</filter-name>
      <description>Process x-Forwarded-For to get remote address and X-Forwarded-Proto to identify SSL requests</description>
      <filter-class>fr.xebia.servlet.filter.XForwardedFilter</filter-class>
      <init-param>
         <param-name>protocolHeader</param-name>
         <param-value>x-forwarded-proto</param-value>
      </init-param>
   </filter>
   <filter>
      <filter-name>SecuredRemoteAddressFilter</filter-name>
      <description>Flag as secure all requests coming from private network IP address blocks.
Must be declared after XForwardedFilter</description>
      <filter-class>fr.xebia.servlet.filter.SecuredRemoteAddressFilter</filter-class>
   </filter>
   <filter-mapping>
      <filter-name>XForwardedFilter</filter-name>
      <url-pattern>/*</url-pattern>
      <dispatcher>REQUEST</dispatcher>
   </filter-mapping>
   <filter-mapping>
      <filter-name>SecuredRemoteAddressFilter</filter-name>
      <url-pattern>/*</url-pattern>
      <dispatcher>REQUEST</dispatcher>
   </filter-mapping>
   ...
</web-app>

Gestion de SSL et des communications sécurisées avec des Servlet Filters

Mise en oeuvre multi-canaux et header X-Forwarded-Proto suivant les topologies Tomcat

Topologie Load Balancer Hardware Apache Httpd Tomcat

Il est très fréquent, lorsqu’une application web doit être hautement disponible, de faire précéder les serveurs web d’un Load Balancer Hardware qui devient alors un Single Point Of Failure extrêmement fiable. Nous prendrons pour ce paragraphe l’hypothèse que le load balancer hardware prend en charge l’encryption HTTPS.

Remarque SSL et load balancer

La pertinence de gérer SSL dans le load balancer est très discutée ; certains y sont farouchement opposés (cf loadbalancing.org), d’autres sont plus mesurés (c.f. HAProxy) et enfin les vendeurs de load balancers hardware y sont très favorables . Ce débat, qui porte aussi sur la pertinence de déléguer la compression (aka gzip ou deflate) au load balancer, dépasse le cadre de ce billet et le domaine de compétence des architectes applicatifs. Pour aller plus loin, nous vous recommandons Making applications scalable with Load Balancing de Willy Tarreau (HA Proxy).

Remarque Apache et mod_proxy_http

Nous utiliserons dans ce billet Apache Httpd en version 2.2.11 avec le connecteur mod_proxy_http / mod_proxy_balancer. Il serait également possible d’utiliser le protocole AJP (avec mod_jk, mod_proxy_ajp ou mod_cluster) ; nous expliquerons notre préférence pour mod_proxy_http dans un prochain billet.

Gestion du paramètre X-Forwarded-Proto dans les load balancers

L’utilisation du header X-Forwarded-Proto nécessite une configuration très simple : le load balancer valorise le header X-Forwarded-Proto, les serveurs web et Tomcat écoutent sur un seul port et la RemoteIpValve Tomcat (ou le XForwardedFilter) traite le header X-Forwarded-Proto pour valoriser request.isSecure() et request.getScheme() .

Note : cette approche permet très facilement de gérer les communications sécurisées non SSL en utilisant une SecuredRemoteAddressValve Tomcat (ou un SecuredRemoteAddressFilter) qui marquera request.isSecure() des requêtes non SSL émises depuis des plages d’adresses IP pré-déterminées.

Sur un F5 Big-IP, le header X-Forwarded-Proto sera défini grâce à une iRule de type :

when HTTP_REQUEST {
   HTTP::header remove X-Forwarded-Proto
   HTTP::header insert X-Forwarded-Proto http
}
when HTTPS_REQUEST {
   HTTP::header remove X-Forwarded-Proto
   HTTP::header insert X-Forwarded-Proto https
}

Source : F5 DevCentral wiki – HTTP::header

Astuce Big-IP iRules: ‘remove’ versus ‘replace’

Par rigueur, nous avons préféré utiliser HTTP::header remove puis HTTP::header insert plutôt que HTTP::header replace qui ne traite que la première occurence du header. Si une personne malveillante injecte plusieurs headers X-Forwarded-Proto, HTTP::header replace n’écrasera que la première occurence alors que le duo HTTP::header remove & HTTP::header insert les supprimera toutes avant d’en insérer une valide.

La configuration du serveur Http est alors triviale, il suffit d’écouter sur le seul port 80 et de transmettre au serveur Tomcat en passe plat.

..
# 'myapplication' cluster
<Proxy balancer://myapplication>
   BalancerMember      http://node-1:8080 route=node-1
   ...
   BalancerMember      http://node-n:8080 route=node-n
</Proxy>
ProxyPreserveHost On
ProxyPass /mypath balancer://myapplication/mypath stickysession=JSESSIONID

Configuration Apache httpd.conf

Gestion multi-canaux depuis le load balancer

La configuration multi-canaux du load balancer nécessite une configuration plus lourde des serveurs Apache et Tomcat puisque le nombre de canaux (port d’écoute, etc) est doublé.

# 'myapplication' non ssl and ssl clusters
<Proxy balancer://myapplication>
   BalancerMember      http://node-1:8080 route=node-1
   ...
   BalancerMember      http://node-n:8080 route=node-n
</Proxy>
<Proxy balancer://myapplicationssl>
   BalancerMember      http://node-1:8083 route=node-1
   ...
   BalancerMember      http://node-n:8083 route=node-n
</Proxy>
<VirtualHost default:80>
   ...
   ProxyPreserveHost On
   ProxyPass /mypath balancer://myapplication/mypath stickysession=JSESSIONID
   ...
</VirtualHost>
<VirtualHost default:83>
   ...
   ProxyPreserveHost On
   ProxyPass /mypath balancer://myapplicationssl/mypath stickysession=JSESSIONID
   ...
</VirtualHost>

Configuration Apache httpd.conf multi canaux

Topologie Apache Httpd – Tomcat

Gestion du paramètre X-Forwarded-Proto dans Apache

Bien qu’il soit possible de décrypter SSL sur les serveur web Apache Httpd, nous préférons largement la déléguer au load balancer pour les raisons suivantes :

• Sécurité : la passphrase d’un certificat SSL est un secret très sensible qu’il est plus facile de gérer sur un nombre très limité de load balancers à l’accès très restreint plutôt que sur les serveurs web qui sont plus nombreux et sur lesquels de nombreuses équipes interviennent. Il est certes possible de protéger la passphrase d’un serveur Apache en limitant l’acccès au user root mais on voit souvent sur le terrain le user root de serveur web utilisé par beaucoup d’intervenants pour faciliter le travail au quotidien. Il est beaucoup plus simple de limiter les accès sur des serveurs ultra spécialisés comme les load balancers.
• Performance : HTTPS est très consommateur en CPU et son tuning est délicat (réutilisation des sessions SSL, etc). Pour plus de détails, Apache Con EU 2008 – Apache Performance Tuning par Sander Temme.
• Simplicité : grâce à l’utilisation d’un header X-Forwarded-Proto pour indiquer le protocole utilisé, la configuration du serveur se limite au seul port d’écoute 80.

Si vous avez malgré tout besoin de décrypter HTTPS dans les serveurs web, voici un exemple de configuration Apache Httpd.

# 'myapplication' cluster
<Proxy balancer://myapplication>
   BalancerMember      http://node-1:8080 route=node-1
   ...
   BalancerMember      http://node-n:8080 route=node-n
</Proxy>
<VirtualHost default:80>
# Declare X-Forwarded-Proto as "http" for incoming request
RequestHeader set X-Forwarded-Proto "http"
...
</VirtualHost>
<VirtualHost default:443>
# mod_ssl configuration
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile "/private/etc/apache2/server.crt"
SSLCertificateKeyFile "/private/etc/apache2/server.key"
# Overwrite X-Forwarded-Proto declaration for port 443, request are "https"
RequestHeader set X-Forwarded-Proto "https"
...
</VirtualHost>
..
ProxyPreserveHost On
ProxyPass /mypath balancer://myapplicationssl/mypath stickysession=JSESSIONID

Configuration Apache httpd.conf portant le header X-Forwarded-Proto

Remarque Apache Httpd : Il n’est pas possible de déclarer deux points de configuraiton pour un même <VirtualHost />, par conséquent, si votre configuration référence un fragment extra/httpd-ssl.conf pour gérer SSL, vous devez modifier ce fragment pour ajouter la directive RequestHeader set ..., plutôt que d’utiliser un fragment ‘maison’ extra/httpd-myconfig.conf.

Gestion multi-réseaux

La gestion multi-réseaux avec Apache n’est pas particulièrement compliquée mais introduit une duplication de code verbeux qu’il est agréable d’éviter car il faut déclarer deux balancers qui ne diffèrent que par leur port d’écoute.

# 'myapplication' non ssl and ssl clusters
<Proxy balancer://myapplication>
   BalancerMember      http://node-1:8080 route=node-1
   ...
   BalancerMember      http://node-n:8080 route=node-n
</Proxy>
<Proxy balancer://myapplicationssl>
   BalancerMember      http://node-1:8083 route=node-1
   ...
   BalancerMember      http://node-n:8083 route=node-n
</Proxy>
<VirtualHost default:80>
   ...
   ProxyPreserveHost On
   ProxyPass /mypath balancer://myapplication/mypath stickysession=JSESSIONID
   ...
</VirtualHost>
<VirtualHost default:443>
   SSLEngine on
   SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
   SSLCertificateFile "/private/etc/apache2/server.crt"
   SSLCertificateKeyFile "/private/etc/apache2/server.key"
   ...
   ProxyPreserveHost On
   ProxyPass /mypath balancer://myapplicationssl/mypath stickysession=JSESSIONID
   ...
</VirtualHost>

Configuration Apache httpd.conf multi canaux

Tomcat seul

L’utilisation de Tomcat seul, sans serveur web ni load balancer en amont, simplifie le choix. Tomcat écoute à la fois en http et https (généralement respectivement les ports 80 et 443). Seule l’approche multi-connecteurs s’applique. La littérature regorge de mises en oeuvre de SSL avec Tomcat. Le principal point d’attention est la délégation de l’encryption SSL à OpenSSL grâce au connecteur APR (Http11AprConnector) plutôt que de reposer sur l’implémentation SSL des JVM (JSSE) qui est beaucoup moins performante.

<server>
   ...
   <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" SSLRandomSeed="builtin" />
   ...
   <Service name="Catalina">
      <Connector protocol="org.apache.coyote.http11.Http11AprProtocol"
           port="8443" minSpareThreads="5" maxSpareThreads="75"
           enableLookups="true" disableUploadTimeout="true"
           acceptCount="100"  maxThreads="200"
           scheme="https" secure="true" SSLEnabled="true"
           SSLCertificateFile="/usr/local/ssl/server.crt"
           SSLCertificateKeyFile="/usr/local/ssl/server.pem"
           clientAuth="false" sslProtocol="TLS"/>
      ...
</server>

Extrait de server.xml

Astuce : comment éviter de démarrer le serveur Tomcat avec les privilèges root ?

Sur les serveur Unix/Linux, écouter sur les ports <1024 requiert les privilèges root ; faire écouter un serveur Tomcat sur les ports 80 (http) et 443 (https) devient donc très délicat pour la sécurité de la plate-forme. Une astuce est d'utiliser iptables pour faire du port forwarding de 80 et 443 vers 8080 et 8443. Plus de détails dans Tomcat Wiki - How to run Tomcat without root priviledges? ou Rife - Installing Tomcat on port 80 with iptables.

Que choisir ? Multi-canaux ou header X-Forwarded-Proto ?

Si l'approche multi-canaux avec un premier connecteur pour les communications non http et un second pour les communications https/ssl a le mérite d'être l'approche "historique", elle présente les défauts de :

• ne pas gérer les communications sécurisées non http,
• complexifier sensiblement les configurations Apache Httpd et, dans une moindre mesure, Tomcat.

Notre préférence va à l'utilisation d'un header http X-Forwarded-Proto qui permet de simplifier les configurations Apache Httpd et Tomcat et aussi de permettre des communications sécurisées non SSL.

L'argument d'une complexification de la configuration Tomcat par l'ajout de la RemoteIpValve (ou du XForwardedFilter) est discutable puisque cette valve est la plupart du temps nécessaire pour gérer le header X-Forwarded-For qui permet d'obtenir l'adresse IP de l'internaute, élément important pour l'audit d'actions qui requièrent SSL.

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.