Blue/Green Drupal, mise en production sans interruption
Blue/Green : une continuité de services
Blue/Green est un modèle de déploiement applicatif qui nécessite la création de deux environnements en parallèle et ce afin de garantir une continuité de service lors de la bascule d’une version N à N+1 en production. Nous allons partir du principe que le projet Drupal est hébergé chez AWS.
Qu'est ce que la méthode Blue/Green ?
Il existe plusieurs types de mode de déploiement en production :
- Rip Replace : on remplace les anciennes sources par les nouvelles.
- Continuous : on ajoute les nouveaux codes aux anciennes sources
- Blue/Green : environnement en parallèle
C’est Blue/Green qui va nous intéresser ici. Un modèle de déploiement applicatif qui nécessite la création de deux environnements en parallèle et ce afin de garantir une continuité de service lors de la bascule d’une version N à N+1 en production.
Processus : On met à jour une version N+1 à côté de la version N et une fois celle-ci installée on bascule le trafic de la version N à la version N+1.
Voici un premier schéma explicatif :
Source : Amazon
Vous souhaitez en savoir plus ?
Prenez un rendez-vous de 15 minutes avec Hakim pour en discuter :
Hakim Rachidi
CTO & Head of DevOps Business Unit
Pourquoi Blue/Green n'est faisable que dans certains cas précis sur Drupal ?
Avec Drupal, le premier constat est que l’utilisation d’une unique base de données durant le processus n’est pas réalisable en l’état. Lors de la mise à jour, la maintenance du site sur Drupal 8 n’est pas obligatoire. Cependant la navigation n’est pas assurée, ce qui va à l’encontre de ce processus de mise à jour sans interruption. Il est donc fortement conseillé de passer le site en maintenance pendant la montée en version du schéma.
Le schéma sera donc plus proche de celui-ci :
Source : Nelap
Ou le MySQL de Green et un réplica du MySQL Blue juste avant la nouvelle installation de Green.
Comment mettre en place Blue/Green avec Drupal ?
Voici un schéma montrant une instance Drupal en production chez AWS. Cela représente l’instance Blue par exemple.
La mise en place de Blue/Green nécessitera la duplication de cette instance, cela implique donc un prix assez élevé.
Il est important de bien comprendre que durant la période de synchronisation des configurations (entre les nouvelles sources Drupal et la BDD), un temps de contribution sur le site pourra être perdu. Exemple :
- On lance la nouvelle installation de la version N+1
- On copie la BDD de la version N
- On lance les scripts de mise à jour.
Si durant ce laps de temps des contenus (node, entité ou user) sont créés, ils ne seront pas reportées sur la BDD N+1 (sauf si un script de maj de ces contenus est prévu à cet effet).
Quels sont les développements spécifiques à prévoir ?
Il y a d’autres points à prendre en considération pour la bonne mise en place de Drupal avec Blue/Green. Dans un premier temps, il faut sortir le stockage du cache de la BDD et le mettre dans Redis (ou Memcached) dans le but de pouvoir mutualiser ce dernier entre les deux instances.
Source : Redis
De la même façon les sessions utilisateurs peuvent être stocker dans Redis ce qui permettra de ne pas perdre les sessions lors de la bascule de Blue vers Green.
Source : Create submodule to store PHP sessions in Redis
Il sera donc important de se rapprocher du schéma suivant :
En ce qui concerne la perte de data lors de la procédure de déploiement, des modules comme entity_share pourront permettre de mettre en place une synchronisation entre les environnements au niveau des contenus.
Retour d'expérience Actency
Ce que nous pouvons dire en retour d’expérience c’est que ce processus ne peut s’appliquer qu’a certains types de projets Drupal.
Un projet qui génère beaucoup de contenus (node, commentaire etc.) à la minute ne sera pas adapté à ce mode de déploiement car il sera assez compliqué de rapatrier l’ensemble des contenus créés durant la procédure de déploiement.
Il est possible de bloquer temporairement les contributions afin d’éviter d’avoir des contenus à synchroniser. Cela peut être fait assez facilement en bloquant temporairement la page de connexion au site ainsi que celle de création de compte et de s’assurer que personne ne sera connecté sur le site ou ne pourra contribuer. Cependant il est sûr que ce système n’est pas idéal.
Cela nous montre bien que pour rendre ce mode de déploiement possible avec Drupal, il faut préparer en amont l’infrastructure ainsi que le socle applicatif. C’est donc à la création de l’environnement qu’il faudra se poser ces questions. Il est d’ailleurs très difficile d’envisager cette méthode de déploiement sur un projet déjà existant et qui ne prend pas en compte les éléments cités précédemment.
