Questo tutorial mostra come inizializzare una nuova applicazione, sviluppare una funzionalità per l'applicazione ed eseguire il deployment dell'applicazione in produzione utilizzando le moderne tecniche di integrazione continua/distribuzione continua (CI/CD) con Google Kubernetes Engine (GKE).
Il presente documento fa parte di una serie:
- CI/CD moderno con GKE: un framework di distribuzione del software
- CI/CD moderno con GKE: creazione di un sistema CI/CD (architettura di riferimento)
- CI/CD moderno con GKE: applica il flusso di lavoro degli sviluppatori (questo documento)
In questo tutorial utilizzerai strumenti come
Skaffold,
kustomize
,
Artifact Registry,
Config Sync,
Cloud Build e
Cloud Deploy per sviluppare, creare ed eseguire il deployment della tua applicazione.
Questo documento è destinato agli Enterprise Architect e agli sviluppatori di applicazioni, nonché ai team di sicurezza IT, DevOps e SRE (Site Reliability Engineering). Una certa esperienza con strumenti e processi di deployment automatizzato è utile per comprendere i concetti contenuti in questo documento.
Architettura
In questo tutorial, eseguirai l'onboarding di una nuova applicazione. Successivamente, svilupperai una nuova funzionalità ed eseguirai il deployment dell'applicazione in ambienti di sviluppo, gestione temporanea e produzione. L'architettura di riferimento contiene l'infrastruttura e gli strumenti necessari per integrare e rilasciare una nuova applicazione con il flusso di lavoro illustrato nel diagramma seguente:
A partire dal repository di codice per la CI, il flusso di lavoro include i seguenti passaggi:
Puoi condividere il codice sorgente dell'applicazione tramite i repository.
Quando esegui il commit e il push del codice nel repository dell'applicazione, attiva automaticamente una pipeline CI in Cloud Build. Il processo di CI crea ed esegue il push di un'immagine container ad Artifact Registry.
Il processo di CI crea anche una release CD per l'applicazione in Cloud Deploy.
La release CD genera manifest Kubernetes con rendering completo per gli sviluppatori utilizzando
skaffold
e ne esegue il deployment nel cluster GKE di sviluppo.La release CD viene quindi promossa da sviluppo a target temporaneo, che genera manifest di gestione temporanea con rendering completo e ne esegue il deployment nel cluster GKE di gestione temporanea.
Quindi, la release CD passa dalla gestione temporanea alla produzione, che genera manifest di produzione con rendering completo e ne esegue il deployment nei cluster GKE di produzione.
Per ulteriori informazioni sugli strumenti e sull'infrastruttura utilizzati in questo flusso di lavoro, consulta CI/CD moderno con GKE: creazione di un sistema CI/CD.
Obiettivi
Onboarding di una nuova applicazione.
Eseguire il deployment dell'applicazione nell'ambiente di sviluppo.
Sviluppa una nuova funzionalità ed eseguine il deployment nell'ambiente di sviluppo.
Promuovi la nuova funzionalità per la gestione temporanea e poi rilasciala in produzione.
Testa la resilienza dell'applicazione.
Costi
In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
- Google Kubernetes Engine
- Versione Google Kubernetes Engine (GKE) Enterprise per Config SyncYES
- Artifact Registry
- Cloud Build
- Cloud Deploy
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
- Per questo tutorial, esegui il deployment dell'architettura di riferimento di questa serie.
prepara l'ambiente
Se continui direttamente da Modern CI/CD with GKE: Build a CI/CD system, vai alla sezione successiva. Tuttavia, se hai una nuova sessione o la sessione è scaduta, apri Cloud Shell e imposta il progetto in cui hai installato l'infrastruttura dell'architettura di riferimento:
gcloud config set core/project PROJECT_ID
Sostituisci
PROJECT_ID
con l'ID del tuo progetto Google Cloud.
Onboarding di una nuova applicazione
L'architettura di riferimento contiene una fabbrica di applicazioni. Questa fabbrica è una raccolta di un repository Git denominato application-factory-repo
e dei seguenti trigger di Cloud Build:
create-app
tf-plan
tf-apply
create-team
Utilizzi la fabbrica delle applicazioni per integrare una nuova applicazione dai repository di base. L'onboarding delle applicazioni prevede i seguenti passaggi:
Crea la definizione dell'applicazione: puoi creare la definizione dell'applicazione in un file Terraform e archiviarla in
application-factory-repo
, che funge da catalogo di applicazioni.Crea l'infrastruttura dell'applicazione: esegui Terraform sul file di definizione dell'applicazione per creare l'infrastruttura dell'applicazione. L'infrastruttura delle applicazioni è composta da:
Una zona di destinazione per la nuova applicazione include la definizione dello spazio dei nomi, dell'account di servizio e dei criteri di base nel repository
acm-gke-infrastructure-repo
. La zona di destinazione viene creata solo in un cluster GKE di sviluppo durante l'onboarding di una nuova applicazione. Questo viene fatto per sbloccare gli sviluppatori in modo che possano utilizzare l'ambiente di sviluppo e iniziare a eseguire l'iterazione. La zona di destinazione nei cluster di gestione temporanea e produzione viene creata con l'approccio GitOps. Questo approccio viene mostrato più avanti in questo documento, quando è tutto pronto per promuovere la release nei cluster.Il repository dell'infrastruttura del repository iniziale dell'infrastruttura che ospita il codice per creare la pipeline CI in Cloud Build, la pipeline CD in Cloud Deploy e il repository Artifact Registry per l'archiviazione degli artefatti.
Un trigger di Cloud Build dell'infrastruttura che prende il codice nel repository dell'infrastruttura e crea le risorse in base alla loro definizione.
Un repository di applicazioni del repository applicazioni iniziali che ospita il codice sorgente dell'applicazione.
Creazione di risorse CI/CD dell'applicazione: utilizzerai l'infrastruttura dell'applicazione per creare risorse CI/CD per l'applicazione.
Crea la definizione dell'applicazione:
Esegui il trigger create-app
per generare un file di definizione dell'applicazione in application-factory-repo
. Il file di definizione contiene la definizione dichiarativa delle risorse necessarie per creare un'applicazione.
Nella console Google Cloud, vai alla pagina Cloud Build:
Fai clic su
create-app
attivatore.Fai clic su MOSTRA ANTEPRIMA URL per visualizzare l'URL necessario per richiamare il webhook.
In Cloud Shell, richiama il trigger effettuando una richiesta curl sull'URL ottenuto dal passaggio precedente e trasmettendogli i parametri sotto forma di payload.
curl "WEBHOOK_URL" -d '{"message": {"app": "sample","runtime": "python","trigger_type": "webhook","github_team": ""}}'
Nell'esempio di codice precedente:
Sostituisci
WEBHOOK_URL
con l'URL ottenuto dall'attivatore."app": "sample"
specifica il nome dell'applicazione."runtime": "python"
indica al produttore dell'applicazione di utilizzare il modello Python per creare repository di applicazioni."trigger_type": "webhook"
specifica il tipo di pipeline CI/CD per l'applicazione."github_team": ""
è un team in GitHub che verrà associato ai repository creati per l'applicazione. Poiché non hai ancora creato un team GitHub, passalo come stringa vuota.
Controlla la pipeline per il trigger
create-app
:Vai alla pagina della cronologia di Cloud Build.
È disponibile una nuova pipeline per il trigger
create-app
. Al termine, la definizione dell'applicazione viene creata inapplication-factory-repo
.Esamina il file di definizione dell'applicazione:
In un browser web, vai a GitHub e accedi al tuo account.
Fai clic sull'icona dell'immagine e poi su
Your organizations
. Scegli la tua organizzazione.Fai clic sul repository
application-factory-repo
, vai alla cartellaapps/python
e apri il nuovo file denominatosample.tf
creato dal triggercreate-app
. Ispeziona il file, che contiene codice Terraform per creare una nuova applicazione.
Crea l'infrastruttura dell'applicazione:
Ora che hai creato la definizione dell'applicazione, esegui il trigger tf-apply
per creare l'infrastruttura dell'applicazione.
Nella console Google Cloud:
Vai alla pagina di Cloud Build .
Fai clic sull'attivatore
tf-apply
.Fai clic su "MOSTRA ANTEPRIMA URL" per visualizzare l'URL necessario per richiamare il webhook.
Richiama l'attivatore:
curl "WEBHOOK_URL" -d '{}'
Nell'esempio di codice precedente:
- Sostituisci
WEBHOOK_URL
con l'URL ottenuto dall'attivatore.
- Sostituisci
Controlla la pipeline per il trigger
tf-apply
:Vai alla pagina della cronologia di Cloud Build.
È disponibile una nuova pipeline per il trigger
tf-apply
. Attendi che venga completata.
Questo trigger crea l'infrastruttura dell'applicazione.
Esamina l'infrastruttura dell'applicazione:
Esamina i vari componenti dell'infrastruttura delle applicazioni.
Zona di destinazione
Vai a Cloud Shell e imposta il progetto.
gcloud config set core/project PROJECT_ID
Sostituisci
PROJECT_ID
con l'ID del tuo progetto Google Cloud.Recupera le credenziali per il cluster di sviluppo GKE.
gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
Controlla lo spazio dei nomi dell'applicazione. Lo spazio dei nomi prende il nome dall'applicazione, esempio.
kubectl get namespaces sample
L'output è simile al seguente:
NAME STATUS AGE sample Active 15m
Controlla l'account di servizio nello spazio dei nomi.
kubectl get serviceaccounts -n sample
Esiste un account di servizio oltre a quello predefinito. L'output è simile al seguente:
NAME SECRETS AGE default 0 15m sample-ksa 0 15m
Repository dell'infrastruttura
In un browser web, vai a GitHub e accedi al tuo account. Fai clic sull'icona dell'immagine. Poi fai clic su Your organizations
. Scegli la tua organizzazione e fai clic sul repository sample-infra
.
Questo repository ha quattro rami: cicd-trigger
, dev
, staging
e prod
. Contiene inoltre quattro cartelle cicd-trigger, dev, staging e prod. Il ramo predefinito è cicd-trigger
e puoi eseguire il push del codice, mentre altri rami hanno regole di protezione, quindi non puoi eseguire il push del codice direttamente in quei rami. Per eseguire il push del codice a questi rami, devi creare una richiesta di pull. La cartella cicd-trigger
contiene il codice per creare risorse CI/CD per l'applicazione, mentre le cartelle dev
, staging
e prod
contengono il codice per creare l'infrastruttura per i diversi ambienti dell'applicazione.
Trigger dell'infrastruttura
Nella console Google Cloud:
Vai alla pagina di Cloud Build
Esiste un nuovo trigger denominato
deploy-infra-sample
.Questo trigger è connesso al repository
sample-infra
in modo che, quando viene eseguito un push del codice in questo repository, il trigger venga richiamato e identifichi il ramo in cui è avvenuto il push, che vada alla cartella corrispondente su quel ramo ed esegua Terraform lì. Ad esempio, se il codice viene inviato al ramocicd-trigger
, il trigger esegue Terraform sulla cartella cicd-trigger del ramo cicd-trigger. Analogamente, quando viene eseguito un push al ramodev
, il trigger esegue Terraform sulla cartella dev del ramo dev e così via.
Repository di applicazioni
- Vai a GitHub e recupera i repository nella tua organizzazione. Esiste un nuovo repository con il nome
sample
. Questo repository ospita il codice sorgente e i passaggi per creare i container inDockerfile
,kustomize
configurazioni che descrivono le configurazioni necessarie dell'applicazione eskaffold.yaml
che definisce i passaggi di deployment che Cloud Deploy deve utilizzare per CD.
Creazione di risorse CI/CD dell'applicazione
Ora che hai creato lo schema dell'applicazione, esegui il trigger deploy-infra-sample
per creare le relative risorse CI/CD. Puoi richiamare il trigger manualmente utilizzando l'URL webhook o eseguendo un commit al repository Git sample-infra
.
Per richiamare il trigger di Cloud Build, aggiungi una nuova riga in un file nel repository. Quindi, esegui il push delle modifiche:
Se non hai mai utilizzato Git in Cloud Shell, configura Git con il tuo nome e indirizzo email. Git utilizza queste informazioni per identificarti come autore dei commit creati in Cloud Shell:
git config --global user.email "GITHUB_EMAIL_ADDRESS" git config --global user.name "GITHUB_USERNAME"
Sostituisci quanto segue:
GITHUB_EMAIL_ADDRESS
: l'indirizzo email associato al tuo account GitHubGITHUB_USERNAME
: il nome utente associato al tuo account GitHub
Clona il repository Git
sample-infra
:git clone https://github.com/GITHUB_ORG/sample-infra cd sample-infra
Sostituisci quanto segue:
GITHUB_ORG
con la tua organizzazione GitHub.
Il trigger cicd-trigger del ramo predefinito è verificato.
Aggiungi una nuova riga al file env/cicd-trigger/main.tf, esegui il commit della modifica ed esegui il push.
echo "" >> env/cicd-trigger/main.tf
Esegui il commit e il push delle modifiche:
git add . git commit -m "A dummy commit to invoke the infrastrucutre trigger" git push cd ..
Non appena viene eseguito il push delle modifiche, viene avviato il trigger di Cloud Deploy
deploy-infra-sample
.
Monitora lo stato dell'attivatore:
Vai alla pagina della cronologia di Cloud Build per visualizzare la pipeline e attendi che venga completata.
Rivedi le risorse CICD dell'applicazione
Esamina le varie risorse CI/CD create per l'applicazione.
Nella console Google Cloud:
Vai alla pagina Cloud Build e visualizza il trigger
deploy-app-sample
.Questo è il trigger della pipeline CI. È connesso al repository del codice dell'applicazione
sample
. Il trigger viene richiamato quando viene eseguito un push al repository dell'applicazione ed esegue i passaggi di build definiti nella configurazione del trigger. Per visualizzare i passaggi eseguiti dal trigger quando viene richiamato, fai clic sul nome del trigger e poi sul pulsante APRI EDITOR.Vai alla pagina di Artifact Registry e visualizza il nuovo repository con il nome
sample
.Questo repository di artefatti archivia gli artefatti dell'applicazione.
Vai alla pagina della pipeline di Cloud Deploy e visualizza la pipeline con il nome
sample
. Questa è la pipeline di deployment continuo che esegue il deployment dell'applicazione nei cluster GKE.
Esegui il deployment dell'applicazione nell'ambiente di sviluppo
Il trigger deploy-app-sample
è connesso al repository dell'applicazione denominato sample
. Puoi richiamare il trigger manualmente, utilizzando l'URL webhook o tramite push al repository dell'applicazione.
Aggiungi una nuova riga in un file nel repository
sample
ed esegui il push delle modifiche per richiamare il trigger di Cloud Build:Clona il repository Git
sample
:In Cloud Shell:
git clone https://github.com/GITHUB_ORG/sample cd sample
Sostituisci
GITHUB_ORG
con la tua organizzazione GitHub.Aggiungi una nuova riga al file
skaffold.yaml
.echo "" >> skaffold.yaml
Esegui il commit e il push delle modifiche:
git add . git commit -m "A dummy commit to invoke CI/CD trigger" git push
Non appena viene eseguito il push delle modifiche, viene avviato il trigger di Cloud Deploy
deploy-app-sample
.
Monitora lo stato dell'attivatore:
Vai alla pagina della cronologia di Cloud Build per visualizzare la pipeline e attendi che venga completata.
Il trigger esegue i passaggi definiti nella sua configurazione. Il primo passaggio consiste nel creare un'immagine Docker dal codice dell'applicazione nel repository
sample
. L'ultimo passaggio consiste nell'avviare la pipeline di Cloud Deploy che esegue il deployment dell'applicazione nel cluster GKE di sviluppo.Controlla il deployment nel cluster di sviluppo:
Vai alla pagina della pipeline di Cloud Deploy.
Fai clic sulla pipeline
sample
. Il deployment nel cluster GKE di sviluppo è stato avviato. Attendi che venga completata.
Verifica che il deployment dell'applicazione sia stato eseguito correttamente :
Recupera le credenziali al cluster di sviluppo.
gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
Esegui il tunneling nel cluster GKE.
gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080
Nella barra degli strumenti di Cloud Shell, fai clic su
Anteprima web, quindi fai clic su Anteprima sulla porta 8080:
L'output è il seguente:
Hello World!
In Cloud Shell, premi
CTRL+C
per terminare il port forwarding.
Aggiungi una nuova funzionalità all'applicazione
Quando sviluppi una nuova funzionalità, devi eseguire rapidamente il deployment delle modifiche nell'ambiente di sviluppo per testarle ed eseguire l'iterazione. In questo tutorial imparerai ad apportare modifiche nel repository del codice delle applicazioni e a eseguirne il deployment nell'ambiente di sviluppo.
In Cloud Shell, cambia la directory in repository
sample
già clonato:Aggiorna l'applicazione in modo che restituisca un messaggio diverso:
sed -i "s/Hello World/My new feature/g" main.py
Esegui il commit e il push delle modifiche:
git add . git commit -m "Changed the message" git push
Non appena viene eseguito il push del codice al repository GitHub, il trigger di webhook
deploy-app-sample
viene avviato.Monitora lo stato del trigger nella pagina della cronologia di Cloud Build e attendi che venga completato.
Vai alla pagina della pipeline di Cloud Deploy
Fai clic sulla pipeline
sample
. Il deployment nel cluster GKE di sviluppo è stato avviato. Attendi che venga completata.
Verifica che il deployment dell'applicazione sia stato eseguito correttamente :
Recupera le credenziali per il cluster di sviluppo se hai aperto una nuova sessione di Cloud Shell:
gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
Esegui il tunnel nel cluster GKE:
gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080
Nella barra degli strumenti di Cloud Shell, fai clic su
Anteprima web, quindi fai clic su Anteprima sulla porta 8080:
L'output è il seguente:
My new feature!
In Cloud Shell, premi
CTRL+C
per terminare il port forwarding.
Promuovi la modifica ai cluster di gestione temporanea e produzione
Prima di promuovere l'applicazione in ambienti di gestione temporanea e produzione, devi creare la zona di destinazione per l'applicazione nei cluster GKE per quegli ambienti. Quando hai eseguito l'onboarding dell'applicazione, la zona di destinazione per lo sviluppo è stata creata automaticamente nel cluster GKE dev aggiungendo il codice a acm-gke-infrastructure-repo
nel ramo dev.
Crea una zona di destinazione nella gestione temporanea e nella produzione di cluster GKE
Crea zona di destinazione nel cluster GKE gestione temporanea: devi creare una richiesta pull da sviluppo a ramo gestione temporanea in
acm-gke-infrastructure-repo
e unirla.Vai a GitHub e passa al repository
acm-gke-infrastructure-repo
. Fai clic suPull requests
e poi sul pulsanteNew pull request
. Nel menu Base, scegli staging, quindi nel menu Confronta scegli dev. Fai clic sul pulsanteCreate pull request
.In genere, un utente che ha accesso al repository esamina le modifiche e poi unisce il PR per assicurarsi che solo le modifiche previste vengano promosse nell'ambiente di gestione temporanea. Per consentire ai singoli utenti di provare l'architettura di riferimento, le regole di protezione dei rami sono state allentate in modo che l'amministratore del repository possa ignorare la revisione e unire il PR. Se sei un amministratore del repository, unisci la richiesta di pull. In caso contrario, chiedi all'amministratore di unirli.
Config Sync sincronizza le modifiche ricevute nel ramo di gestione temporanea del repository
acm-gke-infrastructure-repo
con il cluster GKE di gestione temporanea, che comporta la creazione della zona di destinazione per l'applicazione sul cluster GKE di gestione temporanea.Crea zona di destinazione nei cluster GKE di produzione: devi creare una richiesta di pull dalla gestione temporanea al ramo di produzione e unirla.
Fai clic su
Pull requests
e poi sul pulsanteNew pull request
. Nel menu Base, scegli prod e nel menu Confronta scegli staging. Fai clic sul pulsanteCreate pull request
.Se sei un amministratore del repository, unisci la richiesta di pull. In caso contrario, chiedi all'amministratore di unirli.
Config Sync sincronizza le modifiche ricevute nel ramo di produzione del repository
acm-gke-infrastructure-repo
con i cluster GKE di produzione, il che comporta la creazione della zona di destinazione per l'applicazione nei cluster GKE di produzione.
Promuovere i cambiamenti dallo sviluppo alla gestione temporanea
Ora che hai creato la zona di destinazione per l'applicazione nei cluster GKE di gestione temporanea e produzione, promuovi l'applicazione dall'ambiente di sviluppo a quello di gestione temporanea.
Trova il nome della release più recente e salvalo come variabile di ambiente:
export RELEASE=$(gcloud deploy targets describe dev --region=us-central1 --format="json" | jq -r '."Active Pipeline"[0]."projects/PROJECT_ID/locations/us-central1/deliveryPipelines/sample"."Latest release"' | awk -F '/' '{print $NF}')
Sostituisci
PROJECT_ID
con l'ID del tuo progetto Google Cloud.Verifica che la variabile di ambiente sia stata impostata:
echo $RELEASE
In Cloud Shell, esegui questo comando per attivare la promozione della release dall'ambiente di sviluppo all'ambiente di gestione temporanea:
gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample --region=us-central1 --to-target=staging --quiet
Controlla il deployment gestione temporanea:
Vai alla pagina della pipeline di Cloud Deploy
Fai clic sulla pipeline
sample
. Il deployment nel cluster GKE di gestione temporanea è stato avviato. Attendi che venga completata.Verifica che il deployment gestione temporanea sia stato eseguito correttamente:
Recupera le credenziali per il cluster gestione temporanea:
gcloud container clusters get-credentials gke-staging-us-central1 --zone us-central1-a
Esegui il tunnel nel cluster GKE:
gcloud container clusters get-credentials gke-staging-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080
Nella barra degli strumenti di Cloud Shell, fai clic su
Anteprima web, quindi fai clic su Anteprima sulla porta 8080:
L'output è il seguente:
My new feature!
In Cloud Shell, premi
CTRL+C
per terminare il port forwarding.
Promuovere le modifiche dalla gestione temporanea alla produzione
Ora promuovi la release dalla gestione temporanea alla produzione. Hai due cluster di produzione e Cloud Deploy ha un target per ciascuno di loro denominato prod1 e prod2 rispettivamente.
In Cloud Shell, esegui questo comando per attivare la promozione della release dalla gestione temporanea al cluster prod1:
gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample --region=us-central1 --to-target=prod1 --quiet
Il rilascio in cluster di produzione richiede l'approvazione, quindi l'implementazione attende fino a quando non la approvi. Per visualizzarlo:
Vai alla pagina della pipeline di Cloud Deploy
Fai clic sulla pipeline
sample
. L'implementazione in prod1 richiede l'approvazione e il ruolo clouddeploy.approver è necessario per approvare l'implementazione. Poiché sei il proprietario del progetto, puoi accedere per approvare la release.Approva la release per prod1:
Esegui questo comando per recuperare il nome dell'implementazione in attesa di approvazione e salvarlo in una variabile di ambiente:
export ROLLOUT=$(gcloud deploy targets describe prod1 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')
Approva la release:
gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet
Dopo l'approvazione, inizia la release prod1. Monitora l'avanzamento nella pagina della pipeline di Cloud Deploy.
Una volta completato il deployment di prod1, avvia la release prod2.
gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample --region=us-central1 --to-target=prod2 --quiet
Anche il rilascio in prod2 richiede l'approvazione. Approva la release nel cluster prod2:
Esegui questo comando per recuperare il nome dell'implementazione in attesa di approvazione e salvarlo in una variabile di ambiente:
export ROLLOUT=$(gcloud deploy targets describe prod2 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')
Approva la release:
gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet
Dopo l'approvazione, inizia la release prod2. Monitora l'avanzamento nella pagina della pipeline di Cloud Deploy.
Verifica che il deployment nel cluster di produzione sia riuscito dopo il completamento delle pipeline di Cloud Deploy in prod1 e prod2.
Nei cluster di produzione viene creato un Ingress multi-cluster e utilizzi un bilanciatore del carico per accedere all'applicazione di produzione. Queste configurazioni Ingress multi-cluster vengono create utilizzando i file YAML k8s/prod/mci.yaml e k8s/prod/mcs.yaml nel repository
sample
. Quando invii una richiesta all'indirizzo IP del bilanciatore del carico, Ingress multi-cluster la inoltra a una delle due istanze dell'applicazione in esecuzione in due diversi cluster GKE.Elenca la regola di forwarding associata al bilanciatore del carico per trovare l'indirizzo IP.
gcloud compute forwarding-rules list
L'output è simile al seguente:
NAME: mci-qqxs9x-fw-sample-sample-ingress REGION: IP_ADDRESS: 34.36.123.118 IP_PROTOCOL: TCP TARGET: mci-qqxs9x-sample-sample-ingress
Apri un browser web e inserisci quanto segue nell'URL:
http://IP_ADDRESS:80
Sostituisci
IP_ADDRESS
con l'indirizzo IP del bilanciatore del carico.L'output è il seguente:
My new feature!
Questo conferma che il deployment dell'applicazione sia stato eseguito come previsto nei cluster di produzione.
Testa la resilienza dell'applicazione
In questa sezione testerai la resilienza dell'applicazione in esecuzione in produzione riavviando uno dei due nodi dei due cluster GKE di produzione senza influire sull'applicazione.
L'applicazione in produzione utilizza il traffico in entrata multi-cluster ed è accessibile tramite un IP del bilanciatore del carico. Quando si accede all'applicazione attraverso quell'IP, il traffico in entrata multi-cluster la instrada a una delle due istanze dell'applicazione in esecuzione su due diversi cluster GKE. Quando uno dei cluster GKE non è integro e l'istanza dell'applicazione in esecuzione non può essere raggiunta, il traffico multi-cluster in entrata continua a inviare il traffico all'istanza integro dell'applicazione in esecuzione sull'altro cluster GKE. Ciò rende invisibile l'interruzione del cluster all'utente finale e l'applicazione gestisce continuamente le richieste.
Per testare la resilienza:
Trova il pool di nodi dei cluster GKE di produzione in esecuzione in us-west1.
gcloud container clusters describe gke-prod-us-west1 --zone=us-west1-a --format=json | jq ".nodePools[0].instanceGroupUrls[]" | tr '"' ' ' | awk -F '/' '{for(i=NF-2; i<=NF; i=i+2) printf ("%s ",$i); print ""}'
L'output è simile al seguente:
us-west1-b gke-gke-prod-us-west1-node-pool-01-6ad4e1ed-grp us-west1-c gke-gke-prod-us-west1-node-pool-01-98407373-grp
L'output ha due colonne: la prima colonna è la zona e la seconda colonna è il nome del gruppo di istanze associato al pool di nodi del cluster GKE di produzione nella regione us-west1.
Riavvia il gruppo di istanze corrispondente ai pool di nodi:
gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_1 --zone=ZONE_1 --max-unavailable=100% gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_2 --zone=ZONE_2 --max-unavailable=100%
Sostituisci
INSTANCE_GROUP_1
con il nome del primo gruppo di istanze.Sostituisci
ZONE_1
con la zona del primo gruppo di istanze.Sostituisci
INSTANCE_GROUP_2
con il nome del secondo gruppo di istanze.Sostituisci
ZONE_2
con la zona del secondo gruppo di istanze.Controlla lo stato del gruppo di istanze.
Vai alla pagina Gruppi di istanze
I due gruppi di istanze sono in fase di riavvio, mentre per gli altri gruppi è presente un segno di spunta verde.
Apri un browser web e inserisci quanto segue nell'URL:
http://IP_ADDRESS:80
Sostituisci
IP_ADDRESS
con l'indirizzo IP del bilanciatore del carico.Anche quando uno dei due cluster GKE non è attivo, l'applicazione è disponibile e l'output è il seguente:
My new feature!
Questo dimostra che la tua applicazione è resiliente e ad alta disponibilità.
Gestisci l'applicazione
Quando hai creato questa applicazione dalla fabbrica dell'applicazione, hai ottenuto pipeline Git, infrastruttura e pipeline CI/CD separate per l'applicazione. Hai utilizzato queste risorse per eseguire il deployment dell'applicazione e aggiungere una nuova funzionalità. Per gestire ulteriormente l'applicazione, devi solo interagire con questi repository Git e la pipeline senza dover aggiornare i dati di fabbrica dell'applicazione. Puoi personalizzare le pipeline e i repository Git dell'applicazione in base ai tuoi requisiti. In qualità di proprietario dell'applicazione, puoi definire chi può accedere alle pipeline e ai repository Git della tua applicazione per gestirla.
Esegui la pulizia
Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial.
Elimina il progetto
- Nella console Google Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.
Passaggi successivi
- Scopri le best practice per la configurazione della federazione delle identità.
- Leggi Kubernetes e le sfide del deployment continuo del software.
- Scopri di più sui pattern di logging e monitoraggio ibridi e multi-cloud.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.