Industrialisation et multi-sites avec Drupal

Porte usine

Créer une usine à sites ou pouvoir industrialiser la création d'un site Internet est une problématique souvent rencontrée pour développer sa présence Internet. Elle doit souvent répondre à un ou plusieurs de ces objectifs :

  • Le temps - mise en production d'un site dans un délai court
  • Le coût : Réduction du coût de fabrication
  • La maintenance : Réduction du coût de maintenance et facilité pour une gestion globale
  • L’homogénéité : respect d'un catalogue de fonctionnalités et de mises en pages communes pour permettre une présence web massive et cohérente

Drupal permet d'industrialiser la production de sites internet et nous offre comme d'habitude plusieurs solutions pour y parvenir.

En effet, une des forces de Drupal est qu'il ne se limite pas à être un outil de conception d'un seul et unique site. Il peut être utilisé également pour la gestion simultanée de plusieurs sites. Ces capacités existent depuis de nombreuses années, mais ne sont pas toujours bien connues ou comprises. Et comme tout outil moderne et puissant, Drupal propose plusieurs méthodes / architectures différentes permettant de propulser toute une série de sites Drupal, chacune de ces architecture ayant ses propres avantages / inconvénients.

Le point clé à considérer lors du déploiement à grande échelle de sites Drupal est que plusieurs sites semi-indépendants ne signifient pas nécessairement de multiples installations de Drupal. En fait, cela peut même ne pas signifier du tout plusieurs sites mais bien un seul et unique site. En effet, ce qui peut apparaître comme un site distinct, peut n'être effectivement qu'une implémentation du système de contrôle d'accès de Drupal. Pour décider de l'architecture à mettre en place, il y a un certain nombre de facteurs à considérer, comme par exemple :

  • si le pilotage des sites sera unique ou non (ou de quel autonomie doit disposer chacun des sites),
  • si chacun des sites doit apparaître pour les visiteurs comme un site à part ou comme faisant partie d'un site unique,
  • si le thème et la mise en page des contenus doivent suivre une ligne éditorial précise ou non, 
  • si tous les sites doivent disposer du même processus de publication,
  • si le contenu devra être partagé ou pas entre les différentes sites,
  • etc.

Vous trouverez à la fin de ce billet quelques critères vous permettant de vous guider dans le choix d'une architecture cible.

Faisons un tour d'horizon des principaux moyens de mettre en place une présence en ligne massive avec Drupal, et quels sont les avantages et inconvénients de chacune des architectures possibles.

Pour contextualiser les choix possibles avec un exemple, nous considérerons un cas d'utilisation classique, celui d'une université avec plusieurs collèges et départements. Selon l'école, chaque collège ou département peut avoir une grande autonomie quant à leur présence sur le web, ou bien l'université peut avoir une stratégie web centralisée. Le même concept s'applique à une grande entreprise avec plusieurs divisions, ainsi qu'à des organisations plus petites avec seulement une poignée de sites « différents ».

Installations distinctes

photo de bulles distinctes

Parfois, la meilleure stratégie est de ne pas unifier les sites du tout. Dans ce cas, toute similitude entre les différents sites est en grande partie une coïncidence. Si il y a un grand nombre de sites, des outils d'automatisation tels que Drush ou Aegir peuvent permettre d'administrer et de créer de nouveaux sites plus facilement. Dans une perspective de création de site, il s'agit en tout état de causes de sites différents et indépendants.

L'avantage de cette approche est que chaque site est entièrement autonome. Cela peut être bon si chaque département doit avoir un contrôle complet ou presque complet sur sa propre présence sur le web. Certains éléments communs peuvent être partagées par ces différents sites (thème, mise en page), mais rien dans Drupal ne permet d'imposer le choix de ces éléments.

Un autre avantage de cette approche est qu'elle ne nécessite pas de tous les sites d'être sous la même version de Drupal. Si une organisation (ou une école) normalise tous ses sites web sur Drupal, elle n'est pas obligé de choisir une version spécifique de Drupal et peut au fil du temps se constituer une collection de sites, gérés par différents départements, propulsés par Drupal 7 ou Drupal 8 simplement du fait de la période à laquelle ils ont été construits. Ceci est la seule stratégie qui permet cela, car les différentes versions de Drupal ne peuvent pas cohabiter sur une même base de code commune.

D'un autre côté, cette autonomie est au prix de la cohérence. Ces sites peuvent ne pas fonctionner de la même manière, et ne peuvent certainement pas être gérée de manière uniforme. Les mises à jour doivent être effectuées sur chaque site indépendamment et l'administration ne peut pas être effectuée de manière centralisée. Les utilisateurs devront se connecter sur chaque site individuellement pour y apporter des modifications, etc. Bien que dans la plupart des cas il y aura un système tiers d'authentification (LDAP, CAS), un compte utilisateur séparé sera toujours nécessaire pour chaque site Internet.

Une autre considération est le partage de contenu. Dans cette architecture, il ne sera pas possible de partager un même contenu entre plusieurs sites. Bien qu'il soit possible de transmettre des données entre plusieurs sites (en utilisant les flux RSS par exemple), la réplication complète de noeuds entre sites n'est pas une tâche simple, même dans Drupal 7, et peut nécessiter un effort important. Cette stratégie peut également avoir des implications pour le référencement (en raison de la duplication de contenu), pour les droits de modification (qui ne peuvent pas être transposés sur chacun des sites), pour la synchronisation de ces contenus partagés quand ils sont modifiés, et ainsi de suite. Bref la mise en place d'un tel partage va soulever de nombreuses problématiques.

Dans cette approche, chaque site peut être sur un domaine distinct mais peut aussi être installé comme un sous-répertoire sur un seul domaine.

Cette approche est à prendre en considération quand les sites auront des architectures distinctes avec un contenu distinct. Cela peut fournir une grande flexibilité, tout en permettant à l'organisation de standardiser sur une seule plate-forme technologique en interne.

Installations distinctes avec Features

Une légère variation de cette architecture d'installations distinctes est possible avec le module Features. Pour ceux qui ne connaissent pas encore, Features est essentiellement un outil qui permet d'exporter les configurations de Drupal au sein du code, de sorte qu'elles peuvent être transposées d'un site à l'autre très facilement, et bénéficier ainsi également de la sécurité d'un système de contrôle de version de fichiers tel que Git.

Même si les sites sont physiquement séparés, ils peuvent être unifiés par la construction d'un ensemble commun de modules Features déployés (et tenus à jour) sur chacun des sites. Les configurations candidates à ce système sont par exemple les contenus de type événement et leurs vues associées, les contenus de type actualités et leurs vues associées, etc. Ce genre de normalisation peut faciliter aux administrateurs leurs va-et-vient entre ces sites, ainsi qu'une éventuelle migration ultérieure vers une seule installation Drupal de toute cette galaxie de sites.

La limite de cette approche est que tout n'est pas "featurizable" avec Drupal 7. Une grande partie de la configuration de Drupal est souvent à mi-chemin entre le contenu et la configuration, ce qui rend, par exemple, les éléments de menu non exportables dans le code

A titre d'exemple, une fonction "Calendrier" peut être construite avec un type de contenu événement, les vues associées, peut-être une page ou deux, quelques panneaux, et peut-être un style d'image. Ce paquet de configuration peut alors être installé sur plusieurs sites pour leur donner les mêmes fonctionnalités.

Dans la suite logique d'une telle stratégie, toute une série de configurations peut être conçue au travers de plusieurs modules Features qui vont être distribuées, dans un profil d'installation voire tout simplement avec une distribution dédiée. Dans ce cas, un nouveau site peut être généré avec 80% des fonctionnalités déjà activées. L'utilisation d'une distribution permettra d'y déployer bien sûr tous les modules Features standard, mais également de pré-régler certaines configurations non-featurizable et ainsi proposer un jeu de paramétrage commun à tous les sites, tout du moins à leur initialisation.

Un cas typique d'utilisation d'une telle stratégie consiste en la mise en production rapide de micro-sites pour différents événements, à durée de vie limitée donc, avec une configuration et un thème très similaire tout en laissant une grande liberté quand aux contenus et aux adaptations nécessaires.

A noter qu'avec l'arrivée de Drupal 8 et son nouveau système de gestion de la configuration, cette stratégie pourra être encore plus facilement mise en œuvre car désormais l'intégralité des configurations seront accessibles et déployables nativement depuis des fichiers de configuration au format YAML.

Multi-sites

schéma d'une architecture Drupal multi-site

Depuis des années, Drupal a la possibilité de propulser plusieurs sites depuis une seule installation de base. Dans ce cas, il n'existe qu'une seule copie du noyau de Drupal, mais chaque site dispose de son propre fichier de configuration, qui pointe vers une autre base de données. Du point de vue de la conception d'un site, cette stratégie est presque similaire à celle basée sur des installations distinctes. Chaque site doit être configuré de façon indépendante, mais chaque site peut également être configuré depuis une feature. Chaque site peut également vivre sur son propre domaine ou dans un sous-répertoire d'un site principal (même si ce cas nécessite une configuration spécifique du serveur Web).

L'avantage ici est pour les administrateurs de serveur. Il n'y a qu'une seule copie du noyau Drupal, et généralement un seul exemplaire de la plupart des modules, qui sont partagés par tous les sites. Cela rend plus facile la mise à jour d'un module car il faut mettre à jour une seule fois. Cependant, cela signifie également que vous ne pouvez pas facilement mettre à jour un module pour un seul site, sans mettre à jour pour chacun d'eux. La pertinence d'une telle stratégie va dépendre de l'ampleur de l'installation, du nombre de sites, et de la complexité que chaque site pourrait viser.

Un avantage indéniable est que les modules, les thèmes sont beaucoup plus faciles à gérer, car ils ne disposent que d'une seule instance. Ce qui est particulièrement bénéfique pour les thèmes de base. Une installation multi-sites de ce genre aura souvent un thème de base commun, et ensuite chaque site pourra implémenter un sous-thème spécifique pour personnaliser son look tout en conservant les grandes lignes éditoriales définies dans le thème de base.

Un autre avantage est une économie significative en matière d'utilisation de la mémoire vive des serveurs. Les serveurs  mettant en cache la version compilée de tous les fichiers PHP dans leur mémoire, une installation multi-sites entraîne des économies considérables pour le serveur, et pour le client économiquement parlant, comparée à de multiples installations distinctes.

Domain Access

Schéma d'une architecture Drupal Domain Access

Le besoin de disposer de plusieurs sites peut parfois ne pas en être rééllement un. Notamment pour ceux qui veulent "plusieurs sites" mais souhaitent une gestion unique de ceux-ci. Il s'agit moins ici d'avoir de vrais sites indépendants mais plutôt de les faire apparaître comme tels, comme s'il s'agissait de sites disposant de leur propre domaine. Dans ce cas, la solution à implémenter est la suite de modules Domain Access.

Domain Access (DA) est en fait un module de contrôle d'accès qui utilise le système de droits d'accès aux nœuds de Drupal. Avec Domain Access, un administrateur du site peut faire pointer plusieurs domaines vers une seule installation de Drupal. Drupal filtre alors tous les nœuds pour n'afficher que les contenus affectés à ces domaines spécifiques. Dans cette configuration, il n'existe qu'une seule base de données, une seule base de code, une seule base des utilisateurs, et un seul conteneur pour l'intégralité des contenus.

Du côté des avantages, l'administration du système est extrêmement facilitée. Il y a une seule base de code, une seule base de données, une seule base d'utilisateurs. Il permet également le partage de contenu entre les sites de manière très aisée, car il n'y a en fait qu'un seul site. L'affichage d'un contenu sur plusieurs domaines est une simple case à cocher. Dans le même temps, chaque site apparaît sous son propre nom de domaine (metier.organisation.fr par exemple) pour les visiteurs du site et peut faire croire à un site à part.

Domain Access est aussi l'un des mécanismes de partage de contenu les plus faciles d'utilisation, car les contenus ne sont pas réellement « partagés ». Tout contenu peut être associé à autant de domaines que nécessaire, lui permettant d'apparaître « dans ces sites ». Mais ce contenu reste un nœud unique dans le système, de sorte que les modifications apportées sont disponibles immédiatement dans toutes les « versions » diffusées dans la galaxie de sites.

Du côté des inconvénients, parce qu'il n'y a qu'un seul site, il n'y a qu'une seule structure des types de contenu, des vues, des panneaux, etc. Les types de contenu ne peuvent pas varier d'un site à l'autre parce qu'il n'y a qu'une seule installation de Drupal. En clair, l'ensemble des sites générés depuis Domain Access disposeront de la même architecture, puisqu'il s'agira en fait du même site qui donne accès à son contenu de façon granulaire en fonction des domaines utilisés pour y accéder.

Domain Access autorise toutefois quelques configurations spécifiques au domaine. Presque toutes les variables de configuration peuvent être définies distinctement selon le domaine, y compris le thème actif. Puisque les thèmes peuvent être différents, et que les thèmes peuvent implémenter un thème de base commun,  cela permet une énorme flexibilité sur le rendu, et donc le design, de chaque site.

Organic Groups

Schéma d'une architecture Drupal multi-sites avec Organic Groups

Organic Group (OG) est un module basé sur le système des entités de Drupal 7 et est extrêmement souple pour le regroupement de contenus dans un site unique pour simuler plusieurs "sites".

Avec OG, chaque noeud (en fait toute entité) peut être transformé en un «groupe», puis d'autres nœuds peuvent être associés à un ou plusieurs groupes. Selon la configuration, les différents groupes peuvent avoir une incidence sur la navigation, les alias de chemin, la sélection du thème, et ainsi de suite, pour donner l'impression que chaque groupe constitue en soi un « site » différent.

Dans sa version 7, OG est aussi en mesure de permettre une administration déléguée par groupe de manière saine, chaque groupe pouvant disposer de ses propres règles gérant les droits d'accès. Cela signifie, par exemple, que les utilisateurs peuvent modifier les nœuds d'un certain type dans certains groupes, mais pas dans les autres groupes.

Bien qu'Organic Groups soit très flexible, il a aussi ses limites. Comme Domain Access, le fait que ce soit un site Drupal unique avec une base de données unique signifie que les types de contenu disposeront de la même configuration sur tous les « sites » propulsés par OG. Alors que OG peut faire varier le thème du « site », il ne peut pas modifier d'autres paramètres et la configuration générale. A noter que les différents sites sont accessibles depuis un sous-répertoire du site web principal.

L'utilisation d'Organic Groups, comme Domain Access, suppose donc une architecture cible suffisamment uniforme pour la galaxie de sites propulsés par ces deux solutions.

Une question de droits d'accès

De nombreux sites importants et complexes Drupal fonctionnent très bien comme un site unique sur un seul domaine. Souvent, ce qui est un "site" séparé dans l'esprit d'un client n'est pas réellement un site distinct, uniquement une partie d'un seul et même site. Notamment si la seule raison invoquée porte sur les différents contributeurs qui doivent disposer de droits « spécifiques » chacun sur leur propre « site ».

Dans ce cas des modules de gestion des processus de publication, tels que Workbench ou encore Workflow, peuvent tout à fait répondre à cette problématique.

Des solutions non exclusives

Selon les besoins et le contexte propre à chaque organisation, il est également possible d'envisager des stratégies combinant ces architectures multi-sites. Par exemple, Domain Access et Organic Groups peuvent être implémentés sur une instance Drupal qui se trouve être justement un site parmi d'autres d'une architecture multi-site. Et avoir d'autres sites distincts propulsés par le même noyau Drupal. Workbench peut être utilisé pour la gestion du processus de publication des contenus sur une seule instance Drupal indépendamment du fait qu'il utilise DA ou OG.

Schéma d'une architecture Drupal multi-site mixte

Un des points clés du choix de l'architecture est le partage des données. Drupal n'est pas vraiment conçu pour partager du contenu entre des instances Drupal distinctes, bien qu'il existe différentes méthodes mais qui auront des contraintes fortes ou nécessiteront un développement important.

Conclusion

Drupal offre une variété de solutions pour mettre en place une architecture de sites multiples, avec du contenu partagé ou non. Comme toujours avec Drupal, il n'y a pas de bonne solution : seulement des options pour vos besoins spécifiques.

Nous pouvons noter les critères suivants qui pourront vous aider au choix de votre architecture cible :

  • Facilité de création d'un nouveau site
  • Maintenance centralisée
  • Authentification unique (SSO)
  • Quantité de sites visée à moyen/long terme
  • Partage de contenus au travers de la galaxie de sites
  • Partage d'utilisateurs au travers de la galaxie de sites
  • Configurations identiques
  • De multiples sites avec des architectures différentes
  • Cohérence de la présence Internet
  • Design distinct pour chaque site
  • Disponibilité d'une url propre pour chaque site
  • Hébergement unique

Évaluez vos objectifs et prenez votre décision fondée sur ceux-ci. Drupal ne fait que vous donner toutes les clés pour les atteindre sans difficulté. N'hésitez pas à vous faire accompagner dès cette phase par un spécialiste Drupal qui pourra vous conseiller sur la meilleure architecture possible selon vos critères.

Ce billet est une traduction libre et adaptée de l'article Multi-headed Drupal.

Commentaires

Soumis par Sarah (non vérifié) le 29/01/2016 à 16:14 - Permalien

J'aimerais pouvoir implémenter le système de multisite sur une instance Drupal déjà existante. Mon but serait d'avoir deux sites distinct (url bien distinct, pas juste un sous domaine) mais qui pourrait éventuellement partager le même contenu (exemple : choisir de diffuser une actualité sur les 2 sites ou sur 1 seul). Une telle chose est-elle possible ?

Merci pour cet article très instructif :)

Merci, moi qui était persuadée que Domain Access ne servait que pour les sous-domaines (ne l'ayant utilisé que de cette façon) :)

Soumis par Gaius (non vérifié) le 05/07/2016 à 11:40 - Permalien

Je suis en train de dev un site sous DP8. La finalité étant d'avoir 3 déclinaisons, chacune sur un nom de domaine spécifique. Les URLs et les contenus sont tous partagés, mais possèdent un champ de type checkboxes multiple pour dire si on affiche ce node sur tel site ou non. Il y a également des différences coté CSS, mais que au niveau des couleurs, la structure reste la même.

Malheureusement, DP8 n'offre pas beaucoup d'alternative pour ce cas d'utilisation, et j'ai peur que le cache (qui est défini par l'URL) bloc le CSS dynamique en fonction de la déclinaison.

Je pense partir sur un multi-site en partageant toute la BDD mis a part les caches pour qu'ils soient distinct selon le point d'entrée.

Pensez-vous que cette solution est pérenne ?

Merci ;-)

Je ne me suis jamais essayé sur du multi-sites avec une base de données partagée. Et tous les retours que j'ai pu lire à ce sujet sont de cette teneur : ne faites pas cela ! Mais si vous vous y essayez je suis curieux de votre retour d'expérience :-)

Ajouter un commentaire