Multi-sites vs Domain Access

S’il est un sujet suscitant des débats animés et causant de véritables casse-têtes parmi les puristes de la communauté Drupal, c’est bien celui des architectures multi-sites. Drupal offre diverses solutions à quiconque souhaitant mettre en œuvre une installation organisée en sous-sites, et face à cette problématique, force est d’admettre qu’il n’y a pas véritablement de réponse toute faite.

En examinant de très près la question, tout développeur Drupal s’apercevra assez vite que deux orientations possibles se présentent à lui et hésitera en conséquence devant le choix suivant :

1.     Procéder à une installation Multi-site

2.     Mettre en place une architecture s’appuyant sur Domain Access

Qu’est-ce qui différencie ces deux types d’architecture ?

Une installation Multi-site permet de servir plusieurs sites Drupal reposant sur le même code source (de façon complète ou partielle) mais ayant chacun une base de données qui leur est propre.

Domain Access est une suite de modules qui utilisent la syndication de contenu avec une gestion centralisée des utilisateurs, le tout fonctionnant sur plusieurs domaines. Chaque domaine correspond à un sous-site, mais tous pointent vers une installation Drupal mono-base unique. Chaque entité est simplement mappée vers un ou plusieurs domaines sur lequel elle doit être publiée.

Comparons maintenant, point par point, les deux architectures

Une installation multi-site est de très loin celle qui présente de meilleures performances tout en disposant d’une capacité de gestion de montée en charge bien plus élevée.

Etant donné que chaque sous-site dispose de sa propre base de données, le trafic enregistré sur un des sous-sites n’a pas réellement d’impact sur les autres.

Domain Access n’utilise qu’une seule base de données. Derrière plusieurs sites « virtuels » se cache en réalité un seul et même site physique.

Ce type de configuration impacte directement la performance et la capacité de gestion de montée en charge. Enfin, qui dit base de données commune dit aussi point de défaillance unique.

Dans une installation multi-site, le contenu et les utilisateurs de chaque sous-site sont rangés dans des bases de données séparées. Le panneau d’administration reste donc clair et parfaitement ordonné.

Domain Access se fonde entièrement sur la syndication de contenu distribué à travers plusieurs domaines. Il peut très vite en résulter une pagaille monstre dans le panneau d’administration de Drupal !

Lorsque le seuil de 13 à 15 sous-sites est atteint, configurer les permissions des utilisateurs devient un véritable casse-tête.

Par contre, en présence de 7 à 10 sous-sites, c’est l’extase !Utiliser le panneau d’administration est alors simple comme bonjour J

Selon le contexte et la nature du projet, devoir gérer des bases de données séparées peut représenter un avantage ou un inconvénient. Mais dans tous les cas, un point noir subsiste. Le contenu et les utilisateurs ne peuvent pas être partagés de manière directe et immédiate.

Cette particularité peut se révéler très problématique pour des équipes à effectifs réduits ou, pire encore, lorsqu’un administrateur unique se trouve condamné à constamment jongler entre les différents panneaux d’administration de chaque sous-site.

Par expérience, il est facile de prévoir toutes les difficultés que vont rencontrer les clients faisant le choix de confier la gestion d’un site à un administrateur unique. Au reste, n’est-ce pas se priver là d’un des principaux avantages d’une configuration multi-site ?

Astuces: Pour le partage d’utilisateurs, songez à déployer LDAP/CAS à travers tous les sous-sites. Pour ce qui est du contenu partagé, l’astuce consiste à centraliser les tables partagées dans une base de données unique, tout en maintenant la gestion de chaque sous-site dans des bases de données séparées. (Pour plus d’informations :https://www.drupal.org/node/201673)

Du fait de la base de données partagée, le problème le plus pénible posé par Domain Access tient en ce que le menu devient horriblement complexe à gérer, occasionnant par là-même une très grande confusion pour l’administrateur.

Une autre critique que l’on peut formuler est qu’en raison de la base de données unique, il s’avère impossible de créer des alias d’URL identiques pour deux sous-sites (imaginez différentes pages « qui-sommes-nous » pour chaque sous-site).

Astuce: le module Domain Prefixpermet de contourner ces problèmes en utilisant des tables distinctes pour chaque domaine. Cependant, la base de données restant la même, les problèmes de performance et de gestion de montée en charge continueront à se poser.

Avec Multi-site, tous les sous-sites partagent intégralement le même code de base, mais il est tout à fait possible d’installer des modules ou un thème spécifiques pour chaque sous-site, tout cela en conservant l’entière flexibilité de Drupal et sans la moindre incidence sur les autres sous-sites. N’est-ce pas formidable ?

Avec Domain Access, même si un module a été installé pour un seul des sous-sites, ce module doit être chargé à travers le moteur d’amorçage de Drupal (boots trapping process). En d’autres termes, il est impossible de limiter « physiquement » le fonctionnement d’un module à un seul des sous-sites.

Imaginez donc100 sous-sites ayant chacun 2 modules spécifiques. Chaque sous-site risque ainsi d’être soumis à rude épreuve.

De surcroît, un grand nombre de modules distribués sur drupal.orgne sont pas entièrement compatibles avec Domain Access. De quoi poser régulièrement problème aux développeurs de site…

Comment faire son choix?

Pour être certain de faire le meilleur choix possible entre Multi-site et Domain Access, il est vivement recommandé de se poser les questions suivantes :

1.     Combien de sous-sites allez-vous devoir gérer ?

2.     Quel est le trafic estimé sur l’ensemble des sous-sites ?

3.     Est-il nécessaire/obligatoire d’avoir recours à un seul panneau d’administration ?

4.     Aurez-vous besoin de partager le contenu et les utilisateurs entre les différents sous-sites ?

Etudions à présent quelques exemples de demandes qu’un client pourrait formuler :

• Cas #1: Le client souhaite avoir 30 sites similaires mais indépendants. (Imaginez par exemple, une université répartie sur 30 campus)
• Cas #2: Le client souhaite 10 sites similaires, avec un seul administrateur et la possibilité d’échanger du contenu entre les sites. (Imaginez une petite entreprise ne disposant que d’un administrateur à temps partiel)
• Cas #3: Le client est en train de développer un produit auquel tous les utilisateurs pourront participer à partir du site internet. (Pensez par exemple à Drupal gardens d’Acquia)

A présent, et au vu des explications données précédemment, voyons les réponses pour chacun des cas exposés :

• Cas #1: Multi-site
• Cas #2: Domain access
• Cas #3: Multi-site en utilisant Aegir

Note: Aegir est une plateforme de déploiement automatisée Drupal. Plus d’informations sur Aegir dans notre prochain article.

Vous avez une question sur ce sujet ? Tweetez sur @MangotreeStudi0

A propos de l’auteur

Animal connecté insaisissable, vagabond dans l'âme, entrepreneur open source, lecteur boulimique de littérature classique, fan des Beatles et de Beethoven depuis toujours, entretient une histoire d'amour avec l'Inde depuis 2010. Accessoirement chef de projet-architecte Drupal et directeur de mangotreestudios.fr.

N’hésitez pas à contacter l’équipe de l’agence Drupal Mangotree Studios. Vous pouvez également les contacter par email :  info@mangotreestudios.fr