Drupal Multi-site GUIDE TECHNIQUE

Transcription

1 Drupal Multi-site GUIDE TECHNIQUE

2 Table des matières Introduction Fonctionnement...4 Pièges et idées fausses...8 Faire le bon choix Drupal Multi-site

3 Introduction Drupal offre une fonction très utile appelée Multi-site, qui permet de servir de nombreux sites à partir d une même base de code Drupal. Grâce à cette fonction, vous pouvez réduire les coûts liés à la gestion du code pour plusieurs sites et bénéficier d une grande agilité pour lancer rapidement vos nouveaux sites. Vous trouverez dans ce guide technique une description détaillée de Multi-site, des conseils pour exploiter cette fonction pour votre organisation et la liste des aspects à prendre en compte concernant l infrastructure lors du déploiement d une installation Multi-site. Avec Multi-site, la maintenance se résume à une seule copie du noyau de Drupal et des modules complémentaires (sauf dans certains cas particuliers, abordés plus loin dans ce guide). Tous les sites partagent le même code, mais utilisent des bases de données distinctes. Les sites peuvent donc avoir un contenu, une configuration et une apparence très différents avec un code cohérent et géré de façon centralisée. L implémentation d Acquia Cloud Site Factory pour Warner Music Group est un bon exemple d utilisation de Multi-site. Grâce à Multi-site dans Drupal 7, les sites paramore.net, davidbowie.com, et bieberfever.com sont tous servis à partir d une base de code unique trois sites pour trois artistes très différents, avec des équipes éditoriales et créatives différentes, mais avec une seule base de code faisant l objet d une gestion, d une mise à jour et d une maintenance centralisées. Multi-site peut considérablement réduire les efforts de maintenance du code pour une série de sites. 3 Drupal Multi-site

4 Fonctionnement La configuration de chaque site possède son propre sous-répertoire dans le dossier des sites Drupal. Chaque répertoire contient un fichier settings.php personnalisé contenant les paramètres de connexion à la base de données. Drupal analyse le domaine dans une requête HTTP entrante et recherche le répertoire du site correspondant. Lorsqu une correspondance est trouvée, le fichier settings.php du répertoire en question est chargé. Vous êtes très certainement familiarisé avec les répertoires /sites/all et /sites/default. Ils sont nommés de cette façon pour une bonne raison : /sites/default contient le site par défaut servi lorsqu aucun mappage n est spécifié. /sites/all est un répertoire partagé auquel tous les sites ont accès. /sites/[nomdusite] contient la configuration de votre site personnalisé. Avec un répertoire /sites/exemple.com/, dès lors que notre serveur web reçoit une requête portant sur exemple.com, ce répertoire est examiné en premier pour vérifier s il contient un fichier settings.php. Si tel est le cas, ce fichier est chargé et une connexion est établie avec la base de données spécifiée. Tous les fichiers enregistrés par Drupal (téléchargements, CSS agrégés et JavaScript) sont placés dans /sites/exemple.com/files et non pas dans le répertoire /sites/default/files. C est tout! Utiliser Multi-site n exige aucune autre opération et vous pouvez ajouter un nombre illimité de sites en suivant simplement cette procédure. Vous pouvez toutefois aller plus loin pour exploiter les nombreuses autres possibilités offertes par Multi-site. Modules et thèmes spécifiques aux sites Chacun des sites d une installation Multi-site comporte au moins un fichier settings.php et un répertoire /files. Mais chaque répertoire Multi-site peut également contenir des modules et des thèmes, et tous les modules ou thèmes placés dans un répertoire sont uniquement disponibles pour le site correspondant. Prenons l exemple de deux sites, example.com and example2.com : /sites/all/modules/contrib contient tous les modules contrib communautaires que les deux sites doivent partager (le module Views, par exemple). /sites/all/modules/custom contient tous les modules personnalisés, écrits spécifiquement pour cette installation Drupal. /sites/exemple2.com/themes contient tous les thèmes qui ne doivent être disponibles que pour le site exemple2.com. /sites/exemple2.com/modules contient tous les modules qui ne doivent être disponibles que pour le site exemple2.com. 4 Drupal Multi-site

5 Lorsque Drupal recherche les thèmes et les modules disponibles, les répertoires sont examinés dans l ordre suivant : /modules/ /profiles/ /sites/all/ /sites/[nomdusite]/ Un thème personnalisé, intitulé «Chicken» spécifiquement écrit pour exemple2.com peut donc être placé dans le répertoire Multi-sites exemple2.com : /sites/exemple2.com/themes/chicken En procédant ainsi, le thème «Chicken» ne sera accessible qu aux visiteurs du site exemple2.com. Les visiteurs du site exemple2.com auront quand même accès à tous les autres thèmes placés dans /sites/all et dans /themes, mais les visiteurs du site exemple.com ne pourront jamais voir le thème «Chicken». Création de valeurs de remplacement locales Drupal s arrête à la version la plus spécifique d un module. Cela signifie que si vous avez besoin de remplacer un module pour un seul site, vous pouvez l installer dans le répertoire de ce site. Supposons, par exemple, que le module Views fasse l objet d une mise à jour pour passer à la version 7.x 3.7. Dans l environnement de test, tous les sites fonctionnent parfaitement sauf exemple.com, qui nécessite un élément de Views 7.x 3.5. cat /sites/exemple.com/modules/contrib/views/views.info grep ^version 7.x-3.5 cat /sites/all/modules/contrib/views/views.info grep ^version 7.x-3.7 Dans ce cas, exemple.com utilise Views 7.x 3.5 tandis que tous les autres sites auront accès à Views 7.x 3.7. Il en va de même pour les thèmes. Spécification de mappages de domaine avec sites.php Dans Drupal 7, le fichier sites.php permet d associer des domaines aux sites. Le déploiement d un nouveau site avec Multi-site peut être très simple il suffit en effet d ajouter un répertoire. Un processus idéal en environnement de production mais qu en est-il pendant les phases de développement et de test? Le développement et le test ne sont pas effectués dans le domaine actif, mais des tests doivent être réalisés avant le passage en production. C est là qu intervient sites.php. Avec sites.php, il suffit de spécifier un domaine, un port, un répertoire ou une combinaison des trois et d instaurer un mappage vers un sous-répertoire du répertoire /sites Par exemple : <?php // Un tableau avec des domaines en tant que clés et des répertoires en tant que valeurs. $sites = array( exemple.com => exemple.com, exemple.com.localhost => exemple.com, exemple.com.dev.mondomainedetest.com => exemple.com, exemple.com.stage.mondomainedetest.com => exemple.com, );?> 5 Drupal Multi-site

6 Cette possibilité offre une grande flexibilité et un contrôle pointu pour le mappage entre les domaines ou répertoires et les sites. Profils d installation Lorsque vous commencez un projet basé sur Multi-site, vous pouvez créer votre propre profil d installation Drupal. Un profil d installation permet d installer Drupal avec les modules et les configurations voulus. Les distributions Drupal comportent souvent un profil d installation spécifique. Lorsque vous téléchargez Commons 3, par exemple, le téléchargement contient une copie de Drupal 7 ainsi qu une collection de modules et Features. Lors de l installation de Commons, ces modules et Features sont activés et les éventuels contenus échantillons sont installés. La création d un profil d installation évite d avoir à configurer intégralement les différents sites au moment de leur déploiement sur la plateforme Multi-site ; il suffit simplement de modifier les configurations spécifiques à chacun. Il est même possible d installer des modules et des thèmes communs dans le répertoire du profil d installation et laisser ainsi le dossier /sites libre pour les modules spécifiques aux sites. C est l approche adoptée par Commons, Drupal Commerce et pratiquement toutes les autres distributions Drupal. Incorporation du module Features Le module Features permet de packager les fichiers de configuration Drupal comme du code. Il suffit ensuite d enregistrer ces configurations dans le répertoire des modules pour pouvoir les importer en activant simplement leur module. Vous pouvez incorporer le module avec des profils d installation et des valeurs de remplacement locales en procédant comme dans l exemple qui suit. Nos développeurs ont configuré un nouveau type de contenu Acquia Blogposts et l ont exporté vers un module Features nommé acquia_blogpost. Celui-ci est placé dans /sites/default/features/acquia_blogpost. Dans un profil d installation, cet élément est ajouté à la liste des modules qui doivent être installés. Le type de contenu acquia_blogpost est ainsi configuré exactement comme prévu à chaque fois qu un nouveau site est installé. Imaginons maintenant que nous voulions ajouter un nouveau champ pour une photo de chat, mais uniquement sur le site exemple2.com. Il suffit dans ce cas d apporter les modifications requises, d exporter cette nouvelle fonction vers un module et de le placer dans /sites/exemple2.com/features/acquia_blogpost. Le profil d installation va extraire le nouveau champ uniquement sur exemple2.com, et tous les autres sites continueront d utiliser la valeur par défaut. Simple et efficace. 6 Drupal Multi-site

7 Gestion centralisée de la base de code Dans les cas où les sites ont des fonctionnalités similaires, Multi-site permet de simplifier considérablement l effort de gestion du code. Imaginons que vous exécutiez 300 sites dans Multi-site ; si chaque site possédait une base de code distincte, il vous faudrait gérer 300 bases de code. Avec Multi-site, la base de code de chaque site doit uniquement contenir le delta du code de base et les personnalisations par site. Vitesse de déploiement Déployer un nouveau site dans une installation Multi-site est très simple. Il suffit de creér une nouvelle base de données, de spécifier les paramètres de connexion à la base de données dans settings.php, de déployer le code et de procéder à l installation. Un processus beaucoup plus simple que celui impliquant la duplication de la base de code, avec pour résultat un accroissement du code à gérer, vérifier et tester. Divergence de code Si les sites commencent à différer sensiblement en termes de fonctionnalités, gérer une base de code unique peut devenir coûteux. À ce stade, il est généralement préférable de diviser la base de code et de développer les sites individuellement. Imaginons, par exemple, qu un nombre important de vos utilisateurs enregistrés souhaitent interagir et collaborer. Si vous ne voulez pas qu ils le fassent sur votre site principal, démarrer une nouvelle communauté avec Drupal Commons est une bonne option. Bien que vous puissiez exécuter votre site.com et une communauté comme Commons à partir d une même base de code, il peut être préférable de créer un nouveau docroot vers lequel faire migrer vos utilisateurs. Multi-site ou bases de code multiples Il n y a pas de solution universelle. L important est de choisir celle adaptée à votre cas. Multisite est une architecture mature et éprouvée, qui peut toutefois ne pas convenir dans certaines situations. Vous pouvez en revanche vous fier à la vaste communauté Drupal, riche de ses expériences et de ses succès, pour vous aider à faire votre choix. Quelle que soit la solution, Acquia peut vous accompagner. N hésitez pas à nous contacter pour décider de la meilleure voie à suivre en fonction de vos besoins spécifiques. 7 Drupal Multi-site

8 Pièges et idées fausses Il est important de ne pas perdre de vue que Multi-site est un moyen de gérer le code, et non pas de le déployer les meilleures pratiques mises au point sur plusieurs années d hébergement Drupal s appliquent aussi bien à Multi-site qu aux docroots multiples. Une base de code Multi-site unique peut être déployée sur différents clusters de serveurs. Le fait de stocker le code dans une base de code unique ne vous limite pas à un serveur, un cluster ou une configuration unique. Multi-site n implique pas nécessairement un point de défaillance unique Tous les sites d une installation Multi-site partagent au minimum le code du noyau Drupal sous-jacent. Mais cela ne signifie pas que vous êtes enfermé dans un modèle d hébergement particulier. La question essentielle est de savoir comment gérer les mises à jour ; l hébergement d une installation Multi-site n est pas si différent de celui d un quelconque site Drupal. Performance Multi-site garantit une utilisation très efficace des ressources d un serveur. Le langage PHP utilisé dans le fichier settings.php est un langage interprété. Il n y a donc pas d étape de compilation lors du déploiement du code il suffit de déployer les fichiers texte du code source. Lorsque PHP s exécute, ce code source est compilé en opcodes. En l absence de cache d opcodes, cette compilation doit intervenir à chaque requête PHP. Un cache d opcodes permet de conserver les opcodes dans la mémoire et supprime ainsi l étape de compilation, ce qui accélère considérablement l exécution. L extension APC est actuellement le cache d opcodes le plus utilisé, mais PHP 5.5 introduit un cache d opcode («opcache») dans le trunk de PHP. Avec Multi-site, de nombreux sites partagent le même code Drupal et de module. Par extension, cela signifie que de nombreux sites peuvent partager un même cache d opcodes, permettant ainsi de moins mobiliser la mémoire au profit d autres usages. Dans la plupart des cas, la mémoire est la ressource la plus sollicitée ; il est donc toujours utile de pouvoir l économiser. Gestion de la performance Si vous exécutez 50 sites à partir d un même cluster et que l un d eux enregistre un pic de trafic, les 49 autres sites peuvent-ils manquer de ressources? Certainement. Faut-il pour autant leur réserver inutilement une partie de la capacité des serveurs? N est-il pas plutôt préférable d utiliser cette capacité de réserve pour faire face à ce pic de trafic? Si le site qui enregistre le plus gros du trafic continue de mobiliser un surplus de ressources, vous pouvez le faire migrer sur un autre cluster ou bien augmenter simplement la taille du cluster existant. Les ressources étant partagées, les 49 sites moins fréquentés puiseront dans le pool de ressources en fonction de leurs besoins. Faire face à des pics de trafic est un défi, peu importe le code et quelle que soit l infrastructure de serveur. L aspect le plus important dans la gestion de la performance, c est toujours la qualité du code une notion souvent oubliée au regard de la puissance et de la flexibilité très élevées des environnements matériels et cloud d aujourd hui. Il faut rechercher le juste équilibre entre le temps investi dans le développement et le coût du matériel supplémentaire dédié à un site sous charge. Acquia propose un grand nombre d outils et de services pour garantir que le code et la configuration client respectent les meilleures pratiques, notamment des outils SaaS en libre-service comme Acquia Insight, ou des services professionnels dispensés et nos équipes d experts. 8 Drupal Multi-site

9 Si une extension du matériel se révèle être le meilleur plan d action, nous pouvons faire évoluer à tout moment les sites hébergés dans Acquia Cloud, puis les revoir à la baisse lorsque les ressources supplémentaires ne sont plus nécessaires. Charge du serveur de base de données Parce que de nombreux sites peuvent potentiellement partager un serveur de base de données unique, chacun peut affecter les autres en cas de lourde charge ou de requêtes mal optimisées. Certains clients d Acquia exécutent des dizaines de sites sur des installations Multi-site avec un serveur de base de données unique. Dans la plupart des installations Multi-site, il est possible d exécuter des serveurs de bases de données multiples. Spécifier un serveur de base de données requiert une simple modification de la configuration dans settings.php. Mises à jour du code Avoir un code partagé par de nombreux sites présente d indéniables avantages, mais dans certains cas, une certaine vigilance est nécessaire pour la gestion des mises à jour. La mise à jour du noyau de Drupal entraîne en effet une mise à jour simultanée de tous les sites. La meilleure pratique consiste à exécuter la dernière version de Drupal et des modules contrib dans le cas contraire, de graves problèmes de sécurité peuvent survenir. Il n est jamais souhaitable d avoir des sites périmés. Avec Multi-site, vous devez tester TOUS vos sites en amont et non pas au coup par coup. Respecter les meilleures pratiques Drupal prend alors tout son sens mettre à niveau 50 sites avec un code bien formé ne prend pas plus de temps que mettre à niveau un seul site avec un code mal formé Mises à jour de base de données Mettre à jour Drupal ou les modules implique généralement d exécuter update.php ou drush updb pour apporter des modifications de schéma ou de configuration. Ces mises à jour doivent donc être exécutées dans les bases de données de tous vos sites dès que possible après le déploiement du code. Les conséquences peuvent être une perte d intégrité des données ou une augmentation de la charge du serveur pendant le processus de mise à jour. Dans la pratique, de nombreuses mises à jour de base de données sont très légères et ne rencontrent aucune difficulté avec ce processus. Si vous mettez chaque site en mode de maintenance (comme recommandé) avant d exécuter les mises à jour, le problème ne se pose pas. Dans le cadre d un projet, nous avions un fichier texte avec tous nos domaines (un par ligne). Nous avons utilisé un script shell très simple pour exécuter drush updb pour chaque site, avec une brève pause entre chaque mise à jour. Il aurait fallu un peu plus d efforts pour mettre chaque site en mode de maintenance avant d exécuter les mises à jour, ou pour lancer de multiples processus exécutant les mises à jour en parallèle. Il est toujours préférable de procéder d abord à des tests dans l environnement de pré-production. Une fois le processus en place, quelques commandes suffisent pour mettre à jour 50 sites. cron L exécution de Cron pour de nombreux sites qui partagent un serveur web ou de base de données peut soumettre le serveur à une charge importante, en particulier si les tâches cron s exécutent simultanément. Ceci est valable avec Multi-site comme avec des docroots distincts. Il est donc préférable d espacer le plus possible les exécutions de cron pour chaque site de manière à éviter les charges simultanées. 9 Drupal Multi-site

10 Faire le bon choix Il ressort systématiquement de nos discussions au sujet de Drupal ou du développement web en général, que ce soit chez Acquia ou au sein de la communauté Drupal, qu évoluer n est pas une chose facile. Mais c est tout l attrait de l open source et de Drupal en particulier repousser les limites et bénéficier mutuellement de nos diverses expériences. Gérer un grand nombre de sites n est pas une mince affaire, mais chez Acquia, nous avons la chance d interagir quotidiennement avec les entreprises qui exploitent certains des sites les plus importants et les plus complexes au monde. Si vous vous demandez quelle est la meilleure solution pour atteindre vos objectifs, contactez-nous. Nous serons ravis de vous apporter notre aide. N hésitez pas à nous appeler pour en savoir plus. Avec l aide de nos experts vous lancerez votre premier site dès aujourd hui En savoir plus acquia.com PARLONS-EN 10 Drupal Multi-site Dream it. Build it. Together. SKU FRA acquia.com Avenue de l Opéra Paris, France