Modes de déploiement continu : Rolling-upgrade, Blue-Green, Canary

Article écrit par Mahdi Konzali

En travaillant sur des plateformes digitales de haute disponibilité tels que les sites e-commerce, les agences en ligne ou les réseaux sociaux, et en tenant compte du progrès de l’agilité, on constate le besoin des déploiements de plus en plus fréquents d’un côté, et de la transparence et la sûreté des opérations de l’autre côté, d’où l’importance des modes de déploiement continu.

Dans cet article, on s’intéresse aux trois modes les plus connus et que j’ai eu la chance de pratiquer, savoir leurs caractéristiques et comprendre leurs différences, une chose qui peut aider à savoir quel mode choisir pour son application.

Rolling upgrade

Le Rolling upgrade consiste à installer une nouvelle version de l’application d’une façon séquentielle en procédant par une ou plusieurs instances. Ce mode assure la continuité de service, car il ne traite qu’une partie de l’infrastructure à la fois.

Le Rolling Upgrade est conseillé dans les cas suivants :

• Application qui supporte avoir deux différentes versions accessibles en même temps
• Hot-fix, car il n’introduit pas un changement fonctionnel

Blue green

Le mode Blue/Green consiste à avoir deux versions N et N+1 déployées en production en même temps, mais seulement une version est ouverte au public, l’autre est en prod. caché ou PAB (Prod. à blanc).

Démarche :

• Déploiement en PAB (cibler les instances cachées lors du déploiement)
• Tests en PAB (cibler la nouvelle version par des cookies ou un lien interne)
• Switch (à l’aide du load balancer)

Ce mode permet aux équipes de tester le livrable sur l’environnement de production avant ouverture au public. De ce fait, il est très utile pour vérifier les variables et les propriétés de cet environnement. En cas de test non-valide, le switch sera annulé, et l’équipe travaillera sur un fix sans aucun impact sur les utilisateurs.

Dans le cas où on détecte une anomalie bloquante sur la production après déploiement, le rollback sera rapide, en faisant un nouveau Switch qui mettra la version N en avant. Pour cela, il est conseillé de garder la version N en PAB tout au long de la durée de maturité de la version N+1.

Canary release

Le canary release Deployment est une exposition progressive qui offre encore plus de souplesse et réduit de façon énorme le risque de bogue en production.

C’est une technique permettant l’introduction progressive d’une nouvelle version d’une application en ciblant un nombre restreint d’utilisateurs. Tant que les retours sont satisfaisants, elle sera accessible à un nombre plus important, jusqu’à une exposition complète à l’ensemble des utilisateurs.

Démarche :

• Déploiement de la version N+1 en PAB

• Ouverture à un petit nombre de clients
• Exposition progressive aux clients
• Exposition totale (2 versions ouvertes)
• Fermeture des instances de la version N

De façon pratique, une fois que l’application est déployée en PAB (vert), un petit nombre d’utilisateurs sont redirigés vers cette dernière, tandis que l’environnement Blue continue à recevoir le gros du trafic, c’est le Load Balancer qui assure la répartition des charges entre les deux versions. Des indicateurs de télémétrie sont alors utilisés pour évaluer la nouvelle application à chaque étape.

Finalement, on se retrouve en production avec une version assez mature et qui a quasiment déjà fait ses preuves.

Exemple : Facebook

Si vous avez remarqué un jour que votre version de Facebook est différente de celle de votre ami, ce n’est pas votre smartphone qui commence à vieillir, c’est juste que vous et votre ami n’êtes pas dans la même plage d’utilisateurs définie par l’algorithme. Facebook est parmi les premières boites qui utilise ce mode de déploiement, et c’est pour des fins techniques et fonctionnelles. Ces déploiements durent en général des jours, pour collecter le maximum de retours d’utilisateurs et des rapports de bogue.

Points d’attention

Sessions HTTP et répartition de charge

Le point technique qui présente une problématique pour ces modes de déploiement est la gestion des sessions utilisateurs qui est primordiale à la transparence de l’opération et la continuité de service. Nous pouvons citer deux façons de gérer les sessions :

Affinité de session :
Lorsqu’un utilisateur arrive sans session, il est redirigé aléatoirement sur un des serveurs, sur lequel il crée une session.
Le mécanisme de répartition de charge s’assure ensuite que cet utilisateur est toujours redirigé sur ce même serveur. Pour cela, nous pouvons se servir des cookies, c’est qu’on appelle « Affinité basée sur les cookies ».

Ce mécanisme pose des problèmes lors du Blue/Green ou Canary Deployment. En effet, les utilisateurs liés au serveur qui sera isolé et mis à jour, perdront leurs sessions et devront se reconnecter.
Pour remédier à cela, nous pouvons sortir les instances par étape :

• Fermer l’accès vers l’instance pour les nouveaux arrivants (clients)
• Attendre la sortie des utilisateurs sur cette instance (durée attente >= durée de vie d’une session)
• Fermer totalement l’acces à l’instance

HAProxy fournit une fonctionnalité qui gèrent bien de modèle en faisant appel aux flags (up, stop, down) où le flag stop assure le “drain” d’une instance en fermant l’accès aux nouveaux utilisateurs.

Sessions partagées :
Les données des sessions sont stockées dans un serveur cache partagé (redis, memcached ..).
Les serveurs applicatifs partagent une même cache de session, donc les utilisateurs n’ont pas besoin de frapper la même instance à chaque fois.

Ce type de mécanisme est plus adapté aux modes de déploiement Blue/green et Canary. Il facilite le processus et élimine la complexité de gestion de session par les cookies et les ACLs.

Base des données

Les bases de données peuvent souvent être un défi avec ces techniques de déploiement continu, en particulier lorsque vous devez modifier le schéma pour prendre en charge une nouvelle version de l’application. Car les différents serveurs applicatifs pointent vers le même serveur (ou cluster) des données.
L’astuce consiste à séparer le déploiement des modifications de schéma des mises à niveau des applications. Commencez par appliquer une re-factorisation de la base de données pour modifier le schéma afin de prendre en charge à la fois la nouvelle et l’ancienne version de l’application, déployez-la, vérifiez que tout fonctionne correctement afin d’avoir un point de restauration, puis déployez la nouvelle version de l’application. Et une fois la mise à niveau terminée et l’application est stable, appliquez une deuxième migration de schéma afin de supprimer la prise en charge de l’ancienne version.

Exemple