Accedi / Registrati Account

DevOps

Che cos'è il deployment blue green?

Il deployment blue-green è un modello di rilascio delle applicazioni che prevede il trasferimento graduale del traffico utente da una versione precedente di un'app o microservizio in produzione a una nuova release quasi identica, anch'essa in produzione. 

La versione precedente viene chiamata ambiente blue, mentre la nuova versione prende il nome di ambiente green. Dopo che il traffico di produzione è stato completamente trasferito dall'ambiente blue a quello green, l'ambiente blue può essere mantenuto per un eventuale rollback oppure ritirato dalla produzione e quindi aggiornato, diventando un modello da utilizzare come punto di partenza per l'aggiornamento successivo.

Questo modello di deployment continuo comporta tuttavia alcuni svantaggi. I vari ambienti presentano esigenze diverse in tempi di attività oppure non dispongono tutti delle risorse necessarie per eseguire correttamente i processi di integrazione e distribuzione continue (CI/CD) in modalità blue green. All'interno del processo di trasformazione digitale che le aziende stanno affrontando, anche le app tuttavia si evolvono per supportare tale distribuzione continua.

Funzionamento di un deployment blue green

Deployment blue green

Facciamo un esempio. Hai sviluppato una semplice app cloud native, costituita da un gioco mobile in cui gli utenti accumulano punti toccando palloncini colorati che volano sullo schermo. Il back end del gioco è supportato da vari microservizi basati su container, che gestiscono gli obiettivi del gioco, così come il punteggio, le dinamiche e le comunicazioni, oltre all'identificazione del giocatore.

Dopo il rilascio iniziale, centinaia di utenti iniziano a utilizzare il gioco, registrando migliaia di transazioni al minuto. Poiché il tuo team DevOps ti invita a rilasciare le nuove versioni al più presto e di frequente, stai per rilasciare un aggiornamento secondario per il microservizio che gestisce le dinamiche, con lo scopo di incrementare le dimensioni e la velocità dei palloni rossi.

Anziché attendere la mezzanotte per eseguire il push dell'aggiornamento all'ambiente di produzione (quando il numero degli utenti attivi è al minimo), utilizzi un modello di deployment blue green per aggiornare l'app durante l'orario di picco, e lo fai senza causare alcuna discontinuità al servizio. 

Questo è possibile perché hai copiato in un container identico ma separato (green) il microservizio che gestisce le dinamiche dall'ambiente di produzione (blue). Dopo aver incrementato le dimensioni e la velocità dei palloni rossi nell'ambiente verde, hai sottoposto l'aggiornamento a un controllo qualità e a una fase di staging (probabilmente automatizzati tramite un progetto stress test open source quale Jenkins) prima di effettuarne il push all'ambiente di produzione, parallelo all'ambiente blue attivo. 

Il team operativo può utilizzare un servizio di bilanciamento del carico per reindirizzare la transazione successiva di ogni singolo utente dall'ambiente blue all'ambiente green e, una volta filtrato tutto il traffico di produzione attraverso l'ambiente green, hai disattivato l'ambiente blue. L'ambiente blue può essere mantenuto come opzione per il ripristino di emergenza o essere trasformato in un container per l'aggiornamento successivo.

Deployment blue green e Kubernetes

Kubernetes offre la soluzione ideale, perché include tutti gli elementi associati al processo di deployment blue-green, inclusi app cloud native, microservizi, container, integrazione continua, distribuzione continua, deployment continuo e DevOps. Essendo una piattaforma open source che automatizza le operazioni dei container Linux®, Kubernetes consente di orchestrare i container che ospitano i microservizi delle app cloud native, permettendo inoltre agli sviluppatori di riutilizzare gli svariati modelli architetturali da cui è supportato, anziché creare architetture applicative completamente nuove.

Uno di questi è noto come modello di deployment dichiarativo. Poiché i microservizi sono piccoli per natura, il loro numero può aumentare molto rapidamente. Il modello di deployment dichiarativo riduce il lavoro manuale necessario per implementare i nuovi pod, ovvero le unità più piccole e semplici dell'architettura Kubernetes.

Perché scegliere Red Hat

Red Hat® OpenShift, la piattaforma Kubernetes enterprise leader di mercato, è stata potenziata introducendo le funzionalità CI/CD nei suoi componenti di base. I prompt e gli argomenti della riga di comando sono già stati documentati nei minimi dettagli per  consentire il rollout dei deployment blue-green nel tuo ambiente Red Hat OpenShift.

Inoltre, se la tua piattaforma Kubernetes è open source, puoi mantenere il controllo dell'intera piattaforma e di tutti i componenti che dipendono da quest'ultima, permettendo ai tuoi servizi e applicazioni di continuare a funzionare ovunque si trovino e a prescindere dagli ambienti che li supportano.

Sfrutta appieno le nostre tecnologie open source e inizia subito ad analizzare, modificare e migliorare il codice sorgente su cui si basano. Ai nostri prodotti si affidano oltre il 90% delle aziende della classifica Fortune 500*, di qualsiasi settore: con un'infrastruttura basata su prodotti e tecnologie Red Hat realizzerai i tuoi obiettivi.

Prodotti che semplificano il deployment continuo

Red Hat Enterprise Linux logo

Una base solida per nuove applicazioni, macchine virtuali e cloud ibridi.

Red Hat OpenShift Logo

Piattaforma di container Kubernetes espressamente concepita per gli ambienti enterprise.

  • Dati sui clienti Red Hat e classifica Fortune 500, giugno 2018