4 février 2010
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 »
16 novembre 2009
Chez XebiaLabs, nous nous y connaissons en déploiement automatique d’applications Java EE. L’une des choses les plus surprenantes réside dans le fait que «les fournisseurs de serveurs d’application ne semblent pas faire partie des personnes qui maitrisent le mieux le déploiement d’applications».
Dans un article précédent, nous avons décrit ce que nous considérons comme le déploiement d’application J2EE global. Et force est de constater que:
- Déployer va bien au delà d’un simple déploiement d’un EAR ou d’un WAR.
- La plupart des applications ont également besoin d’autres artéfacts comme par exemple du contenu statique pour le serveur web ou encore des fichiers de configuration, utilisés par le code java, au démarrage.
- Il faut également configurer des ressources JEE comme des Datasources JDBC ou des composants JMS (Queues, Topics, Servers).
- A ceci s’ajoute, bien entendu, la configuration du middleware lui-même: création et configuration de clusters de serveurs d’application ou de virtual hosts d’un serveur Apache.
- L’ordre d’exécution des tâches est important afin de réduire (voire de prévenir) la coupure de service de l’application pendant le déploiement et d’en augmenter la vitesse.
Alors posons nous la question. Que nous proposent les fournisseurs de serveurs d’application dans ce domaine ?
Lire la suite de cet article »
20 octobre 2009
Vous venez juste de boucler la première version de votre application, packagée par Maven. Vos intégrateurs ont préparé un environnement de recette et vous ont communiqué les informations de connexion à la console d’administration de votre serveur d’applications. Vous vous connectez, accédez aux fonctionnalités de déploiement et déployez le fichier EAR. Satisfait, vous démarrez votre navigateur pour vérifier que l’application tourne correctement. Mais quand vous essayez de charger la page, vous obtenez l’erreur DNS « Host not found ». C’est donc le moment d’appeler un ami – l’administrateur de cette obscure infrastructure, qu’on appellera Michel. Michel est bien sûr très heureux d’ajouter un enregistrement DNS qui va permettre d’aller sur le serveur Apache à partir de l’URL www.app-in-dev.com. « Quoi ! Un serveur Apache ? » vous exclamez vous, « Mais ça devrait pointer vers notre serveur d’applications, pas du tout vers un quelconque serveur HTTP ! ».
Michel, qui a l’habitude de ce genre d’exclamation vis-à-vis de l’organisation des réseaux d’entreprise, explique calmement que toutes les requêtes partant d’un navigateur doivent d’abord passer par un serveur HTTP avant d’être redirigées vers le serveur d’applications. « Il est donc aussi nécessaire de configurer Apache ! », dit-il. « Mais je développe une application Java, j’ai juste besoin de déployer sur un serveur d’applications et hop, terminé ! » répondez vous. Et Michel d’expliquer sur un ton très sérieux : « Écoute fiston, appuyer sur le bouton de déploiement de ta console d’administration est juste une petite étape parmi toutes celles qui permettent de réaliser un vrai déploiement. »
Lire la suite de cet article »
11 septembre 2009
A l’Atelier BNP PARIBAS, Xebia présentera sa solution de déploiement automatique DeployIT commercialisée par sa filiale XebiaLabs.
Intervenants :
- M. Guillaume Bodet, Directeur Technique, Xebia
Informations utiles :
25 août 2009
Le groupe Xebia a créé en Juin 2009, Xebia Labs une société de droit néerlandais dont les actionnaires sont Xebia NL, Coert Baart, Vincent Partington et Luc Legardeur.
Erreurs humaines, interventions « pompier », manque de prédictibilité, complexité des guides et procédures de mise en production, manque d’évolutivité des scripts, frictions entre les départements Etudes et Production, mises à jour des middleware et des applicatifs coûteuses sont autant de maux que rencontrent les utilisateurs des technologies Java/J2EE.
Fort de nos 8 ans d’expérience dans la conception, la mise en place et la gestion d’applications et d’infrastructures basées sur Java/J2EE chez plus de 200 clients en Europe, Xebia a créé DeployIT, une offre logicielle, exclusivement dédiée aux déploiements Java/J2EE.
DeployIT permet de sécuriser et de réduire les coûts des déploiements des applications et des infrastructures Java/J2EE, jugés de plus en plus périlleux, coûteux et aléatoires.
Xebia Labs propose donc une plateforme logicielle incluant les spécificités des applications et infrastructures Java/J2EE, adossée à une approche méthodologique éprouvée, offrant les avantages suivants :
- Réduction des risques d’échecs des déploiements liés aux trop nombreuses interventions humaines.
- Réduction des coûts liés au développement et à la maintenance de scripts coûteux et hétérogènes.
- Suppression des interventions « pompier » des équipes de développement pour aider les cellules d’exploitation à mettre en production.
- Réduction du Time to Market des nouvelles applications ainsi que de leurs évolutions fonctionnelles.
- Standardisation autour d’un outil commun des départements Etudes et Production.
- Garantie des SLA par une professionnalisation de la filière de déploiement.
Pour avoir plus d’informations sur cette solution, n’hésitez pas à contacter Luc Legardeur au 01 42 91 27 93 ou par mail : llegardeur@xebia.fr.
5 mai 2009
Une conférence est l’occasion de discuter avec les ingénieurs des difficultés que nous rencontrons à utiliser leurs produits. J’ai profité de ma participation à SpringOne 2009 pour échanger avec Mark Thomas sur le suivi de l’adresse IP des internautes dans les logs d’audit d’applications web. Mark Thomas est des principaux committer du projet Tomcat et de SpringSource tc Server.
Le problème se présente lorsqu’un serveur Tomcat est précédé d’un reverse proxy (e.g. mod_proxy, Squid Cache, etc) ou d’un load balancer (Nortel Alteon, F5 Big-IP, etc) : La méthode HttpServletRequest.getRemoteAddr() ne retourne plus l’adresse IP de l’internaute mais celle du composant réseau qui précède le serveur Tomcat.
Cette perte d’information a été compensée par les reverse-proxy en ajoutant un header http X-Forwarded-For à toutes les requêtes qu’ils font transiter. Bien que ce header ne soit pas standard (son nom commence d’ailleurs par « X- »), il est devenu un standard de facto utilisé par la très grande majorité des reverse proxy et load balancers (paramètre xforward=enable pour les Alteon d’après Command Reference ; propriété Insert XForwarded For de la GUI du profile http ou règle when HTTP_REQUEST { HTTP::header insert "X-Forwarded-For" [IP::client_addr] } pour les Big-IP d’après F5 Dev Central : Using « X-Forwarded-For » in Apache or PHP ).
Cependant, les implémentations de l’API Servlet ne sont pas tenues de prendre en compte ce paramètre dans la méthode request.getRemoteAddr() dont la javadoc stipule bien Returns the Internet Protocol (IP) address of the client or last proxy that sent the request. . Tomcat est d’ailleurs autant concerné que ses concurrents Websphere ou Weblogic, pour ne citer qu’eux.
Toutes les couches sont impactées : l’Access Log Tomcat dont les patterns common et combined utilisent le remote host name (%h) et les frameworks de sécurité et d’audit comme Spring Security (cf WebAuthenticationDetails.getRemoteAddress()) ou CAS Inskektr ClientInfo).
Lire la suite de cet article »
3 décembre 2008
Gérer les modifications d’une base de données est toujours une affaire délicate, que ce soit lors du développement d’une application, pendant le déroulement des tests unitaires et même lors du déploiement en production.
On observe un grand nombre de difficultés, en particulier dans les projets Agile, où les changements sur le modèle de données sont fréquents.
A l’heure actuelle, peu d’outils sont disponibles sur le marché et on pense rarement à les mettre en place sur nos projets. On passe par des solutions « maisons » avec toutes les difficultés que cela peut engendrer.
Tout d’abord, nous ferons un point sur les problèmes posés par la gestion des bases de données, puis nous verrons comment Liquibase, outils de refactorisation, peut nous aider à les surmonter.
Nous continuerons par la description de ses caractéristiques et fonctionnalités principales et par les différents moyens de l’exécuter.
Un petit exercice pour se familiariser avec cet outil viendra conclure ce billet.
Lire la suite de cet article »
1 octobre 2008
Voici la liste des billets les plus lus sur ce blog en juillet, août et septembre :
Tout au long du cycle de vie d’une application J2EE, il est nécessaire de posséder des traces de qualité :
- durant le développement, afin de suivre l’exécution pas à pas et de détecter d’éventuelles anomalies.
- durant la recette, afin de corréler anomalies fonctionnelles et exécution du programme.
- durant l’exploitation, afin de surveiller la « bonne santé » de l’application.
Mais obtenir des traces de qualité n’est pas un exercice trivial. C’est pourquoi nous vous proposons nos 10 commandements des logs.
Lire cet article »
Spring 2.5 est sorti depuis le 19 novembre 2007 comme nous l’annoncions, il y a quelques temps, dans notre revue de presse. Vous avez comme moi sagement mis à jour vos poms Maven2 vers la dernière release de Spring (normalement et la plupart du temps compatible avec les versions 2.0.x).
Mais avez-vous vraiment profité des nouveautés de cette version en terme de configuration ?
Lire cet article »
Jouer avec les Threads n’est pas trivial. En informatique de gestion, cette difficulté est heureusement masquée par les serveurs d’application et les API spécifiques. La plupart du temps, ils permettent aux développeurs de s’abstraire de ces contraintes et de se concentrer sur le code métier, moins technique. Il arrive pourtant qu’il faille se relever les manches. Certains besoins vous ont certainement déjà poussé à faire communiquer 2 Threads.
Si le développement n’est pas facile, le debug peut devenir une calamité ! La programmation concurrente ne soulève pourtant que 3 types majeurs de problèmes. Faites le sondage autour de vous, les développeurs associent trop rapidement le mot clé synchronize au multithreading sans en comprendre véritablement le fonctionnement. Demandez-leur ensuite de vous décrire l’utilité du mot clé volatile …
Cet article revient sur les grands principes de la programmation concurrente.
Lire cet article »
11 juillet 2008
Tout au long du cycle de vie d’une application J2EE, il est nécessaire de posséder des traces de qualité :
- durant le développement, afin de suivre l’exécution pas à pas et de détecter d’éventuelles anomalies.
- durant la recette, afin de corréler anomalies fonctionnelles et exécution du programme.
- durant l’exploitation, afin de surveiller la « bonne santé » de l’application.
Mais obtenir des traces de qualité n’est pas un exercice trivial. C’est pourquoi nous vous proposons nos 10 commandements des logs.
Une application J2EE possède de nombreux types de logs :
- Des logs purement techniques, ponctuelles, générées automatiquement ou à la demande comme les dumps (ThreadDump, MemoryDump…).
- Des logs provenant de l’environnement d’exécution : logs Système (journaux d’évènements serveur…), logs du serveur applicatif et logs générées par les librairies tierces utilisées par l’application.
- Les logs générées par le code développé pour l’application, que nous désignerons comme logs applicatives, sur lesquelles l’équipe projet a la main.
Nous traiterons quasi exclusivement de ces dernières dans cet article.
Lire la suite de cet article »
28 mai 2008
La MOE et l’exploitation doivent collaborer au jour le jour : la MOE réalise et livre des applications, l’exploitation est en charge de les installer et de les exploiter. Cependant, ces deux équipes, bien qu’elles travaillent dans le même but, n’ont pas les mêmes besoins ni les mêmes problématiques.
Cette divergence n’est pas dramatique tant que la collaboration se passe bien : la MOE est consciente des besoins de l’exploitation et en tient compte en simplifiant la prise en charge des applications par les équipes d’exploitation. Les choses se compliquent bien sûr quand les problèmes et les mésententes arrivent.
Un des problèmes récurrents qui fait intervenir les deux équipes est le déploiement des applications.
Lire la suite de cet article »
