Usine à site : première approche en mode multisite

Après notre article sur la migration vers Drupal 9, nous poursuivons nos articles de fond et vous partageons aujourd’hui notre réflexion sur les enjeux des usines à sites.

Le développement logiciel a fortement évolué ces 20 dernières années passant d’un mode artisanal à un fonctionnement industrialisé. On retrouve cet aspect notamment dans les pratiques DevOps où l’automatisme va de pair avec le contrôle qualité. Finalement, on cherche à se rapprocher du monde de l’industrie traditionnelle produisant à la chaîne rapidement et efficacement. 

Pour aller plus loin dans ce rapprochement avec le monde industriel, est apparu le concept d’usine à sites. Chez Digiwin, ce concept est mis en œuvre avec succès en s’appuyant sur le puissant CMS Drupal. Nous allons vous présenter ici ce travail, cette expérience, depuis nos débuts jusqu’à notre solution actuelle d’usine à sites.  

Petit rappel sur Drupal

Drupal est un CMS (Content Management System), ce que nous traduirons en français par « système de gestion de contenu ». Pour la petite histoire, son nom vient du vient du néerlandais « Druppel » qui signifie « goutte », d’où son logo. 

Son développeur initial le définit comme un assembleur rapide de site web utilisable tel quel sur un serveur web. Il peut être utilisé et personnalisé de plusieurs manières, graduellement plus complexes, en fonction du niveau de connaissance : 

• Out of the box : il permet de s’authentifier, gérer les révisions, créer ses propres types de contenus, menus, etc… 
• Personnalisation simple : il permet de modifier l’emplacement des éléments graphiques par simple drag and drop et de modifier l’apparence du site en utilisant un thème différent, directement à partir du back-office. 
• Extension des fonctionnalités par ajout de modules issus de la communauté 
• Extension des fonctionnalités par développement interne, ou par le développement de ses propres modules qui peuvent à leur tour être partagés, ou pas, avec la communauté. 

Drupal possède en outre une hiérarchie de fonctions substituables qui permet aux développeurs expérimentés de réécrire une partie du fonctionnement du site sans toucher au reste (système de hook). 

Toute cette modularité permet une grande richesse de personnalisation, mais présente quelques défauts, notamment son modèle de base de données. Plutôt complexe, elle peut contenir plusieurs centaines de tables en fonction des types de contenus créés et des modules utilisés.

Définition d’un Multisite sous Drupal

Une installation multi-site permet à une seule instance Drupal (codebase identique) de servir plusieurs sites ayant des noms de domaines différents. Chaque site possède sa propre base de données et donc son propre paramétrage, ses propres contenus, ses propres modules et thèmes activés. 

Dans une architecture multisite, les sites auront souvent un thème de base commun et chaque site pourra implémenter un sous-thème spécifique pour personnaliser son look tout en conservant les grandes lignes graphiques définies dans le thème de base. 

Comme des frères et sœurs, les sites d’une architecture multisites peuvent se ressembler et se comporter de la même manière ou avoir chacun son propre style. Ils partagent le même ADN. 

Malgré tout, la maintenance et la mise à niveau des sites peut devenir complexe et chronophage en fonction du nombre de sites. 

Même si les montées de version sont moins laborieuses grâce à la gestion des dépendances avec Composer, la montée de version du cœur impactera l’ensemble des sites en même temps. Tous les sites seront alors mis en maintenance au même moment.  

De plus, suite à une montée de version, pour des mises à jour majeures du Core de Drupal, il faut souvent exécuter des commandes supplémentaires. Elles permettent de mettre à jour la structure de la base de données, mais il est généralement impossible de les lancer sur un grand nombre de sites simultanément. 

Il faut ensuite tester le bon fonctionnement de tous les sites, et éventuellement les corriger, avant de les remettre en ligne. 

Définition d’une Usine à Site

Le concept d’usine à sites est souvent confondu avec le concept de multisite. Comme énoncé précédemment, le multisite permet de gérer plusieurs sites avec une seule instance du socle CMS.  

Quant à elle, l’usine à sites permet d’industrialiser, voire d’automatiser, la création et les déploiements de nouveaux sites. 

Ses principaux avantages sont de : 

• Donner un cadre commun en harmonisant les pratiques 
• Diminuer les coûts de production de chaque site 
• Diminuer les coûts de maintenance 
• Mutualiser les moyens (maintenance, hébergement, etc.) 

Notre première rencontre avec une usine à site sous Drupal

Contexte de mise en oeuvre d’un multisite avec Drupal

Notre première rencontre avec une usine à sites Drupal a eu lieu lors d’une mission chez SNCF Réseau. Installé en multisite, l’usage de Drupal permettait de déployer un grand nombre de sites. La majorité de ces sites était dédiée à l’évènementiel (durée de vie courte, besoin de mise en œuvre rapide).  

Plusieurs aspects se sont avérés fastidieux dès la première approche. Si cet écosystème de sites était présenté comme une usine à sites, il n’y avait en réalité que peu d’automatismes. La majorité des actions de création de sites étaient réalisées par copie d’un des modèles de sites existants.  

De plus, nous avons fait face à un autre niveau de complexité lié à un des inconvénients de Drupal multisite. Comme expliqué précédemment, la mise à niveau du Core de Drupal nécessite de mettre à niveau tous les sites. Cette action entraine alors une quantité de travail significative avec parfois des problèmes majeurs à résoudre liés à des modules non compatibles. 

Pour s’éviter ces désagrément, l’usine à sites était composée de plusieurs installations de Drupal, une par version, les sites étant déployés sur l’une ou l’autre des versions. L’upgrade consistait en fait alors à migrer un site d’une installation de Drupal à l’autre.  

La solution est plutôt censée. Pour autant, elle comporte quelques inconvénients, notamment lorsque l’on effectue une modification des templates de bases à faire obligatoirement sur chaque installation. 

Nouveau virage : création d’un outil de commande sous Symfony Console

Pour faciliter notre gestion et renforcer l’aspect industriel de l’usine à sites, nous avons développé un outil en ligne de commande basé sur Symfony Console. Ainsi, les différentes étapes de la création à la mise en ligne étaient automatisées. 

Cet outil que nous avons appelé OXYGEN, développé pour Drupal 7 puis étendu à la gestion de sites en version Drupal 8, nous permettait de :  

• Dupliquer un site (fichiers, base de données, configuration) 
• Rajouter le nouveau site dans le fichier sites.php 
• Rajouter le vhost afin qu’il soit accessible en ligne via son propre nom de domaine 

Nous avons étendu ces fonctionnalités à d’autres actions que nous faisions régulièrement : 

• Mettre en production à partir de la version de recette 
• Récupérer la version de production d’un site en local pour évolution et débogage 
• Archiver des sites 
• Mettre en maintenance des sites 

Le niveau d’automatisme atteint était plutôt satisfaisant, rendant nos interventions efficaces et productives. Mais c’est alors que le client a exprimé une nouvelle demande : être autonome pour la création des sites les plus simples.  

OXYGEN étant un outil en ligne de commande et donc non orienté tout public dans son utilisation, il ne constituait pas une réponse acceptable pour le client. Nous avons donc développé un module spécifique dédié à cette gestion.  

Développement d’un module sous Drupal 8 dans un écosystème D7 et D8

Notre module est développé sous Drupal 8 directement. A cause de la rupture technologique avec la version 7 et de la migration en D8 sur la quasi-totalité des sites, développer un module sous Drupal 7 avec une adaptation Drupal 8 est inutilement coûteux. Comme nous l’avons cité dans un article, passer de D7 à D8 est bien plus complexe que la migration de Drupal 8 vers Drupal 9.

Installé sur un site spécifique de l’usine à sites, ce module effectue les mêmes actions qu’OXYGEN mais depuis une interface web.  

Cette solution peut sembler idéale et elle l’était d’un point de vue utilisateur. Mais en réalité, elle reste tributaire des défauts du multisite Drupal en termes de maintenance technique. C’est pourquoi, nous avons commencé à imaginer une usine à sites sans le multisite Drupal, solution que nous utilisons désormais.

Notre prochain article « Usine à sites Drupal : la version de la maturité » expliquera comment utiliser une usine à site Drupal sans multisite.