Application Java et Production
Lundi 12 avril avait lieu dans les locaux de Xebia une présentation sur « les applications Java et la production » animée par Cyrille Le Clerc. Cette formation de deux heures était très intéressante, si le sujet vous intéresse et que vous êtes sur Paris, ils en refont une le lundi 26 avril http://training.xebia.fr/soiree-les-applications-java-et-la-production.
Cinq pôles principaux ont été abordés : les bonnes pratiques autour du déploiement, la supervision et le monitoring, la gestion des logs, la question de la robustesse et les bonnes pratiques organisationnelles. Seul le déploiement sera abordé dans cet article, la suite suivra !
Cyrille Le Clerc est architecte EE depuis 11 ans, dont 6 ans passé chez IBM Global Services et un peu plus de 3 ans chez Xebia.
Minimiser le nombre de composants à déployer
Au niveau du déploiement, la première bonne pratique est de minimiser le nombre de composants à déployer. Ce qui ne veut pas dire qu’il faut déployer des applications monolithiques mais bien qu’il est important de chercher et d’essayer de regrouper les composants de manière cohérente.
Il est courant pour le déploiement d’un unique EAR ou WAR de devoir dupliquer certains fichiers ou de devoir modifier certaines configuration sur d’autres serveurs. Chaque ‘micro-tâche’ de déploiement peut être source d’erreurs, moins il y en a plus il y a de chance que cela se passe bien ou que le retour en arrière soit aisé.
Ainsi, on peut retrouver la situation suivante : le contenu statique est contenu dans l’archive EAR avec l’ensemble du code nécessaire à l’application. Ce contenu statique sera dupliqué sur un serveur http simple dans une optique d’optimisation d’accès aux ressources statiques. On y accède via un filtrage des URLs en utilisant un mécanisme de routage en amont.
Cela fait donc 3 étapes pour une livraison :
- déploiement de l’application,
- déploiement des ressources statiques,
- mise à jour des règles de routages.
De plus, il est fréquent que le point de routage soit en plus sur un serveur mutualisé, ce qui augmente le risque d’impact de la mise à jour pour la web application déployée sur les autres applications dont les routes transitent par ce point de routage. La principale raison évoquée est le fait de gagner en performance.
La proposition de Cyrille est d’utiliser le mécanisme de proxy-cache http, pouvant être facilement mis en place par l’équipe infrastructure avec des outils tels que que Varnish Cache, squid, ibm Fast Response Cache Accelerator (FRCA) voir un simple module apache http comme mod_cache.
Il n’y a plus de déploiement des fichiers sur un serveur statique, plus de besoin de modifier les règles de routage.
Un autre exemple sur la nécessité du regroupement des différentes briques par cohérence est le double filtrage lié à la sécurité. Il est fréquent d’avoir en amont un premier filtrage par adresse IP puis dans un deuxième temps un filtrage sur un couple login/mot de passe. L’idée est dans ce cas de regrouper ses deux actions ensemble, que ce cela soit sur le firewall, en java ou autre mais à un même point . De plus, cela permet également de pouvoir faire un filtrage par login et par adresse IP en même temps c’est à dire de contrôler par exemple que le login ‘admin’ ne puisse être utilisée que par l’adresse IP X et l’adresse IP Y.
Cohabiter en bonne intelligence
Sur un même serveur physique
Le deuxième aspect du déploiement abordé est sur le fait de cohabiter en bonne intelligence. Au niveau de la cohabitation de plusieurs applications sur un même serveur, les recommandations sont simples :
Minimiser les répertoires absolus et faire en sorte que chaque fichier soit dans un répertoire préfixé par un identifiant d’application (possible d’utiliser le group id et l’artifact id du composant par exemple ou plus simple /etc/my-application.
Organiser l’utilisation des ports réseaux en séparant un préfixe definissant l’application et un suffixe définissant le service par exemple, si 100 correspond à l’application Facture, on aura le port du serveur http sur 10080, le port du SSL sur 10043. Cette séparation permet de faire cohabiter de manière organisée 100 applications.
Sur un même serveur d’application
En ce qui concerne la bonne cohabitation sur un même serveur d’application, il faut de la même manière minimiser les répertoires absolus (c’est à dire privilégier les chemins relatifs comme (${java.io.tmpdir}/my-app1/) et les rendre lisible en les préfixant par l’artifact id (et le group id si besoin) pour empêcher les collisions entre répertoire.
Cyrille recommande également de limiter au maximum les variables java statiques qui impactent l’ensemble du serveur, il vaut mieux les définir par application.
Au niveau des paramètres de configuration, la question est posée de savoir si il vaut mieux mettre les fichiers de configuration directement dans l’archive ou au contraire de les externaliser. La décision dépend de la situation, par exemple, si l’équipe d’exploitation ne désire pas que l’équipe de développement possède les accès base de données, la configuration se fera à l’extérieure de l’application.
Une autre recommandation au sujet des paramètres de configuration est de limiter le nombre de paramètres dont la valeur change suivant les environnements : en isolant ses réseaux virtuels, il est possible de conserver des noms de bases de données identiques, de conserver les noms de hosts.
Dans le cas où l’équipe d’exploitation propose d’utiliser des noms incluant par exemple les différents environnements ex : monappli-dev , monappli-rec, ma-bdd-dev, ma-bbd-rec il est possible de proposer un compromis avec la création d’alias. La multiplication des paramètres de configuration est souvent source de problème lors des déploiements. De même, il n’y a pas lieu de faire changer les ports d’écoute.
Cette recommandation impose qu’il n’y ait pas de perméabilité entre les zones de développement, de recette et de production. Dans une précédente mission, il suffisait d’utiliser foxy-proxy, plugin firefox de configuration de proxy pour switcher automatiquement de mon application web de prod vers mon application web d’homologation. Dans ce cas, l’homologation était fermée, impossible d’avoir accès à Internet par exemple. Il est également conseillé, par sécurité, de modifier par exemple le logo sur l’homologation ou de jouer avec des codes couleurs pour indiquer de manière visuelle l’environnement sur lequel on se trouve mais aussi d’ajouter un filtrage sur les ip appelantes (bloquer les ips ou changer les mots de passes). A l’aide des .profile, il est possible d’indiquer directement sur la console ‘prod’ ou ‘valid’, avec putty de changer les couleurs etc.
Savoir ce qui est réellement déployé
Un autre point important du déploiement est de déployer des composants qui soient réellement traçables. On ne déploie que des composants taggés sur lesquels aucun commit n’aura été effectué (règle d’entreprise respectée/ utilisation de la fonctionnalité d’hook pour SVN) et/ou on empêche le redéploiement ( utilisation de la fonctionnalité Disable Redeployement de Nexus)) pour pouvoir connaître avec précision les classes déployées. Des outils comme Nexus ou Archiva permettent facilement de déployer des archives sur différents environnements en garantissant leur conformité.
Voilà les différents axes abordés sur la partie ‘déploiement’, la présentation, qui a durée 2 heures environ et a abordé 5 axes différents (seul le premier a été présenté ici), a été dense ! Pour ceux que cela intéresse plus en détails, Cyrille devrait publier ses slides dans quelques semaines et organisera à la mi mai une formation de 2 jours sur le thème. Pour le suivre sous twitter : @Cyrilleleclerc .
Soirée très enrichissante, notamment les parties sur la gestion des logs, le profiling et JMX.
En revanche si Cyrille a un tuyau sur « comment atteindre les personnes coté production » lorsqu’on est un simple développeur java, je suis preneur
Merci d’être venus et merci pour ces retours
@Jean Baptiste,
> comment atteindre les personnes coté production
Il me vient en tête :
- s’intéresser à leurs réalités et leurs problèmes (souvent les derniers informés, jongler avec des milliards d’applis hétérogènes, pas forcément formés aux nouvelles technos, pas forcément les budgets pour se former ni pour prendre des prestataires motivés, forte pression lors des indisponibilités, etc),
- admettre qu’ils ont un mode de fonctionnement très différent (en général orienté ticket plutôt que projet, etc),
- un peu de démagogie quand on les croise sur le fait que les application ne sont pas « production ready »
,
- être pédagogique plutôt que dédaigneux lorsqu’ils ne connaissent pas (1),
- montrer de l’intérêt pour le fonctionnement en prod, proposer des réunions « améliorer les logs » & cie,
j’en oublie plein d’autres et je reconnais, j’ai aussi parfois échoué à instaurer une vraie collaboration constructive avec les équipes d’exploitation
.
Cyrille
(1) j’adore la commande screen pour travailler en binome avec les exploitants une jolie vidéo ici : http://blog.xebia.com/2009/09/06/pair-programming-for-sysadmins/