Modifier de la configuration directement sur un site Drupal 8 en production

Clip de cinéma

La gestion de la configuration native à Drupal 8 permet de très facilement passer des modifications ou des ajouts de la configuration depuis une instance de site (un environnement de développement par exemple) vers une autre instance de site (l'environnement de production). Ces exports et imports de la configuration d'un site sont réalisés d'un seul tenant : c'est à dire que c'est toute la configuration d'un site qui est mise à jour. Ainsi si des ajouts de configuration ont été réalisés sur le site de production, celles-ci seront écrasées au prochain import de la configuration si ces configurations ne sont pas présentes également sur l'environnement source.

Mais il existe des cas valides où certaines configurations peuvent et doivent être modifiées directement en production. Les cas d'usage immédiats sont par exemple la création de nouveaux formulaires Webform, ou encore la création ou mises à jour de nouvelles Newsletters gérées avec le module SimpleNews. Il est tout à fait légitime qu'un webmestre puisse modifier ou créer de nouvelles NewsLetters sur le site de production. Cela s'apparente presque à un contenu, sauf que...il s'agit ici d'entités de configuration.

Découvrons comment gérer ces cas particuliers avec le module Configuration split, module qui va nous permettre de conserver un processus organisé pour gérer l'évolution et la maintenance d'un site en production tout en permettant la modification en live de certaines configurations.

Configuration du module Configuration split

Nous allons illustrer la configuration à mettre en place pour permettre aux utilisateurs de créer de nouvelles Newsletters de Simplenews sur le site de production.

Après avoir installé le module Configuration Split, nous créons un nouveau paramètre pour ce module. Nous supposons que le projet Drupal 8 est basé sur composer et que son dossier de synchronisation est situé sur le chemin ../config/sync par rapport à docroot du projet. 

En premier nous créons un nouveau répertoire ../config/excluded. Ce répertoire accueillera les fichiers YML des configurations qui auront été créés en production.

Puis nous définissons un nouveau paramètre Configuration Split.

Configuration split settings

Nous lui donnons un nom, lui indiquons le répertoire de stockage des fichiers de configuration créé précédemment (../config/excluded), puis la chose la plus importante : nous n'activons pas cette configuration en laissant décochée l'option Active.

Nous continuons la configuration, en utilisant la section Conditionnal Split

Configuration split conditionnal

Nous pouvons ici sélectionner une configuration existante, ou encore indiquer des configurations au moyen de wildcard. Ici nous indiquons de découper les configurations de toutes les newsletters Simplenews, au moyen des fichiers simplenews.newsletter.*. Et nous activons l'option Split only when different, qui nous permet de conserver les configurations identiques entre les environnements dans le répertoire de synchronisation principal contenant tous les fichiers de configuration du site.

Puis nous pouvons enregistrer, pour obtenir.

Configuration split status

 

Notez encore une fois le status Inactif de notre configuration. Elle doit rester ainsi sur tous les environnements source autre que la production.

Nouveau processus d'import de la configuration

Une fois cette configuration créée, nous l'exportons puis la committons sur notre dépôt puis la déployons sur tous nos environnements, donc celui de production. Par exemple comme ceci, mais bien sûr cela est à adapter au processus en cours.

dev > drush cex
dev > git add .
dev > git commit -m "config split excluded"
dev > git push

prod > git pull
prod > drush cim

 

Une fois cette configuration excluded importée sur le site de production, nous allons l'activer depuis le fichier settings.php en ajoutant une surcharge de configuration, surcharge qui bien évidemment ne sera présente que sur l'environnement de production.

<?php

// This will allow module config per environment and exclude newsletter from being overridden
$config['config_split.config_split.excluded']['status'] = TRUE;

 

Et nous obtenons sur notre site en production notre configuration Excluded qui est désormais activée.

Config split active on production

 

Et c'est fini, ou presque. Désormais il conviendra avant tout import de configuration sur le site en production, de lancer au préalable un export de la configuration excluded au moyen de la commande drush config-split export (ou drush csex).

Cette commande va détecter si de nouvelles configurations sont présentes sur le site de production, ou si celles existantes ont été modifiées, par rapport à la configuration générale du site, et le cas échéant va exporter ces configurations modifiées ou ajoutées dans le répertoire ../config/excluded.

Et la commande générale d'import de la configuration, drush cim, va alors rassembler à la fois la configuration présente dans le répertoire principal ../config/sync, et également la configuration présente dans le répertoire ../config/excluded.

Le nouveau processus de mise à jour et d'import de la configuration sur l'environnement de production peut alors ressembler à cela

prod> drush csex -y excluded
prod> drush cim -y

Ou encore au moyen d'un petit script shell

#!/bin/bash
echo "-----------------------------------------------------------"
echo "Exporting excluded config"
drush csex -y excluded

echo "-----------------------------------------------------------"
echo "Importing configuration"
drush cim -y

Désormais, vous pourrez créer et gérer nos Newsletters aussi simplement qu'il s'agissait de contenus, directement sur le site de production. Bien sûr le même concept peut s'appliquer à toute configuration que vous souhaitez pouvoir gérer en production : les formulaires Webform par exemple, ou encore le positionnement de certains blocs, etc. tout en conservant un processus structuré pour maintenir votre site en production au moyen de la gestion de la configuration de Drupal 8.

Merci à Jon Minder pour son article Advanced Drupal 8 Configuration Management (CMI) Workflows qui m'a plus qu'aidé, et bien sûr au créateur et mainteneur de ce module particulièrement utile.

 

Commentaires

Soumis par Thomas (non vérifié) le 24/01/2020 à 19:05 - Permalien

Bonjour,
très bon article.
Le titre de l'article suggère d'utiliser "prod > git pull et prod > drush cim" sans mettre le site en maintenance. Est-ce qu'il est possible de procéder à l'import sans mettre le site en maintenance ou il faut le mettre ne serait-ce que quelques secondes en maintenance le temps que les commandes s'exécutent?

Soumis par fabrice le 25/01/2020 à 01:15 - Permalien

Bonjour,
Dans le doute oui il est préférable de mettre en maintenance juste avant. Mais pour certaines mises à jour / import de configuration cela n'est pas vraiment nécessaire (pour ne pas dire inutile). Le tout est de bien maitriser et connaitre le contenu des mises à jour déployées sur le site. Bien sûr dans une prespective d'automatisation, il est plus sûr d'inclure la mise en maintenance dans le processus.

Ajouter un commentaire