Déploiements blue-green et bascules DNS

Un déploiement blue-green maintient deux environnements de production complets en fonctionnement, l'un en service (« blue »), l'autre inactif mais entièrement déployé et prêt (« green »), et fait passer le trafic de l'un à l'autre en une seule opération rapide plutôt que par une mise à jour progressive. Une façon courante de réaliser cette bascule, surtout entre infrastructures ou fournisseurs distincts, est un changement DNS : mettre à jour l'enregistrement du domaine pour qu'il pointe vers l'adresse de l'environnement green une fois celui-ci vérifié comme sain.

Là où la version simple atteint ses limites

Une bascule par DNS n'est pas instantanée, contrairement à la bascule du groupe cible d'un répartiteur de charge. Chaque résolveur qui a mis en cache l'ancienne réponse (blue) continue de la servir jusqu'à l'expiration du TTL de cet enregistrement. Pendant une durée proportionnelle au TTL, une partie du trafic arrive donc encore sur l'environnement que vous venez de quitter. Avec un TTL d'une heure, cela représente potentiellement une heure de trafic réparti entre les deux environnements avant que la bascule soit complète partout.

• Abaissez le TTL bien avant la bascule prévue, idéalement au moins un cycle complet de l'ancien TTL à l'avance, pour qu'au moment de la bascule chaque résolveur ait déjà remis en cache la valeur avec le nouveau TTL, plus court.
• Gardez l'ancien environnement (blue) pleinement opérationnel et sain pendant au moins la durée du TTL après la bascule, sans le désactiver immédiatement : il reçoit encore du trafic réel durant cette période.
• Vérifiez la bascule en interrogeant directement le DNS plutôt qu'en vous contentant des journaux applicatifs : cela confirme que l'enregistrement lui-même a changé, indépendamment de la part du trafic qui l'a déjà rattrapé.
• Ne remontez le TTL à sa valeur normale qu'une fois certain que la bascule est terminée et stable.

L'alternative progressive : le DNS pondéré

Plutôt que de faire basculer tous les résolveurs d'un coup en espérant que l'environnement green tienne immédiatement la pleine charge de production, plusieurs fournisseurs DNS prennent en charge des politiques de routage pondérées (ou en pourcentage) : 95 % des réponses pointent vers blue, 5 % vers green, et cette répartition évolue progressivement (80/20, 50/50, puis au-delà) à mesure que la confiance dans le nouvel environnement grandit.

On échange une bascule nette et simple contre la possibilité de repérer un problème tant qu'il n'affecte qu'une petite part du trafic, et de revenir à 100 % blue en quelques secondes si green n'est finalement pas prêt, plutôt que de devoir annuler une bascule complète sous pression.

Vérifier les deux approches de la même façon

Quelle que soit la stratégie utilisée, l'étape de vérification est identique : résolvez le domaine à plusieurs reprises, depuis plusieurs points d'observation, et vérifiez que la répartition réellement observée correspond à celle qui a été configurée. Une politique pondérée censée envoyer 10 % du trafic vers green mais qui en envoie en réalité 40 % (à cause d'un poids mal configuré, ou parce que certains résolveurs mettent en cache et ne retirent pas la répartition au sort aussi souvent que prévu) est exactement le type de dérive qui n'apparaît qu'en vérifiant les réponses réellement résolues, plutôt qu'en faisant confiance au tableau de bord du fournisseur DNS pour refléter parfaitement la réalité.