Strategia di rilascio Canary contro Blue / Green


125

La mia comprensione di una versione canary è che è una versione parziale di un sottoinsieme di nodi di produzione con sessioni permanenti attivate. In questo modo puoi controllare e ridurre al minimo il numero di utenti / clienti che subiscono l'impatto se finisci per rilasciare un bug dannoso.

La mia comprensione di una versione blu / verde è che hai 2 ambienti di produzione con mirroring ("blu" e "verde"), e sposti le modifiche a tutti i nodi del blu o del verde contemporaneamente, quindi usi la magia di rete per controllare a quale ambiente vengono indirizzati gli utenti tramite DNS.

Quindi, prima di iniziare, se qualcosa che ho detto finora non è corretto, per favore inizia a correggermi!

Supponendo che io sia più o meno sulla buona strada, allora un paio di domande sulle due strategie:

  • Esistono scenari in cui il canarino è preferito al blu / verde e viceversa?
  • Esistono scenari in cui un modello di distribuzione può implementare entrambe le strategie contemporaneamente?

5
La tua comprensione è valida, ma non definirei una strategia blu-verde come necessaria per la distribuzione a tutti i nodi contemporaneamente. Puoi distribuirli con la calma che desideri: l'unica pressione sono le tue scadenze. Inoltre, puoi utilizzare il blu-verde per rilasciare le modifiche solo a un sottoinsieme dei tuoi nodi (ad esempio modificando solo uno dei tanti pool di endpoint API).
Patrick M

1
Molto bella la sintesi di questi concetti che vedo ovunque senza prima una definizione chiara!
kheraud

Risposte:


94

Il rilascio blu-verde è più semplice e veloce.

È possibile fare un rilascio blu-verde se aver testato la nuova versione in un ambiente di test e sono molto certi che la nuova versione funzionerà correttamente in produzione. Usando sempre gli interruttori di funzionalità è un buon modo per aumentare la tua fiducia in una nuova versione, poiché la nuova versione funziona esattamente come la vecchia finché qualcuno non attiva un toggle di funzionalità. Suddividere la tua applicazione in piccoli servizi rilasciabili in modo indipendente è un altro, poiché c'è meno da testare e meno da rompere.

È necessario eseguire un rilascio canarino se non si è completamente certi che la nuova versione funzionerà correttamente in produzione. Anche se sei un tester approfondito, Internet è un luogo ampio e complesso e presenta sempre sfide inaspettate. Anche se utilizzi gli interruttori delle funzionalità, uno potrebbe essere implementato in modo errato.

L'automazione della distribuzione richiede impegno, quindi la maggior parte delle organizzazioni pianificherà di utilizzare una strategia o l'altra ogni volta.

Quindi esegui la distribuzione blu-verde se sei impegnato in pratiche che ti consentono di essere sicuro di farlo. Altrimenti, manda fuori il canarino.

L'essenza del blu-verde si sta distribuendo tutto in una volta e l'essenza della distribuzione canary si sta distribuendo in modo incrementale, quindi dato un singolo pool di utenti non riesco a pensare a un processo che descriverei come fare entrambi allo stesso tempo. Se avessi più pool indipendenti di utenti, ad esempio utilizzando diversi data center regionali, potresti fare il blu-verde all'interno di ciascun data center e canary tra i data center. Sebbene se non avessi bisogno della distribuzione canary all'interno di un data center, probabilmente non ne avresti bisogno in tutti i data center.


Qualche parola sul significato dei colori: - il vecchio ambiente potrebbe essere il blu, il nuovo il verde. - Nella prossima versione, il vecchio sarà il verde. Wiki:> Molte lingue non fanno distinzione tra ciò che in inglese è descritto come "blu" e "verde" e utilizza invece un termine di copertura che copre entrambi - "grue"
kinjelom

Il canarino non è sempre più veloce del blu / verde. Tutto dipende dai flussi di lavoro CI e CD!
Ligemer

81

Ho scritto un saggio dettagliato su questo argomento qui: http://blog.itaysk.com/2017/11/20/deployment-strategies-defined

A mio parere, la differenza è se la nuova versione "verde" è esposta o meno agli utenti reali. Se lo è, allora lo chiamerei Canary. Un modo comune per implementare Canary è il normale blu / verde con l'aggiunta del routing intelligente di utenti specifici alla nuova versione. Leggi il post per un confronto dettagliato

Blu verde: inserisci qui la descrizione dell'immagine

Canarino: inserisci qui la descrizione dell'immagine


4
Le tue illustrazioni sono fantastiche, potrei considerare di incorporarle nella tua risposta qui, ma mantenere il link per un'immersione più profonda con le spiegazioni.
quickshiftin

Grazie. Li hanno aggiunti
itaysk

4
Ottima spiegazione. Ma sarebbe meglio mostrare la percentuale di carico dell'utente sull'illustrazione canarino.
nikli

Qual è la differenza tra "durante" e "dopo" nel diagramma di rilascio di Canary? Mi aspettavo che "dopo" assomigliasse a quello della versione blu / verde
Kes115

entrambi i metodi hanno lo scopo di ridurre il rischio valutando la nuova versione. durante significa che la nuova versione viene distribuita ma non è stata ancora presa una decisione su come procedere. after significa dopo che è stata presa una decisione positiva di procedere.
itaysk

6

Sebbene entrambi questi termini sembrino abbastanza vicini l'uno all'altro, presentano sottili differenze. Uno mette fiducia nel rilascio della tua funzionalità e l'altro nel modo in cui rilasci.

Canarino

  1. La versione canary è una tecnica per ridurre il rischio di introdurre una nuova versione del software in produzione implementando lentamente la modifica a un piccolo sottoinsieme di utenti prima di distribuirla all'intera infrastruttura.

  2. Sta per avere un'idea delle prestazioni della nuova versione (integrazione con altre app, CPU, memoria, utilizzo del disco, ecc.).

Blu verde:

  1. Riguarda più il rilascio prevedibile con distribuzione senza tempi di inattività.
  2. Facile rollback in caso di guasto.
  3. Processo di distribuzione completamente automatizzato

4

Ecco alcune definizioni in linea:

  • Distribuzione blu-verde : quando si distribuisce una nuova versione di un'applicazione, viene creato un secondo ambiente. Una volta che il nuovo ambiente è stato testato, prende il posto della vecchia versione. Il vecchio ambiente può quindi essere disattivato.

     

  • Test A / B : due versioni di un'applicazione sono in esecuzione contemporaneamente. Una parte delle richieste va a ciascuno. Gli sviluppatori possono quindi confrontare le versioni.  
  • Versione Canary : viene avviata una nuova versione di un microservizio insieme alle vecchie versioni. Quella nuova versione può quindi accettare una parte delle richieste e il team può testare come questa nuova versione interagisce con il sistema generale.

3

Un buon inizio di definizioni. Penso che aiuti anche a prendere una decisione per la tua strategia se dividi la definizione di "rilascio" in "distribuzione" e "rilascio (funzionalità)".

Distribuisci (binari)

L'azione della distribuzione binaria del prodotto in un sistema (di produzione).

Release (funzionalità)

L'azione di gestione della disponibilità di funzionalità per (gruppi di) utenti.

Perché? In genere hai (più) due preoccupazioni quando "rilasci": 1) Bug / compatibilità con le versioni precedenti / ecc. 2) Verifica della validità / usabilità delle nuove funzionalità

Quindi chiedetevi, prima di scegliere una strategia in modalità Canarino o Blu / verde o qualsiasi altra modalità grigia / mista: Quali preoccupazioni abbiamo quando rilasciamo / distribuiamo la nuova versione? E solo allora se conosci le tue preoccupazioni, scegli la tua strategia.

Inoltre, è possibile eseguire strategie di distribuzione / rilascio più complesse. Ad esempio, in alcuni cloud / infra è possibile avere più server di produzione e inoltrare il carico in proporzioni diverse a diversi server e versioni del prodotto e monitorare la solidità prima di ridimensionare un rilascio / distribuzione a tutti gli utenti.

Segnalazione di funzioni

L'azione di "configurazione" (fredda o anche calda) quale funzionalità è (non) disponibile per quale (gruppo) di utenti

Se fai anche qualcosa come il "contrassegno delle funzionalità" puoi prima distribuire, misurare la validità del tuo rilascio in base alla compatibilità con le versioni precedenti / prospettiva dei bug e rilasciare gradualmente nuove funzionalità a diversi utenti, o viceversa (ridimensionare o addirittura ripristinare la funzionalità e / o i file binari ). Il contrassegno delle funzionalità consente di suddividere la disponibilità della funzionalità dalla distribuzione dei file binari e offre un processo decisionale molto più dettagliato rispetto al solo "deploy / rollback"

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.