Dans un précédent article sur le déploiement, j’ai présenté l’ensemble des tâches à mettre en œuvre pour déployer une application Java dans un environnement d’entreprise. Le scénario décrivait étape après étape la configuration de chaque composant comme les serveurs web, les pare-feux, la base de données et les ressources externes JEE. Le point clé à retenir était que ces différentes configurations de composants avaient autant d’importance dans un déploiement que l’installation d’un fichier EAR ou WAR.
Mais voilà, comme on l’avait rapidement suggéré précédemment, il existe un scénario légèrement plus compliqué que celui décrit ci-dessus ; il s’agit du cas de mise à jour d’une application vers une nouvelle version. Bien que le déploiement initial d’une application soit forcément important, un certain nombre de raisons me fait penser que le déploiement d’une nouvelle version l’est encore plus.
Lire la suite de cet article »
Après avoir abordé la gestion des fichiers de logs, nous continuons aujourd’hui la série « Applications Java prêtes pour la Production » avec l’audit.
Par audit, nous entendons l’audit des actions importantes réalisées sur une application.
Pourquoi auditer ?
Est-il vraiment utile de générer des informations d’audit dans nos applications ? Sans explications de juriste, quelques exemples suffiront à nous en convaincre :
- Un site web de partage de photos doit pouvoir dire qui a uploadé quelle image, depuis quelle adresse IP et à quelle date.
- L’application d’administration d’un site de e-commerce doit tracer toutes les modifications de prix pour empêcher un employé astucieux de baisser à 1 euro le prix de son téléphone préféré le temps de passer commande.
Pour revenir à des explications plus théoriques, les logs d’audit nous apportent :
- les informations nécessaires à la justice en cas d’infraction,
- la détection d’intrusions,
- la reconstitution des événements en complément des logs d’exceptions pour aider au diagnostique de problèmes.
Nous nous placerons dans le cas le plus fréquent où nous ne développons pas d’outil pour consulter ces informations d’audit et où un accès direct au média de stockage (grep sur fichier texte, sql sur base de données, etc) suffit.
Lire la suite de cet article »
Tout a déjà été dit sur les logs. Pour preuve, ce n’est plus un sujet chaud, les équipes d’exploitation sont très contentes avec les logs de nos applications 
.
D’accord, l’envers du décor est moins reluisant et il reste une marge de progression. Nous avions proposé dans Les 10 commandements des logs applicatives des suggestions focalisées sur le contenu des fichiers de logs ; voici aujourd’hui des propositions pour gérer les fichiers eux-mêmes. Même si le sujet peut sembler trivial, ces bonnes pratiques peuvent grandement simplifier le quotidien des équipes de production et améliorer les relations tumultueuses entre exploitants et développeurs.
Au risque de surprendre certains, les exemples de ce billet utilisent Logback plutôt que le standard de-facto Log4j car certaines bonnes pratiques que je proposerai sont impossibles à mettre en oeuvre avec Log4j. Aujourd’hui, je préfère utiliser Logback à Log4j pour gérer les logs de mes applications … même si je suis nostalgique du format ‘.properties’ pour la configuration de ces dernières .
Bien que Logback ne soit pas le sujet de ce billet, j’ai ajouté à l’article initial un paragraphe « Pourquoi je préfère Logback à Log4j » pour expliquer ce choix.
Lire la suite de cet article »
3ème épisode de notre série. Il est temps pour notre magnifique application de dépasser la barre symbolique de l’utilisateur unique. Mais comme nous nous sentons confiants et forts, nous allons pousser le vice de passer à, tenez vous bien, 5 utilisateurs concurrents. Et comme certains diraient, « Et là, c’est le drame ». Les temps se dégradent à vitesse grand V.
Lire la suite de cet article »
Xebia organise le 12 Avril à partir de 19h, une soirée « Les dix bonnes pratiques des applications Java prêtes pour la production » suivie d’un cocktail.
Cette soirée gratuite vous permettra d’appréhender les bonnes pratiques que se doivent de respecter les Directions Etudes et Développement pour rendre leurs applications Java/J2EE prêtes pour la production.
Elle se déroulera dans les locaux de Xebia : 156, boulevard Haussmann, 75008 Paris.
Les inscriptions peuvent se faire :
Lire la suite de cet article »
Nous sommes heureux de vous proposer le nouveau catalogue de formation Xebia Traning :
Xebia Training se positionne logiquement dans la continuité de Xebia, tant sur la qualité de son offre de formation technique que méthodologique (méthodes agiles), en proposant des formations haut de gamme animées uniquement par les référents de leur domaine.
Avec pour principe premier le refus de tout compromis sur la qualité du formateur et du contenu, Xebia Training fait systématiquement intervenir des acteurs de références dans leurs domaines respectifs.
Nos formations, savant équilibre entre théorie et travaux pratiques, sont destinées à un large public soucieux d’acquérir les meilleures pratiques de notre industrie.
Suite de nos investigations sur l’application PetClinic dégradée.
Après une première passe qui nous a permis de calibrer les logs de manière un peu plus pertinente, il est temps, toujours sans l’aide du code source, de mettre les mains sous le capot de Tomcat (6.0.20).
Et pour cela, rien de mieux que de jeter de nouveau un œil à notre VisualVm.
Tant de threads pour un seul utilisateur.
Pour (re)commencer, penchons nous sur nos threads, juste après le démarrage du serveur (et donc avant la première connexion d’un utilisateur)
Lorsque l’on démarre un serveur Tomcat, un certain nombre de threads sont affectés à sa ‘tuyauterie’ interne (connecteurs RMI, JMX). Mais de là à avoir 165 threads, il y a certainement un souci quelque part !
Creusons un peu, et entrons dans le détail de ces threads en utilisant l’onglet Threads.
Lire la suite de cet article »
Le 1er février dernier, XebiaLabs a mis en ligne une version dite « Personnelle » de « Deployit », sa solution d’automatisation des déploiements J2EE.
Cette version est gratuite et possède toutes les fonctionnalités de la version Enterprise, exception faite des aspects sécurité. Elle inclut une licence permettant à un utilisateur unique et identifié d’utiliser l’outil, sans limitations. Deployit Personal Edition inclut en standard des plugins pour IBM WebSphere AS, Oracle WebLogic Server et JBoss AS. Cette version peut être téléchargée gratuitement avec sa documentation et des tutoriels permettant de comprendre son fonctionnement.
Par ailleurs, avec Deployit Personal Edition, vous avez tout à disposition pour développer vos propres plugins : la documentation de l’API de plugin, les tutoriels et le code source des plugins existants. Enfin, en plus du support technique fourni via le web, notre équipe support peut être contactée gratuitement pendant 90 jours !
Lire la suite de cet article »
Dans notre article sur l’utilisation de HTTPS avec Tomcat en production, nous avons étudié les solutions reposant sur la mise en place d’un reverse proxy HTTP. Nous n’avons pas oublié pour autant le protocole AJP. Ce protocole est né pour faciliter et accélérer les communications entre un serveur web frontal et le serveur d’application JServ en back-end d’Apache. Avec le temps, Tomcat a remplacé Apache JServ mais AJP est resté. Jusqu’en 2003, AJP était la seule solution viable permettant de placer le serveur d’application derrière un serveur Apache. Avec la maturation de la fonctionnalité Proxy dans Apache est née la solution tout HTTP. Nous avons donc décidé d’organiser un match opposant la solution AJP à la solution HTTP.
Lire la suite de cet article »
Complet
Twitter
