Blue-green deployment e cutover DNS

Un blue-green deployment mantiene attivi due ambienti di produzione completi, uno live («blue») e uno inattivo ma già pronto e distribuito («green»), e sposta il traffico dall'uno all'altro con un unico passaggio rapido invece di un aggiornamento graduale. Un modo comune per realizzare questo passaggio, soprattutto tra infrastrutture o provider separati, è una modifica DNS: si aggiorna il record del dominio perché punti all'indirizzo dell'ambiente green una volta verificato che è sano.

Dove la versione semplice si rompe

Un cutover basato su DNS non è istantaneo come lo è di solito cambiare il target group di un load balancer. Ogni resolver che ha messo in cache la vecchia risposta (blue) continua a servirla finché il TTL di quel record non scade: per una finestra di tempo proporzionale al TTL, quindi, una parte del traffico arriva ancora sull'ambiente da cui volevi allontanarti. Con un TTL di un'ora, può significare fino a un'ora di traffico diviso tra i due ambienti prima che il cutover sia completo ovunque.

• Abbassa il TTL con largo anticipo rispetto al cutover pianificato, idealmente con almeno un intero ciclo del vecchio TTL di anticipo, così al momento del cutover ogni resolver ha già rimesso in cache il valore con il nuovo TTL più breve.
• Tieni l'ambiente vecchio (blue) pienamente attivo e sano per almeno l'intera finestra del TTL dopo il cutover, senza dismetterlo subito: in quella finestra riceve ancora traffico reale.
• Verifica il cutover interrogando direttamente il DNS e non limitandoti ai log applicativi: così confermi che il record stesso è cambiato, a prescindere da quanto traffico si sia già allineato.
• Riporta il TTL al valore normale solo quando sei sicuro che il cutover sia completo e stabile.

L'alternativa graduale: il DNS ponderato

Invece di far passare tutti i resolver in un colpo solo sperando che l'ambiente green regga subito il pieno carico di produzione, diversi provider DNS supportano policy di routing ponderate (o percentuali): il 95% delle risposte punta a blue, il 5% a green, e la ripartizione si sposta gradualmente (80/20, 50/50 e oltre) man mano che cresce la fiducia nel nuovo ambiente.

Si cede un passaggio netto e semplice in cambio della possibilità di individuare un problema quando coinvolge solo una piccola fetta di traffico, e di tornare al 100% su blue in pochi secondi se green non si rivela pronto, invece di dover annullare un cutover completo sotto pressione.

Verificare entrambi gli approcci allo stesso modo

Qualunque strategia si usi, la verifica è identica: risolvi il dominio più volte, da più di un punto di osservazione, e conferma che la ripartizione effettiva corrisponda a quella configurata. Una policy ponderata pensata per mandare il 10% del traffico su green ma che in realtà ne manda il 40%, per un peso configurato male o perché alcuni resolver mettono in cache e non rieseguono la ripartizione con la frequenza attesa, è esattamente il tipo di scostamento che emerge solo controllando le risposte realmente risolte, invece di fidarsi che la dashboard del provider DNS rifletta alla perfezione la realtà.