Le déploiement bleu-vert, c'est un répartiteur et une doublure

L'affirmation

Le déploiement sans interruption et le retour arrière instantané sont souvent traités comme des capacités avancées exigeant un orchestrateur de conteneurs et une équipe de plateforme. Pour une application unique sur deux ou trois serveurs, ils n'exigent ni l'un ni l'autre — ils exigent un répartiteur de charge, une seconde copie de votre application, et la discipline de basculer le trafic entre elles. Le déploiement bleu-vert est l'une des pratiques de fiabilité au plus fort rendement qu'une petite équipe puisse adopter, et la version qui convient à une petite équipe est réellement simple.

L'idée en un paragraphe

Vous exploitez deux environnements de production identiques, appelés bleu et vert. À tout moment, l'un est en service et sert tout le trafic pendant que l'autre est inactif. Pour déployer, vous livrez la nouvelle version à l'environnement inactif, vous l'y testez pendant qu'il ne reçoit aucun trafic réel, puis vous basculez le répartiteur pour lui envoyer le trafic. L'environnement autrefois en service est maintenant inactif et détient la version précédente, intacte. Si la nouvelle version se comporte mal, vous rebasculez — et parce que l'ancien environnement n'a jamais été modifié, le retour arrière est instantané et total, non un redéploiement mais une redirection.

Pourquoi cela bat le déploiement sur place

L'alternative courante — mettre à jour l'application sur le serveur en service — a deux problèmes que le bleu-vert supprime. D'abord, il y a une fenêtre pendant la mise à jour sur place où l'application s'arrête, redémarre ou tourne à moitié mise à jour, et pendant cette fenêtre des requêtes échouent. Le bleu-vert n'a pas de telle fenêtre, car la bascule se fait entre deux environnements pleinement prêts. Ensuite, revenir en arrière d'un déploiement sur place signifie redéployer, à l'envers, sous pression, en espérant que la version précédente se construise et démarre encore proprement — alors que le retour bleu-vert est un basculement vers un environnement qui exécute déjà l'ancienne version et qu'on sait fonctionnel.

Tout le mécanisme

Avec Nginx comme répartiteur, la bascule est une seule ligne et un rechargement :

# /etc/nginx/upstream.conf  -- la seule chose qui change a la bascule
upstream app {
    server 10.0.1.10:8080;   # bleu   (en service)
    # server 10.0.1.11:8080; # vert   (inactif, la prochaine version va ici)
}

La séquence de déploiement devient un script que n'importe qui peut exécuter et comprendre :

1. Deployer la nouvelle version a l'environnement inactif (vert)
2. Executer les sondes et un test de fumee contre vert directement
3. Basculer : pointer upstream vers vert, `nginx -s reload`
4. Surveiller les taux d'erreur quelques minutes
5. Si mauvais : rebasculer vers bleu, `nginx -s reload`  -- instantane
6. Si bon : bleu devient la doublure inactive pour la prochaine fois

nginx -s reload applique le nouvel amont sans laisser tomber une seule connexion en vol — les requêtes existantes se terminent sur l'ancien processus pendant que les nouvelles vont vers la nouvelle cible — ce qui fait de la bascule elle-même un événement sans interruption plutôt que simplement rapide.

L'étape qui rend cela sûr : tester avant la bascule

Ce qui fait du bleu-vert plus que deux serveurs, c'est la fenêtre de test qu'il crée. Parce que la nouvelle version est en service sur l'environnement vert mais ne reçoit aucun trafic public, vous pouvez l'exercer pleinement avant qu'un seul client ne la touche — exécuter les sondes, frapper les chemins critiques, confirmer que la nouvelle version démarre et sert réellement correctement contre la vraie base et la vraie configuration de production. Cela attrape la catégorie de défaillance qui n'apparaît que dans le vrai environnement : la valeur de configuration manquante, la migration qui n'a pas tourné, la dépendance qui se comporte autrement en production. Vous la trouvez pendant que l'environnement est inactif, pas après y avoir envoyé des clients.

La complication que personne ne mentionne : la base de données

Deux environnements applicatifs sont simples ; la base qu'ils partagent est là où le soin est requis, car bleu et vert parlent à la même base et vous ne pouvez pas garder deux copies des données vives synchronisées. La règle qui fait fonctionner cela est celle des migrations de schéma sûres : chaque changement de base doit être compatible avec l'ancienne et la nouvelle version applicative à la fois. L'ancien code continue de tourner contre le nouveau schéma pendant la fenêtre où les deux existent, ce qui signifie que les changements de schéma sont additifs — ajouter la colonne, déployer du code qui écrit les deux, basculer, puis retirer plus tard l'ancienne colonne dans un cycle séparé. Une migration que la version en service ne tolère pas brise tout le modèle, car cette version sert encore le trafic jusqu'à la bascule et doit continuer de fonctionner si vous revenez en arrière.

Ce que cela coûte

Le coût honnête est un second environnement, qui, pour l'essentiel du cycle de déploiement, reste inactif. Pour une petite application, c'est modeste — une seconde petite instance, ou la même instance exécutant une seconde copie de l'application sur un autre port si vous ne pouvez pas justifier du matériel séparé. Pesez cela contre ce que cela achète : des déploiements sans fenêtre d'interruption, un retour arrière en secondes plutôt qu'un redéploiement angoissant, et un endroit pour tester pleinement chaque version contre la vraie production avant qu'elle ne serve quiconque. Pour toute entreprise où un déploiement raté en heures ouvrables est coûteux, la doublure inactive se rembourse la première fois qu'une mauvaise version est attrapée dans l'environnement vert, ou renversée dans les dix secondes d'une rebascule — au lieu de l'heure frénétique qu'elle aurait autrement été.

Par où commencer

Mettez un répartiteur devant votre application s'il n'y en a pas déjà un — ce seul changement est le prérequis et vaut la peine en soi. Dressez ensuite le second environnement et exercez la bascule et le retour arrière un après-midi calme, avant d'en dépendre, pour que la séquence soit familière plutôt qu'improvisée. La capacité qui vous laisse déployer un vendredi sans crainte n'est pas une plateforme. C'est une doublure et un interrupteur, et c'est à la portée d'une équipe de deux.