Le point sur l'industrialisation Drupal et les installations multi-sites

Une usine à faire des sites Drupal, mais en prenant le temps de bien les faire :)
Mise à jour des différentes solutions possibles pour administrer plusieurs sites Drupal en mutualisant l'architecture Drupal, quitte à profiter d'un principe d'héritage des configurations et développements...

Nous profitons de l'évolution de nos différents projets multi-sites pour énumérer les solutions robustes et disponibles pour propulser une instance Drupal multi-sites. 

Multi-sites

Drupal possède une fonctionnalité qui permet de desservir des sites distincts et indépendants à partir d'une seule base de code. Chaque site possède sa propre base de données, sa configuration, ses fichiers et son domaine de base ou son URL.

La principale raison d'utiliser une installation multisites de Drupal est de gagner du temps lorsque vous gérez plus d'un site Drupal utilisant la même version de la base Drupal. Chaque fois qu'une nouvelle mise à jour de la base de données Drupal est publiée, vous n'aurez à effectuer cette mise à jour que sur un seul jeu de code au lieu de le faire pour chaque site.

Mais il y a des inconvénients :

  • Il faut des compétences techniques pour déployer un nouveau site (créer un VHOST, le configurer etc.)
  • Les différents sites doivent être physiquement hébergés sur la même infrastructure.

Multi-domaines

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.

Le module vous permet de partager les utilisateurs, le contenu et les configurations d'un groupe de sites tels que :

  • exemple.com
  • one.example.com
  • two.example.com
  • mon.exemple.com
  • thisexample.com - peut utiliser n'importe quelle chaîne de domaine
  • example.com:3000 - traite les ports non standard comme uniques

Par défaut, ces sites partagent toutes les tables (base de données) de votre installation Drupal.

L'inconvénient est, comme il n'y a qu'un seul site, qu'il n'y a qu'une seule structure de types de contenu, de vues, de panneaux, etc. Les définitions des types de contenu ne peuvent pas varier parce qu'il n'y a qu'une seule installation Drupal. Les vues sont, techniquement, interdomaines, bien que des filtres soient disponibles pour le "domaine actuel" (similaire à "l'utilisateur actuel").

L'accès au domaine permet cependant une configuration assez spécifique au domaine. Presque toutes les variables de configuration (celles qui utilisent le formulaire des paramètres de base) peuvent être définies par domaine, y compris le thème actif. Comme les thèmes peuvent être différents, et que les thèmes peuvent toujours avoir un thème de base commun, cela permet une grande flexibilité en ce qui concerne les différences graphiques” entre chaque site.

Le module Domain Path peut également trier les alias de chemin d'accès en double, comme "à propos" (que de nombreux domaines peuvent avoir).

Usine à sites avec AEGIR

Aegir est une distribution permettant d'automatiser la plupart des tâches courantes relatives au déploiement, à la maintenance ou à la sauvegarde de vos sites Drupal. C'est une "super distribution" dans le sens où elle permet d'administrer toutes les distributions installées sur votre serveur.

Aegir est très proche d’une installation multi-sites dans le sens où à partir du moment où l’on définit une distribution → un ensemble de modules et de fonctionnalités avec un thème graphique est disponible.
Et à partir du moment où Aegir est installé → On peut alors déployer facilement un nombre indéfini de sites basés sur cette distribution.

Ce qu’apporte AEGIR par rapport à un multi-sites :

  • La possibilité d’héberger sur des serveurs différents ;
  • Une interface graphique pour le déploiement, la migration d’un serveur à un autre, la création d’environnements de tests, la mise à jour des sites concernés.
  • D’autres distributions “Drupal” peuvent êtres gérées avec Aegir, par exemple une distribution spécifique pour des mini-sites, des intranets, etc.
     

Comparaison Multi-Sites (et AEGIR) et Multidomaines

Multi-sites (et Aegir) Multi-domaines
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. 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.
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. 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-sites, 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 un grand nombre de contenu (vues, menus, blocks) dans le panneau d’administration de Drupal.
Lorsque le seuil de 20 sous-sites est atteint, configurer les permissions des utilisateurs peut devenir problématique sans un minimum d’organisation.
 

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.
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 complexe à gérer pour l’administrateur.
Avec Multi-sites, 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.

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 (bootstrapping process). En d’autres termes, il est impossible de limiter « physiquement » le fonctionnement d’un module à un seul des sous-sites.
Domains modifie le fonctionnement de Drupal en profondeur sur la gestion des utilisateurs et du workflow. Il faut donc se montrer attentif à l’ajout de modules contribués qui modifient ces points et vérifier leur compatibilité avant toute chose....
 

Comment faire son choix ?

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

  1. Combien de sous-sites allez-vous devoir gérer ?
  2. Est-il nécessaire/obligatoire d’avoir recours à un seul panneau d’administration ?
  3. Aurez-vous besoin de partager le contenu et les utilisateurs entre les différents sous-sites ?

Exemples de demandes à formuler :

  • Cas #1 : Vous souhaitez avoir 30 sites similaires mais indépendants.
  • Cas #2 : Vous souhaitez 30 sites similaires, avec un seul BO d’administration et la possibilité d’échanger du contenu entre les sites.
  • Cas #3: Vous souhaitez développer un produit (une distribution) auquel tous les utilisateurs pourront participer à partir du site internet.

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

Nous aimons Aegir mais nous devons mobiliser la communauté pour faire évoluer la solution qui, en l'état, ne peut supporter de sites Drupal 10. Les travaux de réécriture d'Aegir5 sont en cours et nous espérons aider les travaux pour en libérer une version stable le plus rapidement possible.

Conclusion et points de vigilance sur l'option "Domains"

C’est un choix très structurant dès le départ. A partir du moment où nous choisissons une architecture, nous le déployons et ce sera difficile par la suite de revenir en arrière. 

Cette limitation concerne surtout les modules qui modifient en profondeur Drupal :

  • Gestion des utilisateurs et des rôles (droits d’accès) ;
  • Ré-écriture d’URL.

Avec Domains, prenons l'exemple d’un menu : soit nous avons un menu unique pour tous et en fonction du domaine en cours, on redirige vers les bonnes pages. Mais si un des sites veut son propre module, alors il faut en faire une copie et dire à Drupal que sur ce domaine on va afficher ce menu plutôt que le menu par défaut.

Même choses pour les “Vues”, par défaut elles prennent un paramètre de contexte qui correspond au Domaines en cours. Sur le même principe on aura une “Vue” Liste des actualités qui sur chaque site partenaire n'affichera que ses actualités et les actualités du portail central. Mais si un partenaire veut une autre vue, il faudra la dupliquer, etc.

Les modifications de structures (champs spécifiques pour un partenaire et non pour un autre), bien que techniquement possibles sont à limiter pour ne pas compliquer la maintenance.

Si chaque partenaire accepte une structure unifiée  et que les seules différences principales d’un portail à un autre sont :

  • Le thème Drupal (l’aspect graphique, les couleurs, un logo)
  • Le “fond documentaire” à interroger par défaut
  • et bien entendu le contenu de chaque site pourra être différent.

... Domains sera une bonne solution.

Nous pensons qu’il est important en phase de conception de bien recueillir le besoin de chaque partenaire afin de réaliser la meilleure structure qui offrira un bon compromis pour chacun et dont il conviendra de ne pas s’éloigner.

Si chaque administrateur de sites impose ses différences et veut d’autres fonctionnalités, là cela deviendra vite très lourd techniquement et humainement à gérer. C’est quelque chose qui peut survenir en cours de projet et sur laquelle nous ne sommes pas maîtres.

Enfin dernier point de vigilance, si pour une raison x ou y (surcharge, attaque, etc.) un site tombe, c’est l’ensemble qui tombe également.

Concernant l’export des contenus si un partenaire décide de quitter le groupement :

  • Il est compliqué d’isoler le site et de l’héberger ailleurs (à la différence d’un multi-sites) ;
  • Mais l’export (au format XML/JSON) du contenu du site partenaire reste bien entendu possible. Drupal 9/10 sur ce point permettant (avec un travail de configuration en back-office) d’exposer toute entité sous la forme d’une API REST.