1. Présentation▲
1-1. Généralités▲
ApacheCon est organisé par l'ASF (Apache Software Foundation), l'entité qui gère de façon non lucrative les célèbres projets opensource.
Depuis l'an 2000, elle a permis à toute la communauté de bénéficier d'un événement d'exception, rassemblant de grands spécialistes dans
différents domaines. Cette année donc, 3 conférences sont organisées dans le monde, au Texas, au Sri Lanka et à Dublin.
Inutile de tenter de restreindre cet événement à un rassemblement de geeks, les sessions traitaient de sujets professionnels, répondant
à des problématiques d'entreprise. ApacheCon a été pour nous l'occasion d'apprendre de nombreuses choses !
1-2. Irlande, pays des Leprechauns▲
Un excellent choix de l'ASF que d'avoir placé ApacheCon 2006 à Dublin, ville qui nous est apparue très dynamique et accueillante. La Guinness désinhibant les timidités, nous avons profité, au dela des horaires des sessions, du cadre très agréable, quoique nuageux. La conférence était hébergée au prestigieux hôtel Burlington (****), à 10 minutes à pied au sud du centre ville. Notre hôtel (hôtel Mespil) n'était guère loin du colloque et tout aussi agréable (***).
Photo Bertrand Delacretaz (équipe Apache Cocoon !) |
|
2. Organisation▲
2-1. Sponsors et Partenaires (Exhibitors)▲
Les logiciels de l'ASF étant utilisés par les plus grandes firmes du monde et les plus grands noms de l'industrie
logicielle (IBM, Sun Microsystems), il n'a pas été difficile de trouver des sponsors pour l'événement.
Une salle d'exhibition était d'ailleurs prévue pour ces sponsors, qui ont pu sonder les visiteurs et leur présenter
leurs derniers produits.
Notons tout particulièrement la très forte délégation de WSO2, dont certains membres présentaient des conférences, et qui propose
des solutions comme Tungsten ou REST, basées sur les Web Services (XML). Nous avons eu l'occasion de discuter avec des ingénieurs
de WSO2, très disponibles et très curieux des infrastructures que nous utilisons professionnellement (Web Services & IBM
Websphere), bref, le genre de discussion qui provoque inévitablement un échange de carte de visite...
Très présent également, Google Inc. animant généreusement leur stand avec tirages au sort et goodies amusants.
Enfin, le dernier sponsor avec qui la conversation fût constructive fût Sun Microsystems
(inévitable avec la présence de Craig Russell),
avec qui nous avons échangé nos impressions sur le projet Derby,
bientôt intégré au Java SE 6 (Mustang) sous le nom de JavaDB. Il
semble que l'une des principales questions sur Derby soit relative à une possible implémentation d'une réplication en temps réel. Certains éditeurs de
SGBD-R proposent des possibilités de réplication (MySQL, Oracle, Microsoft SQL Server...) et c'est encore non natif avec Derby. Coté Load-balancing,
la solution s'appelle Sequoia (anciennement projet Objectweb C-JDBC), un driver JDBC et un contrôleur qui a d'ailleurs fait l'objet d'une conférence de
Emmannuel Cecchet.
2-2. Wi-Fi & IRC▲
Parfait : rien à dire sur l'infrastructure Wireless que Colm MacCarthaigh a installé au Burlington Hôtel. Malgré l'affluence de centaines d'internautes qui checkent leurs e-mails, consultent le programme, téléchargent les slides de présentation, la fluidité du réseau WiFi 802.11g a été impressionnante.
D'autre part, on a apprécié la mise en place d'un chan IRC #apachecon (irc.freenode.net) qui a permis de suivre en temps réel les modifications
de l'emploi du temps, ou de participer à des conversations intéressantes.
2-3. Accueil et restauration▲
Pour pouvoir mesurer la qualité d'un événement, nous avons la désagréable habitude de regarder au delà de la qualité des conférences ;-). Il est toujours plus agréable lors des pauses de bénéficier de zones de discussions, de restauration, d'exhibitions, de travail. Pour la plupart des auditeurs, même pendant ApacheCon 2006, la réalité du travail impose une certaine disponibilité.
Rien de mieux donc que quelques clichés pour vous montrer l'ambiance des pauses et repas à ApacheCon 2006 !. Alors que les orateurs s'organisent (photo 1),
les auditeurs (photo 2) attendent la fin de journée (photo 3) :-).
ApacheCon 2006 s'est déroulé dans la bonne humeur, de nombreuses conférences ont ponctué l'événement de touches d'humour, vraiment très agréable. L'organisation
et la restauration du Burlington Hôtel étaient exemplaires.
Un grand salon aménagé pour l'occasion avec les stands des sponsors était disponible pour permettre aux visiteurs de checker leurs mails, vérifier
le programme, ou comme nous, rédiger leurs impressions. En cette période estivale et en pleine coupe du monde de football, la ville de Dublin était très vivante,
et le Burlington Hôtel était à portée idéale du centre ville. Enfin et pour cette dernière photo, soulignons la sympathie des sponsors, qui, comme Google ont veillé
à la communication autour des projets Apache et Open Source en général.
Crédit photo Noirin Plunkett |
Crédit photo Noirin Plunkett |
|
Crédit photo Noirin Plunkett |
Crédit photo Nielsvk |
|
|
|
3. Notre sélection de conférences▲
3-1. Opening Plenary & Keynote: Free Software Rules (Mark Shuttleworth)▲
Crédit photo Noirin Plunkett |
Même étranger au monde du logiciel libre, vous avez sans doute déja entendu parler de Mark Shuttleworth. De nationalité sud-africaine, Mark Shuttleworth est un entrepreneur très constructif (Thawte revendu à VeriSign, HBD Venture Capital, Canonical Ltd.) et anecdotiquement célèbre en devenant l'un des premiers touristes spacial et le premier africain à effectuer un voyage dans l'espace. Notons bien entendu que Mark Shuttleworth n'en reste pas moins le fondateur de la distribution GNU/linux Ubuntu (basée sur Debian, pour lequel il a développé dans les années 90) pour laquelle il a financé la Fondation Ubuntu à hauteur de 10 millions de dollars. C'est donc ce même Mark Shuttleworth qui a introduit ApacheCon 2006 avec cette Keynote intitulée "Free Software Rules", et articulée en 13 slides : #13 : Pretty is a FEATURE #12 : Consistent PACKAGING (packaging différent depuis des années, en fonction des distributions et des faux-standards, il faut absolument converger vers une solution commune, et proposer une interface simple à l'utilisateur) #11 : Simplified LICENSING #10 : Pervasive PRESENCE (Identité, sécurité) #9 : Pervasive SUPPORT (Combien de fois nous sommes-nous demandés : ce matériel est-il supporté ? Le constructeur ouvre-t-il les spécifications pour l'écriture de drivers .) #8 : Govaritye PA RUSKI (L'un des plus gros travail à fournir encore : travailler l'internationalisation) #7 : Great GADGETS (concentrer un effort vers les Smartphones, les PDA) #6 : Sensory IMMERSION #5 : Getting it TOGETHER (mutualiser, communiquer, partager...) #4 : Plan, Executive, DELIVER #3 : The Extra DIMENSION #2 : Granny's New CAMERA #1 : Keepin it FREE (le principal challenge des 5 prochaines années selon Mark Shuttleworth) Une session d'ouverture très "free-spirit" avec un orateur d'envergure, les auditeurs ne s'y sont pas trompés. |
3-2. "Behind the scenes of the ASF" (Lars Eilebrecht & Cliff Schmidt, ASF)▲
|
ApacheCon 2006 fût l'occasion pour la fondation de démystifier son organisation et son fonctionnement.
Cette tâche fût confiée à deux membres émérites, Lars Eilebrecht et Cliff Schmidt. Outre les informations les plus connues,
comme la base du volontariat, et sa localisation dans le Delaware, on apprend qu'une personne est salariée à temps plein depuis
Avril 2006, et est en charge de tâches administratives (comme l'organisation des conférences, les communiqués, etc.) et une autre est
chargée de l'administration des serveurs.
L'ASF a également tenu à présenter sa structure éligible. Le bureau des directeurs est issu d'un vote annuel, ceux ci ne sont pas obligatoirement des résidents des Etats-Unis. Les racines de l'évolution des membres et de la reconnaissance est le "Meritocracy" : "the more merit you have, the more power you get". Les différents stades de participation sont : L'utilisateur : toute personne qui utilise un logiciel de l'ASF, de façon passive (pas de contribution directe : les "Lurker"), ou de façon active (patches, bug reports : les "Contributors"), Le "Committer" : un utilisateur actif qui par mérite se voit octroyer les droits en écriture au référentiel SVN. Il possède également une adresse *@apache.org et a accès à un certain nombre de ressources privées, Le "Project member" : jugé très méritant pour un projet ; il reçoit la capacité de voter et la capacité de pouvoir proposer la candidature de "Committers", Le "ASF member" : il peut voter et se présenter, mais également proposer des projets à l'incubateur. Actuellement, l'ASF recense 1239 committers, 202 members, 15 membres émérites, 42 officers, et 9 directeurs. Le bureau des directeurs est chargé de gérer les fonds, les infrastructures, la propiété intellectuelle et la gestion des marques. Ces 9 directeurs sont élus chaque année. Ils ne prennent pas de décisions technique. Un PMC ou "Project Management Committee" est une structure humaine dédiée à chaque projet et à ses sous-projets. Les deux membres de l'ASF ont également présenté le projet "Incubator" et les démarches à effectuer pour suggérer un projet à l'ASF. Au niveau infrastructure matérielle, l'ASF dispose d'une architecture haute disponibilité (24h/7j), composée de 16 serveurs répartis principalement sur 2 sites (San Francisco et Amsterdam) et gérés par un administrateur à temps plein. Cette infrastructure reçoit environ 50 requêtes par seconde, 4 millions de hits par jour, et distribue 5 TB par mois. Le référentiel de code source contient 25 GB de données, pour 6 GB de données binaires. Une toile de serveurs miroirs (environ 280 dans 55 pays) s'est constituée pour répondre aux nombreuses demandes de téléchargement. |
3-3. "Web Application Security Trends" (Christian Wenz)▲
|
Christian Wenz a animé une session suivie par un grand nombre d'auditeurs : le sujet était en effet très parlant
et au goût du jour : la sécurité des applications Internet. L'orateur était plutot dynamique et nous a vigoureusement
sortis d'une pause café méritée. Le constat de Christian Wenz est nourri de bon sens : il y a de très (trop)
nombreux articles, forums, livres blancs, tutoriels, livres sur la sécurité, mais chacun aborde le sujet d'une manière
personnelle et les explications ne sont parfois pas les plus justes. De nombreuses fondations ont été créées, et
les médias se sont approprié le sujet, mais tout cela ne semble pas vraiment aider les développeurs et oeuvrer
correctement pour la sécurité. Nous avons donc revu rapidement les principaux problèmes en matière de sécurité applicative Internet : - XSS (Cross site scripting) : il s'agit d'une des plus vieilles méthodes, basée sur l'insertion d'un code HTML ou Javascript au sein d'une page. Dans la plupart des cas bénine, cette méthode s'est complexifiée dernièrement avec l'émergence de AJAX (plus simplement le recours à l'objet XMLHTTPRequest. Des exemples ont illustré cette méthode ainsi que les dérives basées sur le tag meta, ou encore le CSRF (Cross Site Request Forgeries). - SQL Injection : il est également très facile d'accéder à des données confidentielles ou de tricher lors d'une phase d'authentification avec une injection SQL. Il est ainsi permis, si vous n'y prêtez pas attention, de lancer une commande propre à votre SGBDR (une procédure stockée par exemple), de réaliser des attaques basée sur UNION, ou même de tenter des attaques de type DoS (Denial Of Service) applicatif. - XPath Injection : sans entrer dans le détail, Christian Wenz a également présenté les risques liés aux attaques sur un arbre XML, avec le langage XPath. - Regex Injection : consultez l'article de Christian Wenz sur son site ! - Trackback spamming, Comment spamming : allons, si vous possédez un blog, dotClear ou autre, vous avez dû y être confronté. Ces deux plaies sont assez récentes, et dégradent sensiblement la qualité des mini-sites perso (journaux, blogs) et les zones d'échange, communauté. Des robots, insèrent automatiquement des commentaires sans queue ni tête, des liens promotionnels et/ou pornographiques. Les solutions existent pourtant : blacklistes (bloquage d'IP), listes d'exclusion de mots interdits, renommage dynamique des trackbacks, modération manuelle des commentaires (la plus couteuse en temps), la vérification des en-têtes HTTP et notamment les HTTP_REFERER. |
3-4. "Subversion Best practices" (Brian W. Fitzpatrick, Google Inc.)▲
|
En quelques mois Subversion a été unanimement adopté par les professionnels. Pas seulement à cause du vieillissant CVS,
mais également par les fonctionnalités innovantes que Subversion propose.
Brian Fitzpatrick, ingénieur logiciel pour Google, a préparé une synthèse de "bonnes pratiques" issues de son expérience personnelle quant à l'utilisation de Subversion. N'utilisant pas encore Subversion mais CVS, j'ai pris soin de noter tous les points présentés, en espérant pouvoir migrer notre système de gestion des sources vers Subversion. Brian Fitzpatrick a clairement scindé ses slides en 2 parties distinctes : les bonnes pratiques côté serveur et celles côté client. Voici donc un condensé de mes notes: Bonnes pratiques côté "Serveur" - Quel serveur choisir ? : tout dépend du contexte d'utilisation. SVN Server est rapide et léger, idéal pour une installation simple. SVN+SSH sera plus recommandé si un démon SSHD est déja configuré. Enfin, Apache HTTPD permet la navigation web dans l'arborescence SVN, dispose de nombreux points d'intégration, permet également de "monter" un référentiel SVN comme volume réseau, ou encore de personnaliser les logs. - Un référentiel ou plusieurs ? : il est fort recommandé, dans la mesure du possible, d'avoir un seul référentiel, dans le but de simplifier la gestion des droits utilisateurs, du partage du code et de la réduction des coûts de maintenance. Bien entendu, de bonnes raisons peuvent aboutir sur la création de n référentiels, comme une politique d'accès radicalement différente, ou la nature (type) des données (*.java, *.php, fichiers binaires, fichiers XML...). - Politique d'autorisation : il faut mettre en place des systèmes d'authentification pour encourager les efforts de sécurité et l'affectation de responsabilité. Il est également important de savoir qu'une ressource n'est jamais vraiment supprimée avec SVN. - Outils de navigation : de nombreux projets simplifient la navigation, notons particulièrement SVNView ou Trac - "Hook scripts" : une des fonctionnalités intéressantes est de pouvoir exécuter des scripts sur deux événements, on les qualifie de "Pre-commit Hooks" et "Post-commit Hooks". Un "Pre-commit hook" se déclenche avant de valider des modifications dans l'arbre SVN. Python est d'ailleurs le langage de script le plus conseillé pour réaliser ces scripts. Brian Fitzpatrick conseille donc par exemple l'utilisation du script check-case-insensitive.py. Les scripts "Post-commit" s'exécutent en tâche de fond après une validation, notons par exemple mailer.py qui notifie par mail d'une modification, ou encore CIA Bot. - Verrouillages et check-out réservés : le mot d'ordre est "Don't lock everything all the time !", comme peut le faire un Microsoft Visual SourceSafe. Il est seulement nécessaire de vérrouiller les fichiers non fusionnables. L'utilisation de la propriété svn:needs-lock à des fins de communication. On peut souligner que le vérrouillage peut être paramétré par type de fichier. - Auto-versioning : fonctionnalité utile pour les projets hors développement/codage (musique par exemple), ou pour une utilisation non initiée de SVN. - Maintenance du référentiel : grâce à des outils comme les Hooks, vous pouvez être averti dès la modification de votre référentiel SVN. La maintenance en sera plus aisée, et cela vous évitera d'organiser des sessions de "nettoyage" risquées ;-). Pensez également à sauvegarder sur unité de stockage adapté votre référentiel. Bonnes pratiques côté "Client" - Encourager la revue de code : La revue de code est considérablement simplifiée si vous privilégiez des validations fréquentes, avec des petites modifications homogènes. Afin de vous faciliter l'analyse du code source, optez pour des fichiers de logs consistants. Comme certains scripts "Post-commit" le suggèrent, envoyez un mail dès que vous validez une modification. - "Branches" : Avec CVS, certains restaient étrangers au mécanisme puissant de "Branching". Avec Subversion, n'en ayez plus peur !. Vous pouvez scinder vos projets en branches de courts, moyens et longs cycles de vie. Adoptez également une politique de "Branching" stricte. - "Mixing and matching components" : Subversion vous propose, avec des commandes comme svn:externals ou svn:switch, de construire une copie de travail à partir de différentes sources, ou encore de basculer entre différents référentiels. Un retour d'expérience très convaincant de Brian Fitzpatrick sur Subversion. Les conseils prodigués pousseront les plus réticents à abandonner CVS au profit de SVN. |
3-5. Keynote : "Atlas" (Robert Burke)▲
Crédit photo Noirin Plunkett |
Chose originale à ApacheCon 2006, Microsoft était sponsor, et une conférence était même organisée !.
Beaucoup de monde s'est empressé de prendre de place dans la grande "Lansdowne Room" pour assister à la présentation de Robert Burke.
Le sujet du jour était donc le framework ASP.NET "Atlas", qui est selon Microsoft une plateforme de haute productivité d'applications
basées sur AJAX.
Pour mieux comprendre cette technologie quasi inconnue pour la plupart des personnes présentes, Robert Burke a fait
de brefs rappels sur ASP.NET et sur le Web 2.0.
ASP.NET est le langage orienté Web permettant de construire des applications orientées données. Il est notamment possible de développer en ASP.NET grâce à Microsoft Visual Web Developer 2005, que Robert Bruke a pris soin de distribuer. Microsoft préconise également le recours à ASP.NET car sa courbe d'apprentissage est relativement rapide. Un peu de démagogie également : ASP.NET supporte beaucoup de standards comme XHTML, les CSS et les normes d'accessibilité. Concernant le Web 2.0, bien qu'il s'agisse à mon sens d'un buzzword abusivement employé, c'est l'une des motivations ayant poussé Microsoft à effectuer un effort de développement pour séduire les entreprises. Le Web 2.0 dans ses grandes lignes est la standardisation de l'internet autour de grands principes, davantages issus du bon sens que d'une révolution technologique, tels que la consolidation de l'intelligence collective (communauté), l'utilisation de l'internet comme une plateforme à part entière, le replacement de la donnée comme l'essence de la qualité des applications Web, les modèles légers de programmation et d'architecture, ou encore l'interactivité avec l'utilisateur (utilisation de XMLHttpRequest asynchrones, plus connu sous l'acronyme AJAX). Le framework Atlas est une plateforme de productivité pour les applications basés sur AJAX. Une grande interactivité est donc mise en place afin de masquer à l'utilisateur les flux de communication. 2 composants principaux (core) sont proposés : - Un composant client, qui intègre des librairies Javascript pour AJAX, - Un composant serveur, pour l'implémentation des requêtes AJAX et des contrôles afférents. Atlas est également libre au téléchargement. Robert Burke précise que l'intégration de la partie client est supportable par de très nombreuses architectures serveurs autre qu'ASP.NET, mais sans les énoncer précisément. Atlas est compatible avec la majeure partie des navigateurs : IE, Safari, Firefox. Et enfin, Atlas Control Toolkit est un projet OpenSource, ouvert à contribution. Robert Burke a ensuite détaillé les différents modèles architecturaux envisageables avec Atlas, qu'ils soient plus orientés client ou plus orientés serveur. Nous de reviendrons pas sur ces explications car cela pourrait faire l'objet d'un article à part entière. Les démonstrations !. Une présentation dynamique s'achève toujours par une démonstration :-). Robert Burke a marqué ApacheCon 2006 par une présence anecdotique et par une session très dynamique et divertissante. Les démonstrations d'Atlas comme les astuces SSE et Live Clipboard ont été très appréciées (tout comme les menus zoomés façon MacOS d'une des sessions Apache MyFaces d'ailleurs). Quelques liens pour le projet Atlas: - Le site du projet, - Mix06 Talk de Shanku Niyogi : Atlas with PHP, - Mix06 Talk de Nikhil : SSE et Live Clipboard, - Le blog de Robert Burke. |
3-6. "Perform with Apache Derby" (Satheesh Bandaram)▲
|
Je tenais à assister à cette conférence car c'était l'une des seules relative à une base de données. Peu avant ApacheCon 2006,
le projet Derby a été annoncé comme partie intégrante du futur SDK de Sun Microsystems : Java SDK 6 "Mustang". Son nom de
distribution sera alors "JavaDB", plus parlant.
Satheesh Bandaram, avant tout exposé, a tenu à rappeler l'avantage principal de Derby : l'absence de compétences de DBA (Database Administrator) particulières. Puis il a recadré le projet : il ne s'agit pas de concurrencer Oracle ou DB2, très performants pour les base de données de grande dimension, mais bel et bien de proposer une alternative 100% Java à des SGBD plus léger comme MySQL, et de permettre la gestion de base de données de petite et moyenne dimension. En proposant des fonctionnalités parfois inexistantes chez les concurrents directs (suppression en cascade par exemple), Derby espère séduire les aficionados de Java, le tout packagé dans une simple archive JAR de moins 2 Mo. Initialement, Derby est né de l'ouverture d'IBM Cloudscape. Il dispose ainsi de nombreuses interfaces (ODBC IBM, JDBC) de programmation pour différents langages (Java, PHP, ODBC-like). J'ai apprécié l'objectivité avec laquelle Satheesh Bandaram a parlé de Derby : point de solution magique, juste une solution séduisante pour certains aspects, mais inutilisable pour d'autres. J'ai d'ailleurs prolongé cet intérêt pour Derby en discutant longuement avec Manyi Lu (Product Manager - Database Technology Group) de Sun Microsystems, qui s'est chargée de questionner les visiteurs sur leurs besoins en fonctionnalités de SGBD dans un contexte de développement (outil de profiling, optimisation), et surtout dans un contexte de production (réplication, haute disponibilité). A la question : "Derby est notamment interfacé via JDBC, mais il y-a-t-il eu des améliorations pour les interactions avec des EJB CMP par exemple ?", xxx a répondu que non, l'interfacage JDBC est standard et l'implémentation ne prend pas en compte d'éventuels framework de persistence pour des optimisations. Les questions les plus souvent soulevées par les visiteurs afin d'utiliser Derby en environnement de production sont l'implémentation d'un mécanisme de réplication en temps réel (comme le font les gros SGBD propriétaires), l'optimisation de l'archive pour l'embarqué, ou encore l'implémentation d'une possibilité de recherche de type "FULL TEXT SEARCH" comme Microsoft SQL Server. |
3-7. "httpd 2.x to 50,000 users" (Colm MacCarthaigh)▲
|
Première session de l'après midi placée sous le sceau de Apache httpd. Le titre est particulièrement accrocheur
et en a séduit plus d'un, comme le montre la photo ci-contre ! Nous avons tous, au moins une fois dans notre vie d'internaute, téléchargé une ressource à partir de l'excellent Sourceforge (ou même Debian, Ubuntu, Apache, NASA Worldwinds, *BSD etc.). Différents mirroirs sont proposés, et l'un des plus célèbres est HEAnet (National Server Mirror for Ireland). C'est pour HEAnet que Colm MacCarthaigh travaille, en s'occupant de l'ingénierie de l'architecture de téléchargement. Bien entendu, quelques chiffres sont annoncés pour exprimer la dimension de l'infrastructure : - Approximativement 27,000 téléchargements concurrents, - 1200 Mbits/sec en production, - 4Gb/sec en test, - Environ 80% des téléchargements Sourceforge de Avril 2003 à Avril 2004, - Plus de 12,000,000 de fichiers stockés par jour, - 6,38 TéraBytes de contenu disponible, - 5,500,000 téléchargements par jour, - 4 fois plus d'utilisation que ftp.kernel.org 
Nous avons ensuite vu que pour Colm, 4 éléments étaient concernés pour atteindre des performances extrêmes : - Latence du réseau, - Performance des périphériques de stockage, - Performances du kernel OS, - Performances du serveur Web puis différentes manières de réaliser un benchmarking du serveur Web (apachebench, httperf, autobench, siege, SpecWEB), des disques (Postmark, IOZone, Bonnie++, dbench), de la VM et du Scheduler (peu de solutions : tiobench, scripts *.sh maison), et enfin des réponses techniques au tuning des différents composants (kernel, filesystem, Sysctl, RAM, SCSI). Colm MacCarthaigh a également présenté une liste des architectures CPU qui selon lui sont le plus favorable à la performance des serveurs Web (dans l'ordre) : Intel Xeon, Intel Itanium, Niagara et AMD Opteron. |
Crédit photo Noirin Plunkett |
3-8. "Apache Performance Tuning" Part 1 & 2 (Sander Temme)▲
|
Une des rares sessions planifiées sur 2 heures. Utilisant professionnellement Apache, et recherchant une haute disponibilité
maximum, et un service de plus en plus performant, nous tenions à assister à celle-ci, et Sander Temme a développé pendant 2 heures
tous les aspects d'optimisations et de fine-tuning de l'écosystème Apache httpd. Cette session était un très bon complément de "httpd 2.x to
50,000 users" de Colm MacCartaigh. Voici donc les différents points abordés :
Le monitoring : Pour optimiser une architecture, nous avons besoin d'informations quant à son fonctionnement, à son cycle de vie. Inutile de passer outre cette phase. Vous devez analyser les logs, traces, diagrammes d'activité, etc. Le monitoring permet d'observer, d'extrapoler, de recevoir des signaux et des alertes, de tester. Vous pouvez à cet effet monitorer différents composants, tels que les serveurs (CPU, RAM, Swap, I/O), l'infrastructure réseau, les processus httpd (Apache Server Status par exemple). Les systèmes d'exploitation comme GNU/Linux mettent à disposition certains outils comme top, free, ou vmstat. Vous devez également suivre l'activité via les fichiers de logs, comme ErrorLog.log (qui permet plus ou moins de verbosité : debug, info, notice, warn, error, crit) ou AccessLog (ou CustomLog). La performance : Sander Temme a insisté sur 3 composants ciblés par cette phase : - Apache httpd : les processus et threads, DNS lookups, éviter les .htaccess, désactivation des modules inutiles, Access Control, MaxClients - Système d'exploitation : Context switches coûteux sous Solaris et AIX, Linux NTPL, Apache 2.2 workers, ulimit, Swap et RAM - Tiers Applicatif / Site : minProcessors, maxProcessors (Tomcat), JVM (Heap, GC), MySQL Pooling, PHP prefork, préférer application en couches (MVC), Load-balancing... Scalabilité : Pour obtenir un uptime maximum et anticiper les pannes (matérielles, logicielles), vous devez dans la mesure où votre budget le permet, introduire de la redondance. Redonder des disques durs, des alimentations, voire dupliquer des serveurs complets peut sauver votre poste ! Le Load-balancing (LB) a aussi son importance, vous pourrez à tout moment ajouter une nouvelle machine de calcul à votre ferme et votre entité abstraite distribuera la charge automatiquement. Différentes méthodes de LB existent dont le traditionnel DNS round-robin, NLB (Windows Server 2003), Whackamole, ou basé sur des implémentations propriétaires (appliances Cisco, Foundry, Juniper). Linux Virtual Server (LVS) est aussi une solution éprouvée et peu coûteuse pour le Load-balancing. Nous n'avons pu retranscrire toutes les explications fournies et réponses données aux questions des (très) nombreux auditeurs. |
3-9. "Python Portlets" (Santiago Gala)▲
|
Santiago Gala contribue à de nombreux projets Java EE (différents projets
Apache Jakarta,
Apache Portals Jetspeed,
Objectweb JOnAS)
et s'intéresse également à Python. La session était donc une introduction à la programmation de Portlets en Python suivant la spécification JSR-168. Santiago Gala a donc dressé un rapide panorama des projets concernés par le projet Apache Portals : - Jetspeed : ré-architecturé depuis la version 2.x autour de la JSR-168, et basé sur Spring, authentification JAAS, Pluto - Pluto : implémentation de référence de la JSR-168, depuis 2004, issu d'un don et refactorisé en version 1.1 - Cocoon : framework XML - Graffito : Portlets orientés CMS (Content Management System), actuellement dans Apache Incubator, basé sur Apache Jackrabbit (JSR-170) - WSRP4J : standards OASIS pour l'appel à des WebServices Puis Santiago Gala a détaillé l'intérêt des portlets. Les portlets sont très similaires aux éprouvées servlets, mais tirent conclusion de cette expérience en amenant un niveau de maturité et de structuration important. Ainsi, une page est composée de portlets isolées qui proposent un modèle riche d'interaction, qui exploite les actions (Action) et les rendus (Render). Ces portlets sont également définies dans un fichier de configuration portlet.xml qui permet un packaging d'applications Web propre. La JSR-168 est la cible d'une mise à jour majeure suggérée par IBM : la JSR-286 "Portlet Specification 2.0". L'orateur avait je pense tellement de choses à nous dire qu'il en a perdu le fil de sa présentation et préparé un diaporama beaucoup trop long. Une heure après, nous n'avions toujours pas abordé le thème qui m'avait fait choisir cette session plutôt qu'une autre : "Python". J'ai été assez déçu de cette session du fait de la longueur et du titre peut-être mal choisi. Qu'importe ! Santiago Gala m'a néanmoins donné envie d'explorer d'un peu plus près la JSR-286 et de suivre le projet Apache Portals... |
|
4. Liens▲
- Le site de ApacheCon 2006 à Dublin
- Le site de l'ASF
- Les galleries photo de ApacheCon 2006 sur Flickr : ApacheCon EU 2006, ApacheCon 2006
- ApacheCon US 2006 à Austin (Texas) du 9 au 13 Octobre,
- ApacheCon Asia 2006 à Colombo (Sri Lanka) du 14 au 17 Aôut.