Questa guida spiega come eseguire deployment blu/verde senza tempi di inattività su gruppi di istanze gestite di Compute Engine (MIG) utilizzando Cloud Build e Terraform.
Cloud Build consente di automatizzare una serie di processi per sviluppatori, tra cui la creazione e il deployment di applicazioni in vari runtime Google Cloud come Compute Engine, Google Kubernetes Engine, GKE Enterprise e Cloud Functions.
I gruppi di istanze gestite di Compute Engine consentono di utilizzare le applicazioni su più macchine virtuali (VM) identiche. Puoi rendere i tuoi carichi di lavoro scalabili e ad alta disponibilità sfruttando i servizi MIG automatizzati, tra cui: scalabilità automatica, riparazione automatica, deployment a livello di regione (più zone) e aggiornamento automatico. Utilizzando il modello di deployment continuo blu/verde, imparerai come trasferire gradualmente il traffico degli utenti da un gruppo di istanze gestite (blu) a un altro gruppo di istanze gestite (verde), entrambi in esecuzione in produzione.
Panoramica del design
Il seguente diagramma mostra il modello di deployment blu/verde utilizzato dall'esempio di codice descritto in questo documento:
A livello generale, questo modello include i seguenti componenti:
- Due pool di VM di Compute Engine: blu e verde.
- Tre bilanciatori del carico HTTP(S) esterni:
- Un bilanciatore del carico blu/verde che instrada il traffico dagli utenti finali al pool di istanze VM blu o verde.
- Un bilanciatore del carico blu che instrada il traffico da ingegneri e sviluppatori QA al pool di istanze VM blu.
- Un bilanciatore del carico verde che indirizza il traffico da ingegneri e sviluppatori QA al pool di istanze Green.
- Due insiemi di utenti:
- Utenti finali che hanno accesso al bilanciatore del carico blu/verde, che li rimanda al pool di istanze blu o verde.
- Tecnici e sviluppatori QA che richiedono l'accesso a entrambi i gruppi di pool a scopo di sviluppo e test. Possono accedere sia al bilanciatore del carico blu che al bilanciatore del carico verde, che li instrada rispettivamente al pool di istanze blu e al pool di istanze verde.
I pool di VM blu e verde vengono implementati come gruppi di istanze gestite di Compute Engine e gli indirizzi IP esterni vengono instradati nelle VM nel gruppo di istanze gestite utilizzando bilanciatori del carico HTTP(s) esterni. L'esempio di codice descritto in questo documento utilizza Terraform per configurare questa infrastruttura.
Il seguente diagramma illustra le operazioni degli sviluppatori che vengono eseguite nel deployment:
Nel diagramma in alto, le frecce rosse rappresentano il flusso di bootstrap che si verifica quando configuri l'infrastruttura di deployment per la prima volta, mentre le frecce blu rappresentano il flusso GitOps che si verifica durante ogni deployment.
Per configurare questa infrastruttura, esegui uno script di configurazione che avvia il processo di bootstrap e configura i componenti per il flusso GitOps.
Lo script di configurazione esegue una pipeline di Cloud Build che esegue le seguenti operazioni:
- Crea un repository in Cloud Source Repositories denominato
copy-of-gcp-mig-simple
e copia il codice sorgente dal repository GitHub di esempio al repository in Cloud Source Repositories. - Crea due trigger di Cloud Build denominati
apply
edestroy
.
Il trigger apply
è collegato a un file Terraform denominato main.tfvars
in Cloud Source Repositories. Questo file contiene le variabili Terraform che rappresentano
i bilanciatori del carico blu e verde.
Per configurare il deployment, devi aggiornare le variabili nel file main.tfvars
.
Il trigger apply
esegue una pipeline di Cloud Build che esegue
tf_apply
ed esegue le seguenti operazioni:
- Crea due gruppi di istanze gestite di Compute Engine (uno per il verde e uno per il blu), quattro istanze VM di Compute Engine (due per il gruppo di istanze gestite verde e due per il gruppo di istanze gestite blu), i tre bilanciatori del carico (blu, verde e lo splitter) e tre indirizzi IP pubblici.
- Stampa gli indirizzi IP che puoi utilizzare per visualizzare le applicazioni di cui hai eseguito il deployment nelle istanze blu e verde.
Il trigger di eliminazione viene attivato manualmente per eliminare tutte le risorse create dal trigger di applicazione.
Obiettivi
Utilizzare Cloud Build e Terraform per configurare bilanciatori del carico HTTP(S) esterni con backend di gruppi di istanze VM di Compute Engine.
Eseguire deployment blu/verde sulle istanze VM.
Costi
In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi in base all'utilizzo previsto,
utilizza il Calcolatore prezzi.
Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.
Prima di iniziare
- Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
- Installa Google Cloud CLI.
-
Per initialize gcloud CLI, esegui questo comando:
gcloud init
-
Crea o seleziona un progetto Google Cloud.
-
Crea un progetto Google Cloud:
gcloud projects create PROJECT_ID
Sostituisci
PROJECT_ID
con un nome per il progetto Google Cloud che stai creando. -
Seleziona il progetto Google Cloud che hai creato:
gcloud config set project PROJECT_ID
Sostituisci
PROJECT_ID
con il nome del tuo progetto Google Cloud.
-
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
- Installa Google Cloud CLI.
-
Per initialize gcloud CLI, esegui questo comando:
gcloud init
-
Crea o seleziona un progetto Google Cloud.
-
Crea un progetto Google Cloud:
gcloud projects create PROJECT_ID
Sostituisci
PROJECT_ID
con un nome per il progetto Google Cloud che stai creando. -
Seleziona il progetto Google Cloud che hai creato:
gcloud config set project PROJECT_ID
Sostituisci
PROJECT_ID
con il nome del tuo progetto Google Cloud.
-
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
Provalo
Esegui lo script di configurazione dal repository di esempio di codice Google:
bash <(curl https://raw.githubusercontent.com/GoogleCloudPlatform/cloud-build-samples/main/mig-blue-green/setup.sh)
Quando lo script di configurazione richiede il consenso dell'utente, inserisci yes.
L'esecuzione dello script termina tra pochi secondi.
Nella console Google Cloud, apri la pagina Cronologia build di Cloud Build:
Fai clic sull'ultima build.
Vedrai la pagina Dettagli build, che mostra una pipeline di Cloud Build con tre passaggi di build: il primo passaggio crea un repository in Cloud Source Repositories, il secondo passaggio clona i contenuti del repository di esempio in GitHub in Cloud Source Repositories e il terzo passaggio aggiunge due trigger di build.
Repository Cloud Source aperti:
Nell'elenco dei repository, fai clic su
copy-of-gcp-mig-simple
.Nella scheda Cronologia in fondo alla pagina, vedrai un commit con la descrizione
A copy of https://github.com/GoogleCloudPlatform/cloud-build-samples.git
effettuata da Cloud Build per creare un repository denominatocopy-of-gcp-mig-simple
.Apri la pagina Trigger di Cloud Build:
Per avviare il processo di deployment, aggiorna il file
infra/main.tfvars
:Nella finestra del terminale, crea una cartella denominata
deploy-compute-engine
e naviga in una cartella:mkdir ~/deploy-compute-engine cd ~/deploy-compute-engine
Clona il repository
copy-of-gcp-mig-simple
:gcloud source repos clone copy-of-mig-blue-green
Passa alla directory clonata:
cd ./copy-of-mig-blue-green
Aggiorna
infra/main.tfvars
per sostituire il blu con il verde:sed -i'' -e 's/blue/green/g' infra/main.tfvars
Aggiungi il file aggiornato:
git add .
Esegui il commit del file:
git commit -m "Promote green"
Esegui il push del file:
git push
Le modifiche apportate a
infra/main.tfvars
attivano l'esecuzione del triggerapply
, che avvia il deployment.
Repository Cloud Source aperti:
Nell'elenco dei repository, fai clic su
copy-of-gcp-mig-simple
.Verrà visualizzato il commit con la descrizione
Promote green
nella scheda Cronologia in fondo alla pagina.Per visualizzare l'esecuzione del trigger
apply
, apri la pagina Cronologia build nella console Google Cloud:Apri la pagina Dettagli build facendo clic sulla prima build.
Vedrai la pipeline di trigger
apply
con due passaggi di build. Il primo passaggio di build esegue le applicazioni di Terraform per creare Compute Engine e le risorse di bilanciamento del carico per il deployment. Il secondo passaggio alla creazione mostra l'indirizzo IP dove puoi vedere l'applicazione in esecuzione.Apri l'indirizzo IP corrispondente al gruppo di istanze gestite verde in un browser. Vedrai uno screenshot simile al seguente che mostra il deployment:
Vai alla pagina Gruppo di istanze di Compute Engine per visualizzare i gruppi di istanze blu e verde:
Apri la pagina Istanze VM per visualizzare le quattro istanze VM:
Apri la pagina Indirizzi IP esterni per visualizzare i tre bilanciatori del carico:
Vedrai due trigger di build denominati apply
e destroy
. Il trigger apply
è allegato al file infra/main.tfvars
nel ramo main
. Questo trigger viene eseguito ogni volta che il file viene aggiornato. L'attivatore destroy
è manuale.
Nozioni di base sul codice
Il codice sorgente per questo esempio di codice include:
- Codice sorgente correlato allo script di configurazione.
- Codice sorgente relativo alle pipeline di Cloud Build.
- Codice sorgente relativo ai modelli Terraform.
Script di configurazione
setup.sh
è lo script di configurazione che esegue il processo di bootstrap e crea i componenti per il deployment blu/verde. Lo script esegue le seguenti operazioni:
- Abilita le API Cloud Build, Resource Manager, Compute Engine e Cloud Source Repositories.
- Concede il ruolo IAM
roles/editor
all'account di servizio Cloud Build nel tuo progetto. Questo ruolo è necessario per consentire a Cloud Build di creare e configurare i componenti GitOps necessari per il deployment. - Concede il ruolo IAM
roles/source.admin
all'account di servizio Cloud Build nel tuo progetto. Questo ruolo è necessario affinché l'account di servizio Cloud Build crei Cloud Source Repositories nel progetto e cloni i contenuti del repository GitHub di esempio in Cloud Source Repositories. Genera una pipeline Cloud Build denominata
bootstrap.cloudbuild.yaml
in linea, che:- Crea un nuovo repository in Cloud Source Repositories.
- Copia il codice sorgente dal repository GitHub di esempio al nuovo repository in Cloud Source Repositories.
- Crea i trigger di build Applica ed elimina.
Pipeline Cloud Build
apply.cloudbuild.yaml
e destroy.cloudbuild.yaml
sono i file di configurazione di Cloud Build utilizzati dallo script di configurazione per configurare le risorse per il flusso GitOps. apply.cloudbuild.yaml
contiene due passaggi di build:
tf_apply build
passaggio di build che chiama la funzionetf_install_in_cloud_build_step
, che installa Terraform.tf_apply
che crea le risorse utilizzate nel flusso GitOps. Le funzionitf_install_in_cloud_build_step
etf_apply
sono definite inbash_utils.sh
e il passaggio di build utilizza il comandosource
per richiamarle.- Passaggio di build
describe_deployment
che chiama la funzionedescribe_deployment
che stampa gli indirizzi IP dei bilanciatori del carico.
destroy.cloudbuild.yaml
chiama tf_destroy
, che elimina tutte le risorse
create da tf_apply
.
Le funzioni tf_install_in_cloud_build_step
, tf_apply
, describe_deployment
e tf_destroy
sono definite nel file bash_utils.sh
.
I file di configurazione di compilazione utilizzano il comando source
per chiamare le funzioni.
Il seguente codice mostra la funzione tf_install_in_cloud_build_step
definita in bash_utils.sh
. I file di configurazione della build chiamano questa funzione
per installare Terraform all'istante. Crea un bucket Cloud Storage
per registrare lo stato di Terraform.
Il seguente snippet di codice mostra la funzione tf_apply
definita in bash_utils.sh
. Innanzitutto chiama terraform init
, che carica tutti i moduli e
le librerie personalizzate, poi esegue terraform apply
per caricare le variabili dal
file main.tfvars
.
Il seguente snippet di codice mostra la funzione describe_deployment
definita in bash_utils.sh
. Utilizza gcloud compute addresses describe
per recuperare gli indirizzi IP dei bilanciatori del carico utilizzando il nome e li stampa.
Il seguente snippet di codice mostra la funzione tf_destroy
definita in bash_utils.sh
. Chiama terraform init
, che carica tutti i moduli e le librerie
personalizzate, quindi esegue terraform destroy
che annulla il caricamento delle variabili Terraform.
Modelli Terraform
Nella cartella copy-of-gcp-mig-simple/infra/
troverai tutti i file e le variabili di configurazione di Terraform.
main.tf
: questo è il file di configurazione di Terraformmain.tfvars
: questo file definisce le variabili Terraform.mig/
esplitter/
: queste cartelle contengono i moduli che definiscono i bilanciatori del carico. La cartellamig/
contiene il file di configurazione Terraform che definisce il gruppo di istanze gestite per i bilanciatori del carico blu e verde. I gruppi di istanze gestite blu e verde sono identici, pertanto vengono definiti una sola volta e sono sufficienti per gli oggetti blu e verde. Il file di configurazione Terraform per il bilanciatore del carico dello splitter si trova nella cartellasplitter/
.
Il seguente snippet di codice mostra i contenuti di infra/main.tfvars
. Contiene tre variabili: due che determinano quale versione dell'applicazione eseguire il deployment nei pool blu e verde e una variabile per il colore attivo: blu o verde. Le modifiche a questo file attivano il deployment.
Di seguito è riportato uno snippet di codice di infra/main.tf
. In questo snippet:
- Viene definita una variabile per il progetto Google Cloud.
- Google è impostato come provider Terraform.
- Viene definita una variabile per lo spazio dei nomi. Tutti gli oggetti creati da Terraform hanno come prefisso questa variabile, in modo che sia possibile eseguire il deployment di più versioni dell'applicazione nello stesso progetto e che i nomi degli oggetti non siano in conflitto tra loro.
- Le variabili
MIG_VER_BLUE
,MIG_VER_BLUE
eMIG_ACTIVE_COLOR
sono le associazioni per le variabili nel fileinfra/main.tfvars
.
Il seguente snippet di codice di infra/main.tf
mostra l'istanza del modulo splitter. Questo modulo prende il colore attivo in modo che il bilanciatore del carico dello splitter sappia quale gruppo di istanze gestite per eseguire il deployment dell'applicazione.
Il seguente snippet di codice di infra/main.tf
definisce due moduli identici per i gruppi di istanze gestite blu e verde. Prende il colore, la rete e la subnet
definiti nel modulo Splitter.
Il file splitter/main.tf
definisce gli oggetti creati per il gruppo di istanze gestite di splitter. Di seguito è riportato uno snippet di codice di splitter/main.tf
che contiene la logica per passare dal gruppo di istanze gestite (MIG) verde a quello blu. È supportato dal servizio google_compute_region_backend_service
, che può instradare il traffico a due regioni di backend: var.instance_group_blue
o var.instance_group_green
.
capacity_scaler
definisce la quantità di traffico da instradare.
Il codice seguente instrada il 100% del traffico al colore specificato, ma puoi aggiornarlo per il deployment canary in modo da instradare il traffico a un sottoinsieme di utenti.
Il file mig/main.tf
definisce gli oggetti relativi ai MIG blu e verde. Il seguente snippet di codice di questo file definisce il modello di istanza di Compute Engine utilizzato per creare i pool di VM. Tieni presente che questo modello di istanza ha la proprietà del ciclo di vita di Terraform impostata su create_before_destroy
.
Questo perché, quando aggiorni la versione del pool, non puoi utilizzare il modello per creare la nuova versione dei pool quando è ancora utilizzato dalla versione precedente del pool. Tuttavia, se la versione precedente del pool viene eliminata prima della creazione del nuovo modello, ci sarà un periodo di tempo in cui i pool non saranno disponibili. Per evitare questo scenario, abbiamo impostato il ciclo di vita di Terraform su create_before_destroy
, in modo che venga creata la versione più recente di un pool di VM prima di eliminare la versione precedente.
Esegui la pulizia
Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.
Elimina singole risorse
Elimina le risorse Compute Engine create dal trigger di applicazione:
Apri la pagina Trigger di Cloud Build:
Nella tabella Trigger, individua la riga corrispondente al trigger destroy e fai clic su Esegui. Quando il trigger completa l'esecuzione, le risorse create dal trigger apply vengono eliminate.
Elimina le risorse create durante il bootstrap eseguendo il seguente comando nella finestra del terminale:
bash <(curl https://raw.githubusercontent.com/GoogleCloudPlatform/cloud-build-samples/main/mig-blue-green/teardown.sh)
Elimina il progetto
Elimina un progetto Google Cloud:
gcloud projects delete PROJECT_ID
Passaggi successivi
- Scopri di più sui trigger di build.
- Scopri come visualizzare la provenienza delle build.