Questo tutorial mostra come eseguire l'onboarding di una nuova applicazione, sviluppare una funzionalità per l'applicazione ed eseguirne il deployment in produzione utilizzando tecniche moderne di integrazione/distribuzione continua (CI/CD) con Google Kubernetes Engine (GKE).
Questo documento fa parte di una serie:
- CI/CD moderno con GKE: un framework di distribuzione del software
- CI/CD moderno con GKE: crea 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 e distribuire l'applicazione.
Questo documento è rivolto a Enterprise Architect e sviluppatori di applicazioni, nonché a team di sicurezza IT, DevOps e Site Reliability Engineering (SRE). Per comprendere i concetti di questo documento, è utile avere una certa esperienza con gli strumenti e le procedure di deployment automatico.
Architettura
In questo tutorial esegui l'onboarding di una nuova applicazione. Poi, sviluppi una nuova funzionalità ed esegui il deployment dell'applicazione negli ambienti di sviluppo, di gestione temporanea e di produzione. L'architettura di riferimento contiene l'infrastruttura e gli strumenti necessari per l'onboarding e il rilascio di una nuova applicazione con il flusso di lavoro mostrato nel seguente diagramma:
A partire dal repository del codice per la CI, il flusso di lavoro include i seguenti passaggi:
Condividi il codice sorgente dell'applicazione tramite i repository dell'applicazione.
Quando esegui il commit e il push del codice nel repository dell'applicazione, viene attivata automaticamente una pipeline CI in Cloud Build. Il processo CI crea ed esegue il push di un'immagine container in Artifact Registry.
Il processo di CI crea anche una release CD per l'applicazione in Cloud Deploy.
La release CD genera manifest Kubernetes completamente visualizzati per lo sviluppo utilizzando
skaffold
e li esegue nel cluster GKE di sviluppo.La release del CD viene quindi promossa dal dev a un target di staging, che genera manifest di staging completamente visualizzati e li esegue nel cluster GKE di staging.
La release CD viene quindi promossa dalla fase di staging a quella di produzione, generando manifest di produzione completamente visualizzati e eseguendone 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
Esegui l'onboarding di una nuova applicazione.
Esegui il deployment dell'applicazione nell'ambiente di sviluppo.
Sviluppare una nuova funzionalità ed eseguirne il deployment nell'ambiente di sviluppo.
Promuovi la nuova funzionalità in staging e poi rilasciala in produzione.
Verifica la resilienza dell'applicazione.
Costi
In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:
- Google Kubernetes Engine
- Google Kubernetes Engine (GKE) Enterprise edition for Config Sync
- Artifact Registry
- Cloud Build
- Cloud Deploy
Per generare una stima dei costi in base all'utilizzo previsto,
utilizza il Calcolatore prezzi.
Al termine delle attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione Pulizia.
Prima di iniziare
- Per questo tutorial, esegui il deployment dell'architettura di riferimento in questa serie.
prepara l'ambiente
Se continui direttamente da CI/CD moderno con GKE: creazione di un sistema CI/CD, vai alla sezione successiva. Tuttavia, se hai una nuova sessione o se 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.
Eseguire l'onboarding di una nuova applicazione
L'architettura di riferimento contiene una factory di applicazioni. Questa factory è una raccolta di un repository Git denominato application-factory-repo
e dei seguenti trigger Cloud Build:
create-app
tf-plan
tf-apply
create-team
Utilizza la factory di applicazioni per eseguire l'onboarding di una nuova applicazione dai repository di partenza. L'onboarding dell'applicazione prevede i seguenti passaggi:
Crea la definizione dell'applicazione: crea la definizione dell'applicazione in un file Terraform e salvala 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 dell'applicazione è costituita da:
Una landing zone 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 landing zone 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 eseguirlo. La zona di destinazione nei cluster di staging e di produzione viene creata con l'approccio GitOps. Questo approccio viene illustrato più avanti in questo documento quando è tutto pronto per promuovere la release in questi cluster.Il repository di infrastruttura del repository di partenza 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 Cloud Build di infrastruttura che prende il codice nel repository dell'infrastruttura e crea le risorse in base alla loro definizione.
Un repository dell'applicazione dal repository di partenza dell'applicazione che ospita il codice sorgente dell'applicazione.
Crea le risorse CI/CD dell'applicazione: utilizza l'infrastruttura dell'applicazione per creare risorse CI/CD per l'applicazione.
Crea la definizione dell'applicazione:
Esegui l'attivatore 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 Trigger
create-app
.Fai clic su MOSTRA URL DI ANTEPRIMA per visualizzare l'URL necessario per richiamare l'webhook.
In Cloud Shell, invoca l'attivatore inviando una richiesta curl all'URL ottenuto dal passaggio precedente e passando i parametri come 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 alla factory di applicazioni di utilizzare il modello Python per creare i repository di applicazioni."trigger_type": "webhook"
specifica il tipo di pipeline CI/CD per l'applicazione."github_team": ""
è un team di 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 l'attivatore
create-app
:Vai alla pagina Cronologia di Cloud Build.
È disponibile una nuova pipeline per l'attivatore
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 dall'attivatorecreate-app
. Controlla il file, che contiene il codice Terraform per creare una nuova applicazione.
Crea l'infrastruttura dell'applicazione:
Ora che hai creato la definizione dell'applicazione, esegui l'attivatore tf-apply
per creare l'infrastruttura dell'applicazione.
Nella console Google Cloud:
Fai clic sull'attivatore
tf-apply
.Fai clic su "MOSTRA ANTEPRIMA URL" per visualizzare l'URL necessario per richiamare l'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 l'attivatore
tf-apply
:Vai alla pagina Cronologia di Cloud Build.
È disponibile una nuova pipeline per l'attivatore
tf-apply
. Attendi il completamento.
Questo attivatore crea l'infrastruttura dell'applicazione.
Esamina l'infrastruttura dell'applicazione:
Esamina i vari componenti dell'infrastruttura dell'applicazione.
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 GKE di sviluppo.
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, sample.
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. Quindi, fai clic su Your organizations
. Scegli la tua organizzazione e fai clic sul repository sample-infra
.
Questo repository ha quattro branch: cicd-trigger
, dev
, staging
e prod
. Contiene anche quattro cartelle: cicd-trigger, dev, staging e prod. Il ramo predefinito è cicd-trigger
e puoi eseguire il push del codice al suo interno, mentre gli altri rami hanno regole di protezione, quindi non puoi eseguire il push del codice direttamente in questi rami. Per spingere il codice in questi rami, devi creare una richiesta 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 diversi ambienti dell'applicazione.
Attivatore dell'infrastruttura
Nella console Google Cloud:
Esiste un nuovo attivatore denominato
deploy-infra-sample
.Questo trigger è collegato al repository
sample-infra
in modo che, quando viene eseguito un push del codice in questo repository, l'trigger venga richiamato e identifichi il ramo in cui è stato eseguito il push, acceda alla cartella corrispondente su quel ramo ed esegua Terraform. Ad esempio, se il codice viene eseguito nel ramocicd-trigger
, l'attivatore esegue Terraform nella cartella cicd-trigger del ramo cicd-trigger. Analogamente, quando viene eseguito un push nel ramodev
, l'attivatore esegue Terraform nella cartella dev del ramo dev e così via.
Repository delle applicazioni
- Vai su GitHub e visualizza i repository della tua organizzazione. Esiste un nuovo repository con il nome
sample
. Questo repository ospita il codice sorgente e i passaggi per creare i container inDockerfile
, le configurazionikustomize
che descrivono le configurazioni necessarie dell'applicazione eskaffold.yaml
che definisce i passaggi di deployment da utilizzare da Cloud Deploy per il CD.
Creare risorse CI/CD per le applicazioni
Ora che hai creato lo scheletro dell'applicazione, esegui l'attivatore deploy-infra-sample
per creare le risorse CI/CD. Puoi richiamare l'attivatore manualmente utilizzando il relativo URL webhook o eseguendo un commit nel repository Git sample-infra
.
Per richiamare l'attivatore Cloud Build, aggiungi una nuova riga in un file del repository. Quindi, esegui il push delle modifiche:
Se non hai mai utilizzato Git in Cloud Shell, configuralo con il tuo nome e indirizzo email. Git utilizza queste informazioni per identificarti come autore dei commit che crei 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 branch predefinito cicd-trigger è stato sottoposto a check-out.
Aggiungi una nuova riga al file env/cicd-trigger/main.tf, esegui il commit della modifica e 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 le modifiche vengono inviate, viene avviato l'attivatore Cloud Deploy
deploy-infra-sample
.
Monitora lo stato dell'attivatore:
Vai alla pagina della cronologia di Cloud Build per visualizzare la pipeline e attendi il completamento.
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 l'attivatore
deploy-app-sample
.Questo è l'attivatore della pipeline CI. È connesso al repository del codice dell'applicazione
sample
. L'attivatore viene richiamato quando viene eseguito il push nel repository dell'applicazione ed esegue i passaggi di compilazione come definito nella configurazione dell'attivatore. Per visualizzare i passaggi eseguiti dall'attivatore quando viene richiamato, fai clic sul nome dell'attivatore e poi sul pulsante APRI EDITOR.Vai alla pagina Artifact Registry e visualizza il nuovo repository con il nome
sample
.Questo repository di artefatti memorizza gli artefatti dell'applicazione.
Vai alla pagina della pipeline Cloud Deploy e visualizza la pipeline con il nome
sample
. Questa è la pipeline di deployment continuo che esegue il deployment dell'applicazione sui cluster GKE.
Esegui il deployment dell'applicazione nell'ambiente di sviluppo
L'attivatore deploy-app-sample
è collegato al repository dell'applicazione denominato sample
. Puoi richiamare l'attivatore manualmente utilizzando l'URL webhook o tramite un push al repository dell'applicazione.
Aggiungi una nuova riga in un file del repository
sample
e invia le modifiche per richiamare l'attivatore 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 le modifiche vengono inviate, viene avviato l'attivatore Cloud Deploy
deploy-app-sample
.
Monitora lo stato dell'attivatore:
Vai alla pagina della cronologia di Cloud Build per visualizzare la pipeline e attendi il completamento.
L'attivatore esegue i passaggi definiti nella relativa 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 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 Cloud Deploy.
Fai clic sulla pipeline
sample
. Il deployment nel cluster GKE di sviluppo è stato avviato. Attendi il completamento.
Verifica che il deployment dell'applicazione sia andato a buon fine :
Recupera le credenziali per il cluster di sviluppo.
gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
Crea un 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, poi fai clic su Anteprima sulla porta 8080:L'output è il seguente:
Hello World!
In Cloud Shell, premi
CTRL+C
per terminare il port forwarding.
Aggiungere una nuova funzionalità all'applicazione
Quando sviluppi una nuova funzionalità, devi eseguire rapidamente il deployment delle modifiche nell'ambiente di sviluppo per testarle e eseguirne l'iterazione. In questo tutorial, apporti modifiche al repository del codice dell'applicazione e le esegui nell'ambiente di sviluppo.
In Cloud Shell, cambia directory impostandola sul repository
sample
già clonato:Aggiorna l'applicazione in modo da visualizzare 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 il codice viene eseguito nel repository GitHub, viene attivato l'attivatore webhook
deploy-app-sample
.Monitora lo stato dell'attivatore nella pagina Cronologia di Cloud Build e attendi il completamento.
Vai alla pagina della pipeline Cloud Deploy
Fai clic sulla pipeline
sample
. Il deployment nel cluster GKE di sviluppo è stato avviato. Attendi il completamento.
Verifica che il deployment dell'applicazione sia andato a buon fine :
Se hai aperto una nuova Cloud Shell, ottieni le credenziali per il cluster di sviluppo:
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 e poi 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.
Esegui la promozione della modifica ai cluster di staging e di produzione
Prima di promuovere l'applicazione negli ambienti di staging e di produzione, devi creare la landing zone per l'applicazione nei cluster GKE per questi ambienti. Quando hai eseguito l'onboarding dell'applicazione, la zona di destinazione per lo sviluppo è stata creata automaticamente nel cluster GKE di sviluppo aggiungendo codice a acm-gke-infrastructure-repo
nel ramo di sviluppo.
Crea una zona di destinazione nei cluster GKE di gestione temporanea e di produzione
Crea la landing zone nel cluster GKE di staging: devi creare una pull request dal ramo dev al ramo di staging in
acm-gke-infrastructure-repo
e unire i due.Vai su GitHub e vai al repository
acm-gke-infrastructure-repo
. Fai clic suPull requests
e poi sul pulsanteNew pull request
. Nel menu Base, scegli staging e nel menu Confronta, scegli dev. Fai clic sul pulsanteCreate pull request
.In genere, una persona che ha accesso al repository esamina le modifiche e poi unisce la PR per assicurarsi che solo le modifiche previste vengano promosse nell'ambiente di staging. Per consentire agli utenti di provare l'architettura di riferimento, le regole di protezione dei rami sono state allentate in modo che l'amministratore del repository possa bypassare la revisione e unire la PR. Se sei un amministratore del repository, unisci la richiesta di pull. In caso contrario, chiedi all'amministratore di unire i gruppi.
Config Sync sincronizza le modifiche che arrivano sul ramo di staging del repository
acm-gke-infrastructure-repo
con il cluster GKE di staging, il che si traduce nella creazione della landing zone per l'applicazione sul cluster GKE di staging.Crea una landing zone nei cluster GKE di produzione: devi creare una richiesta di pull dal ramo di staging a quello di produzione e unirli.
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 unire i gruppi.
Config Sync sincronizza le modifiche che arrivano sul ramo prod del repository
acm-gke-infrastructure-repo
con i cluster GKE di produzione, il che si traduce nella creazione di una landing zone per l'applicazione sui cluster GKE di produzione.
Esegui la promozione delle modifiche dallo sviluppo alla versione temporanea
Ora che hai creato la landing zone per l'applicazione nei cluster GKE di staging e di produzione, promuovi l'applicazione dall'ambiente di sviluppo a quello di staging.
Trova il nome dell'ultima release 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 il seguente comando per attivare la promozione della release dall'ambiente di sviluppo a quello di staging:
gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample --region=us-central1 --to-target=staging --quiet
Controlla il deployment di staging:
Vai alla pagina della pipeline Cloud Deploy
Fai clic sulla pipeline
sample
. Il deployment nel cluster GKE di staging è stato avviato. Attendi il completamento.Verifica che il deployment di staging sia andato a buon fine:
Recupera le credenziali per il cluster di staging:
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 e poi 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.
Esegui la promozione delle modifiche dalla versione temporanea alla produzione
Ora promuovi la release dalla versione temporanea alla produzione. Hai due cluster di produzione e Cloud Deploy ha un target per ciascuno di essi denominato rispettivamente prod1 e prod2.
In Cloud Shell, esegui il seguente comando per attivare la promozione della release dal cluster di staging a prod1:
gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample --region=us-central1 --to-target=prod1 --quiet
La release nei cluster di produzione richiede l'approvazione, pertanto l'implementazione attende fino a quando non la approvi. Per visualizzarlo:
Vai alla pagina della pipeline 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, hai accesso per approvare la release.Approva la release in prod1:
Esegui il seguente 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
Una volta concessa l'approvazione, inizia il rilascio di prod1. Monitora lo stato di avanzamento nella pagina della pipeline Cloud Deploy.
Al termine del deployment di prod1, avvia il rilascio di 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 il seguente 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
Una volta concessa l'approvazione, inizia il rilascio di prod2. Monitora lo stato di avanzamento nella pagina della pipeline Cloud Deploy.
Verifica che il deployment nel cluster di produzione sia andato a buon fine dopo il completamento delle pipeline Cloud Deploy in prod1 e prod2.
È stato creato Ingress multi-cluster nei cluster di produzione e utilizzi un bilanciatore del carico per accedere all'applicazione di produzione. Queste configurazioni di Ingress multicluster 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!
Ciò conferma che l'applicazione viene eseguita 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 nodi di uno dei due cluster GKE di produzione senza influire sull'applicazione.
L'applicazione in produzione utilizza l'ingresso multi-cluster ed è accessibile tramite un indirizzo IP del bilanciatore del carico. Quando si accede all'applicazione tramite questo indirizzo IP, Ingress multi-cluster la inoltra a una delle due istanze dell'applicazione in esecuzione su due diversi cluster GKE. Quando uno dei cluster GKE non è integro e non è possibile raggiungere l'istanza dell'applicazione in esecuzione, l'ingress multi-cluster continua a inviare il traffico all'istanza integra dell'applicazione in esecuzione sull'altro cluster GKE. In questo modo l'interruzione del cluster è invisibile all'utente finale e l'applicazione gestisce continuamente le richieste.
Per testare la resilienza:
Individua 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 è la zona e la seconda è 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 vengono riavviati, mentre gli altri gruppi sono contrassegnati da 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!
Ciò dimostra che la tua applicazione è resiliente e altamente disponibile.
Gestire l'applicazione
Quando hai creato questa applicazione dalla factory di applicazioni, hai ottenuto repository Git, infrastruttura e pipeline CI/CD separati per l'applicazione. Hai utilizzato queste risorse per implementare l'applicazione e aggiungere una nuova funzionalità. Per gestire ulteriormente l'applicazione, devi solo interagire con questi repository Git e la pipeline senza dover aggiornare la factory 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
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Passaggi successivi
- Scopri le best practice per la configurazione della federazione delle identità.
- Leggi l'articolo Kubernetes e le sfide del deployment continuo del software.
- Scopri di più su pattern di logging e monitoraggio per cloud ibrido e multi-cloud.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.