Che cos'è un deployment Blue-green su Kubernetes?

Kubernetes supporta una strategia del ciclo di vita di sviluppo software chiamata deployment blue-green, che prevede l'esecuzione simultanea di entrambe le nuove e vecchie versioni di un'applicazione in produzione. Continua a leggere per scoprire cos'è un deployment blu-verde e perché potresti voler implementare questa tattica per le tue applicazioni Kubernetes. 

Che cos'è un deployment Blue-green?

Un deployment blu-verde è una strategia del ciclo di vita di sviluppo software che prevede l'esecuzione simultanea di entrambe le versioni, nuova e precedente, di un'applicazione in produzione. Gli utenti vengono gradualmente migrati dalla versione precedente (in blu) alla versione più recente (in verde) dell'applicazione dopo il deployment. 

Per una distribuzione rapida degli aggiornamenti software, gli sviluppatori avevano bisogno di un modo per implementare continuamente le funzionalità. Tradizionalmente, i deployment di codice richiedevano downtime, quindi venivano eseguiti in giorni specifici ogni settimana o ogni mese. Questa strategia rallenta gli aggiornamenti del software e non supporta la continuous delivery.

I deployment Blue-green risolvono questo problema eseguendo sia la versione vecchia che quella nuova di un'applicazione in produzione. La versione blu è la vecchia applicazione, mentre la versione verde è la nuova. Gli utenti vengono lentamente spostati alla nuova versione verde dopo che è stata implementata. Dopo che gli utenti sono passati alla nuova versione verde, la versione blu può fungere da failover se il codice deve essere riportato alla versione precedente a causa di bug o errori critici.

Deployment blu-verde e rolling con Kubernetes

In molti ambienti aziendali, la produzione viene eseguita su più server. Invece di eseguire più versioni contemporaneamente, un deployment continuo funziona con una sola versione di un'applicazione e aggiorna ogni singolo server. 

Supponiamo di avere due server dietro un sistema di bilanciamento del carico ed eseguire una singola applicazione di produzione. In un deployment continuo, uno sviluppatore elimina la rotazione di un server, aggiorna l'applicazione e quindi riporta il server in rotazione. Anche il secondo server viene rimosso dalla rotazione e quindi aggiornato. La maggior parte degli ambienti a rotazione ha tre server in modo che un singolo server possa fungere da failover in caso di errori nel nuovo ambiente di versione.

Blue-green e Canary con Kubernetes

I deployment Canary sono simili a quelli blu-verdi, ma inviano utenti specifici alla versione più recente di un'applicazione invece di spostare lentamente tutti gli utenti alla nuova versione. Si tratta di un'ottima strategia per testare una nuova applicazione con utenti interessati al beta test o testare in silenzio nuove funzionalità con nuovi utenti per ottenere feedback.

In genere, i deployment canary vengono utilizzati su un piccolo sottoinsieme di utenti e la versione originale viene comunque eseguita per la maggior parte degli utenti. Poiché solo un piccolo sottoinsieme di utenti viene indirizzato alla nuova versione, l'infrastruttura è meno costosa e non deve essere troppo avanzata per supportare un numero ridotto di utenti.

Vantaggi di un deployment Blue-green

In qualsiasi ambiente di continuous delivery, i deployment blu-verde offrono diversi vantaggi. I deployment Blue-green accelerano la delivery degli aggiornamenti delle funzionalità delle applicazioni. Gli sviluppatori non devono più attendere una finestra per implementare nuovo codice, che può ritardare i deployment per mesi.

Dei tre tipi di deployment, i deployment blu-verde sono più sicuri degli altri. Entrambe le versioni dell'applicazione vengono eseguite contemporaneamente, in modo che gli sviluppatori possano annullare le modifiche senza sforzi. Se necessario, gli utenti non subiranno downtime né perderanno produttività durante i deployment o i rollback.

Svantaggi del deployment Blue-green

Il principale svantaggio dei deployment blue-green è rappresentato dalle spese. Le aziende devono disporre del budget IT per pagare i due ambienti in grado di ospitare sia le versioni blu che quelle verdi di un'applicazione. Le organizzazioni pagano anche le spese generali del personale per la manutenzione e il monitoraggio di entrambi gli ambienti.

Un altro ostacolo per le organizzazioni è la sincronizzazione dei database. Le modifiche ai database non sono così facili da ripristinare, quindi gli aggiornamenti alle tabelle e allo schema dei database devono essere eseguiti con attenzione, soprattutto se gli ambienti verde e blu utilizzano lo stesso database. Entrambi gli ambienti devono essere attentamente testati prima di essere distribuiti nei database di produzione.

Quando utilizzare un deployment Blue-green con Kubernetes

La delivery continua e Kubernetes vanno di pari passo. Gli sviluppatori possono implementare automaticamente le applicazioni utilizzando strumenti di orchestrazione come Kubernetes. Kubernetes può essere utilizzato per orchestrare sia gli ambienti blu che quelli verdi e gli sviluppatori possono semplicemente implementare il codice e consentire a Kubernetes di gestire la promozione del codice da un ambiente di staging alla produzione.

Gli ambienti containerizzati sono perfetti per i deployment blu-verde, perché consentono di distruggere e ricostruire rapidamente i pod delle applicazioni in modo da poter eseguire le versioni blu o verde. Se un'applicazione di container causa errori, gli sviluppatori possono eseguire più facilmente il rollback delle modifiche alla versione blu.