Vous n’avez pas besoin d’un multisite Drupal 8

Auteur(s) de l'article

Depuis quelque temps on me demande si l'architecture multisite sur Drupal 8 est une option à considérer pour certains projets.
Au risque de lancer un pavé dans la mare - de mon expérience - une instance Drupal multisite est rarement une bonne idée, encore plus avec Drupal 8.
À la fin de cet article, vous serez à même de répondre à la question "Dois-je considérer une architecture multisite pour mon/mes projet(s) Drupal 8 ?".
Petit aparté avant le gros du sujet, contrairement à mon habitude, cet article n'est pas une explication technique/code d'un aspect de Drupal 8.
Je m'intéresse ici uniquement aux avantages et inconvénients inhérents à l'architecture multisite.
Pour ceux qui recherchent une explication technique, je donne quelques liens à la fin de ce billet qui décrivent l'implémentation technique d'un projet multisite sous Drupal 7 et Drupal 8.

Qu'est-ce qu'un multisite ?

Pour celles et ceux qui ne sont pas à l'aise avec la dénomination, une installation multisite permet à une seule instance Drupal de servir plusieurs sites, sous différents noms de domaines. Chaque site aura sa propre base de données et ses propres paramètres de configuration. Chaque site aura donc son propre contenu, ses paramètres, ses modules activés et son thème activé. Cependant, les sites partagent une base de code - aussi dit "codebase" - commune.
Ceci dit, il ne faut pas confondre l'implémentation Drupal multisite avec la fonctionnalité WordPress "Site Networks" - qui est également appelée multisite par abus de langage. Contrairement à WP Site Networks, une installation Drupal multisite ne contient pas d'interface ni d'API permettant de gérer vos sites. Drupal multisite consiste uniquement à changer la connexion aux bases de données via son URL d'entrée. Ainsi, le site foo.example.org et bar.example.org sont des instances Drupal multisite proposant un contenu différent tout en partageant une codebase identique.
L'implémentation est certes un "hack" mais il reste élégant et intelligent, en particulier pour ceux qui construisent et entretiennent de nombreux sites identiques.
La promesse faite est la réduction considérable des coûts et des efforts de maintenance, et constitue sans aucun doute un bon moyen de regrouper la plupart de ses sites sur un seul serveur. Cependant, comme pour beaucoup de hacks, il comporte des risques importants.

Should I stay or should I go ?

Voyons maintenant en détail quels sont les arguments en faveur et en défaveur d'une installation multisite.

Simplification de l'infrastructure

Tous les sites seront installés sur le même serveur !

Ben

un SysAdmin un peu lazy

Lorsqu'on installe une instance multisite, il s'avère souvent que tous les sites sont ensuite servis par un seul serveur.
Au premier coup d'oeil, l'équipe s'occupant de l'infrastructure sera aux anges, il lui faudra installer le minimum viable afin de faire fonctionner l'ensemble des sites.
Cependant, le problème le plus évident lié à l'exécution d'un grand nombre de sites sur une base de code est que l'un d'eux peut être confronté à un pic de trafic et avoir un impact négatif sur le reste des projets.
Vous prenez ainsi le risque que le meilleur jour d'un site soit le pire des 99 autres. Si vous souhaitez desservir un grand nombre de sites en un rien de temps, vous êtes plutôt bien parti...

Réduction de l'espace de stockage

Nous allons gagner en espace de stockage !

Laura

comptable dans l'âme

En effet, l'installation d'une seule instance Drupal va permettre de réduire drastiquement l'espace disque sur votre serveur.
Mais restons réalise, l'espace disque ne vaut plus grand-chose de nos jours, ce n'est pas vraiment un avantage que je qualifierais d'intéressant en 2019.

Simplification des mises à jour et amélioration de la sécurité

Nous allons pouvoir simplifier notre processus de mise à jour et être mieux protégés des exploits !

Hackerman

Laissez-moi découper mon argumentaire en 2 points: mises à jour et sécurité.
Du point de vue des mises à jour: s'il est vrai que la mise à niveau d'un projet Drupal 7 était laborieuse, ce n'est plus le cas avec Drupal 8 et l'avènement de Composer.
Grâce à la gestion des dépendances avec Composer, la maintenance et la mise à jour des modules et du Core sont simplifiés. Il est possible de mettre à jour un projet Drupal 8 en 3 lignes de commandes !
De plus, l'automatisation des déploiements est rendue possible avec plusieurs technologies dont, par exemple, Capistrano et la gem CapDrupal, qui permet de mettre à jour plusieurs sites automatiquement en lançant la commande ou via un système de déploiement continu.
En outre, l'absence de segmentation entre les sites crée un risque de sécurité important. Puisqu'il n'y a pas vraiment de séparation entre un site et un autre, si l'un d'entre eux est compromis, vous devez supposer que tous les sites sont corrompus.
Spaceship attacking Drupal 8 instances in the "Multisite-Land" zone.

Simplification du code

Nos développeurs ne devront gérer qu'une seule codebase, nous allons réduire la complexité

Jérémy

optimiste utopique

Supposons que l'équipe de développement ne fait jamais d'erreurs (ha!) et que le système de test est littéralement à l'épreuve des balles (ha ha!), aucun souci ne peut donc survenir! ... hélas!
Dans un monde où une erreur de syntaxe peut anéantir une centaine de sites Web, les équipes commencent à se montrer très prudentes face au déploiement. Le processus de test peut ainsi devenir excessivement fastidieux et des déploiements en dehors des heures de bureau/tard dans la nuit commencent à apparaître.
A stable drupal vault hermetic to an update pill.
Gardez à l'esprit qu'effectuer une mise à jour Drupal est parfois délicat, surtout lorsque nous parlons de mises à jour majeures du Core. Il faut souvent exécuter des commandes supplémentaires telles que drush updatedb et drush entup et il est généralement impossible de lancer ces commandes sur un grand nombre de sites simultanément.
N'oublions pas le fait que certaines mises à niveau peuvent ne pas se dérouler sans heurts.
C'est à vous de déterminer comment vous voulez gérer cela, et les résultats sont souvent... désastreux et désordonnés.

Quand utiliser un multisite?

Maintenant que je vous ai vraiment bien dégoûté de l'architecture multisite, listons les arguments habituels pour sa mise en place. Aussi, ne peignons pas le diable sur la muraille, le multisite est parfois nécessaire:
  • Les sites sont à destination du même client et le multisite permet de simplifier le scope de chaque site - Pourquoi pas
  • Les sites utilisent exactement les mêmes fonctionnalités & modules/thèmes (sans exceptions) - Pourquoi pas
  • Les sites sont strictement identiques, à l'exception du thème - Pourquoi pas
  • Le multisite va résoudre nos problème de mise à jours - Nope
  • Les sites proposent des fonctionnalités différentes et/ou ont des divergences dans les modules - Nope
  • Les sites utilisent des distributions différentes - Nope
  • Nos ressources internes sont limitées - Nope
  • Les sites sont à destination de clients différents - Nope
Un débat - survenu à la DrupalCon 2014, à Austin - sur la question du multisite est disponible sur YouTube.
A Drupal TV channel on YouTube with 2 clans of Space Invaders on both sides of the tv set.

Conclusion

Le multisite reste une solution de développeurs classique. Très avantageux au début du projet et constituant un hack intelligent, son implémentation peut poser de graves problèmes et nécessite beaucoup de développement sur mesure et/ou d'interventions manuelles pour évoluer dans le temps.
De mon point de vue, la solution multisite fonctionne uniquement lorsque les différences entre les sites sont limitées au contenu.
Une implémentation durable nécessite une politique de tolérance zéro en matière de déviation de code entre les sites. Cela implique souvent de limiter l'évolution ou l'ajout de fonctionnalités indépendamment des sites. Mais comme on le sait tous, l'ajout de fonctionnalité est inhérent au Web, il peut donc être difficile de s'en tenir à une politique stricte.
Les problèmes cités précedemment s'appliquent même dans les meilleures circonstances. Si vous ne pouvez empêcher vos sites de diverger, ce n'est qu'une question de temps avant que vos meilleurs développeurs passent leur temps à exécuter des tâches lourdes et risquées afin de maintenir un semblant de cohérence dans votre architecture multisites.
Quoi qu’il en soit, n’hésitez pas à nous contacter pour vous conseiller sur la meilleure stratégie à adopter en relation avec votre projet.
A stripe of different colorful Space Invaders characters.

Sources

Pour les plus curieux d'entre vous, voici quelques sources d'informations complémentaires ayant inspiré la création de cet article.
Nadine Alladine (30 octobre 2017). More profits & less effort with Drupal multisite functionality
Voir sur https://internetdevels.com/blog/drupal...
Josh Koenig (20 juin 2017). Drupal Multisite: Much Ado About Drupal Multisite
Voir sur https://pantheon.io/blog/drupal...
Acquia (16 décembre 2018). About Drupal multisite installations
Voir sur https://docs.acquia.com/acquia-cloud/...
Drupal 8 Documentations (20 août 2018). Multisite Drupal 8
Voir sur https://www.drupal.org/docs/8/multisite
Drupal 7 Documentations (5 février 2018). Multisite Drupal 7
Voir sur https://www.drupal.org/docs/7/multisite
Contributeurs (14 Août 2018). Discuss whether to deprecate multisite for removal in 9.x
Voir sur https://www.drupal.org/project/drupal/../../
The copyright for Space Invaders is held by the Taito Corporation and is licensed to Midway in the US.