On a tous vécu ce moment. Tu pushes une version, tu lances le déploiement… et là, petit frisson. Le site ralentit. Un 502 qui traîne. Les utilisateurs qui refresh. Et toi qui te dis que oui, tu aurais dû faire ça « proprement ».
Le déploiement blue/green, c’est justement une façon simple d’éviter ce stress. Pas besoin de magie noire, ni de micro services compliqués. Juste une méthode claire, et deux environnements qui se remplacent proprement.
Dans cet article, je te montre comment mettre ça en place, sans downtime, et sans y passer ta semaine.
C’est quoi le blue/green, en vrai
Le principe est bête (dans le bon sens) :
- Blue : ton environnement en production, celui que les utilisateurs consomment maintenant.
- Green : le même environnement, mais prêt à recevoir la nouvelle version.
Tu déploies en green, tu testes, tu valides. Puis tu bascules le trafic de blue vers green. Et si ça part en vrille… tu re bascules. C’est presque un bouton « undo ».
Ce qui change tout, c’est que la bascule est quasi instantanée et ne dépend pas du temps de déploiement de l’application.
Pourquoi ça évite le downtime
Parce que tu ne touches pas à l’environnement qui sert le trafic tant que tu n’as pas fini.
Dans un déploiement classique, tu modifies la prod en direct, donc pendant quelques secondes ou minutes tu as :
- des services qui redémarrent,
- des migrations qui bloquent,
- des caches vides,
- parfois des fichiers statiques en décalage.
En blue/green, tu fais tout ça hors trafic. Et tu ne fais qu’un switch de routage à la fin.
Le vrai prérequis : rendre ton appli « switchable »
Le piège, ce n’est pas l’infra. C’est l’état.
Si ton application dépend d’un stockage local, d’une session sur disque, ou d’une base que tu modifies sans compatibilité, tu vas te compliquer la vie. Donc, avant même d’écrire une ligne de pipeline, vérifie ces points :
- sessions côté serveur stockées dans Redis ou équivalent (pas sur un seul serveur)
- fichiers uploadés dans un stockage partagé (S3, NFS, MinIO…)
- migrations de base de données pensées pour être compatibles entre deux versions (au moins temporairement)
C’est là que la plupart des « ça marche sur le papier » se cassent les dents.
Mise en place simple avec un reverse proxy (Nginx)
Tu peux faire du blue/green juste avec Nginx, deux instances de ton app, et un petit switch.
Exemple d’architecture
- app-blue sur
10.0.0.10:3000 - app-green sur
10.0.0.11:3000 - Nginx en frontal qui envoie le trafic vers l’un des deux
Exemple de config Nginx (idée)
Tu définis un upstream, puis tu changes la cible.
nginx upstream app_backend { server 10.0.0.10:3000; # blue # server 10.0.0.11:3000; # green }
server { listen 80; location / { proxy_pass http://app_backend; } }
Déployer en green, puis au moment de la bascule tu modifies l’upstream (ou tu actives la ligne green), tu reload Nginx :
bash nginx -t && systemctl reload nginx
Reload, pas restart. Donc pas de coupure.
Bon, ce n’est pas le plus « élégant » si tu fais ça à la main tous les jours. Mais ça marche, et ça aide à comprendre le mécanisme.
Variante plus propre : load balancer + health checks
Avec un load balancer (HAProxy, Traefik, ALB AWS, etc.), tu fais mieux :
- tu ajoutes green comme cible
- tu attends que les health checks passent
- tu bascules progressivement ou d’un coup
- tu retires blue
Et tu peux même faire un petit « canary » avant, genre 5 pour cent du trafic en green pour voir si ça fume.
Le point sensible : la base de données (et comment éviter de se piéger)
Blue/green est simple tant que tout est stateless. La base, c’est l’état, donc c’est là que ça se joue.
Le conseil le plus important : fais des migrations compatibles.
Un exemple classique de stratégie safe :
- version A : tu ajoutes une nouvelle colonne nullable, sans casser l’ancienne
- tu déploies la nouvelle appli qui écrit dans les deux (ancienne et nouvelle colonne) ou qui peut lire les deux
- une fois stable, tu fais le nettoyage plus tard (suppression de l’ancienne colonne)
Oui, ça fait « deux temps ». Mais ça évite le scénario où blue et green n’arrivent plus à parler à la même base.
Un mini workflow CI/CD qui ne fait pas peur
Sans entrer dans le roman, un pipeline simple ressemble à ça :
- build + tests
- déploiement en green
- smoke tests sur green (HTTP 200, login, endpoint critique)
- bascule trafic
- monitoring serré pendant 5 à 15 minutes
- si alerte : rollback en re basculant sur blue
Et c’est ça qui rend le truc agréable. Le rollback ne consiste pas à re déployer, juste à re router.
Checklist rapide avant de basculer (celle que tu vas vraiment utiliser)
- green répond aux health checks
- logs OK, pas d’erreurs en boucle
- DB migrations appliquées et compatibles
- cache warm si nécessaire (ou au moins prévu)
- endpoints critiques testés
- plan de rollback clair (et testé une fois, oui, vraiment)
Conclusion : le blue/green, c’est juste de la discipline
Le blue/green n’est pas réservé aux grosses boîtes. C’est une méthode qui met un peu d’ordre dans ton déploiement, et qui te donne surtout un filet de sécurité.
Si tu veux, je peux aussi publier une version plus « pas à pas » sur Le Blog Tech Pro de Samyn-Antoy ABASSE avec un exemple complet Nginx ou Docker Compose, voire une version Kubernetes, mais expliquée calmement. Tu peux garder un œil sur https://monblog-sa-abasse.blogspot.com, j’y poste souvent ce genre de guides pratiques, sans blabla inutile.
Et si tu ne devais retenir qu’une idée : déploie ailleurs, bascule après. Le reste, c’est juste des outils.
Questions fréquemment posées
Qu'est-ce que le déploiement blue/green et comment fonctionne-t-il ?
Le déploiement blue/green est une méthode simple pour déployer une nouvelle version d'une application sans downtime. Il consiste à avoir deux environnements identiques : 'blue' (en production) et 'green' (prêt à recevoir la nouvelle version). On déploie et teste la nouvelle version en green, puis on bascule instantanément le trafic de blue vers green. En cas de problème, on peut revenir rapidement à blue.
Pourquoi le déploiement blue/green évite-t-il les interruptions de service ?
Parce que toute la mise à jour se fait sur l'environnement green, qui ne sert pas encore le trafic utilisateur. Le site en production (blue) reste intact pendant les opérations comme redémarrage des services, migrations ou vidage des caches. La bascule finale est un simple changement de routage quasi instantané, éliminant ainsi les temps d'arrêt.
Quels sont les prérequis essentiels pour rendre une application compatible avec le déploiement blue/green ?
L'application doit être 'switchable', c'est-à-dire qu'elle ne doit pas dépendre d'un stockage local ou d'une session stockée sur un seul serveur. Il faut utiliser des sessions côté serveur centralisées (comme Redis), stocker les fichiers uploadés dans un stockage partagé (S3, NFS...), et concevoir les migrations de base de données pour qu'elles soient compatibles entre deux versions simultanément.
Comment mettre en place un déploiement blue/green simple avec Nginx ?
On peut configurer Nginx avec deux instances de l'application (blue et green) sur des adresses IP différentes. Dans la configuration Nginx, on définit un upstream pointant vers l'une des deux instances. Pour basculer, il suffit de modifier l'upstream pour pointer vers l'autre instance et recharger Nginx avec 'nginx -t && systemctl reload nginx', ce qui ne provoque pas de coupure.
Quelles sont les améliorations possibles du déploiement blue/green avec un load balancer ?
Avec un load balancer comme HAProxy, Traefik ou AWS ALB, on peut ajouter les environnements blue et green comme cibles simultanées. Le load balancer effectue des health checks pour s'assurer que green est prêt avant de basculer progressivement ou totalement le trafic. Cela permet aussi de faire un déploiement canary en envoyant une petite partie du trafic vers green pour tester avant bascule complète.
Comment gérer la base de données lors d'un déploiement blue/green pour éviter les problèmes ?
La base de données étant l'état critique, il faut effectuer des migrations compatibles entre versions. Par exemple, ajouter une colonne nullable sans casser l'existant avant de déployer la nouvelle version qui utilise cette colonne. Cette approche graduelle évite les incompatibilités entre blue et green et permet un rollback facile si besoin.
0 Commentaires