Deployment continuo su Google Kubernetes Engine (GKE) con Cloud Build

1. Panoramica

In questo lab imparerai a configurare una pipeline di continuous delivery per GKE con Cloud Build. Questo lab mette in evidenza come attivare job Cloud Build per diversi eventi Git, nonché un semplice pattern per le release canary automatizzate in GKE.

Completa i seguenti passaggi:

• Crea l'applicazione GKE
• Automatizzare i deployment per i rami Git
• Automatizzare i deployment per il ramo principale di Git
• Automatizzare i deployment per i tag Git

2. Prima di iniziare

Per questa guida di riferimento, hai bisogno di un progetto Google Cloud. Puoi crearne uno nuovo o selezionarne uno già esistente:

1. Seleziona o crea un progetto Google Cloud.

VAI ALLA PAGINA DEL SELETTORE DEI PROGETTI

1. Abilita la fatturazione per il tuo progetto.

ATTIVA LA FATTURAZIONE

3. prepara l'ambiente

1. Crea variabili di ambiente da utilizzare in questo tutorial:

   export PROJECT_ID=$(gcloud config get-value project)
   export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')
   
   export ZONE=us-central1-b
   export CLUSTER=gke-progression-cluster
   export APP_NAME=myapp
   

2. Abilita le seguenti API:
   • Resource Manager
   • GKE
   • Cloud Source Repositories
   • Cloud Build
   • Container Registry

   gcloud services enable \
       cloudresourcemanager.googleapis.com \
       container.googleapis.com \
       sourcerepo.googleapis.com \
       cloudbuild.googleapis.com \
       containerregistry.googleapis.com \
       --async
   

3. Clona l'origine di esempio e passa alla directory del lab:

   git clone https://github.com/GoogleCloudPlatform/software-delivery-workshop.git gke-progression
   
   cd gke-progression/labs/gke-progression
   rm -rf ../../.git
   

4. Sostituisci i valori segnaposto nel repository di esempio con il tuo PROJECT_ID:in questo passaggio crei istanze dei vari file di configurazione univoci per il tuo ambiente attuale.Per esaminare un esempio dei modelli in fase di aggiornamento, esegui il seguente comando.

   cat k8s/deployments/dev/frontend-dev.yaml.tmpl
   

   Esegui la sostituzione delle variabili eseguendo il comando seguente.

   for template in $(find . -name '*.tmpl'); do envsubst '${PROJECT_ID} ${ZONE} ${CLUSTER} ${APP_NAME}' < ${template} > ${template%.*}; done
   

   Per esaminare un esempio del file dopo la sostituzione, esegui questo comando.

   cat k8s/deployments/dev/frontend-dev.yaml
   

5. Se non hai mai utilizzato Git in Cloud Shell, imposta i valori user.name e user.email che vuoi utilizzare:

   git config --global user.email "YOUR_EMAIL_ADDRESS"
   git config --global user.name "YOUR_USERNAME"
   

6. Archivia il codice del repository di esempio in Cloud Source Repositories:

   gcloud source repos create gke-progression
   git init
   git config credential.helper gcloud.sh
   git remote add gcp https://source.developers.google.com/p/$PROJECT_ID/r/gke-progression
   git branch -m main
   git add . && git commit -m "initial commit"
   git push gcp main
   

7. Crea il cluster GKE.

   gcloud container clusters create ${CLUSTER} \
       --project=${PROJECT_ID} \
       --zone=${ZONE}
   

8. Concedi a Cloud Build i diritti per il tuo cluster.Cloud Build eseguirà il deployment dell'applicazione nel tuo cluster GKE e avrà bisogno dei diritti per farlo.

   gcloud projects add-iam-policy-binding ${PROJECT_ID} \
       --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
       --role=roles/container.developer
   

Il tuo ambiente è pronto.

4. Creazione dell'applicazione GKE

In questa sezione, crei e implementi l'applicazione di produzione iniziale che utilizzerai in questo tutorial.

1. Crea l'applicazione con Cloud Build:

   gcloud builds submit --tag gcr.io/$PROJECT_ID/$APP_NAME:1.0.0 src/
   

2. Esegui il deployment manualmente negli ambienti canary e di produzione:crea i deployment di produzione e canary e i servizi utilizzando i comandi kubectl apply.

   kubectl create ns production
   kubectl apply -f k8s/deployments/prod -n production
   kubectl apply -f k8s/deployments/canary -n production
   kubectl apply -f k8s/services -n production
   

   Il servizio di cui è stato eseguito il deployment qui indirizzerà il traffico sia al deployment canary che a quello di produzione.
3. Controlla il numero di pod in esecuzione. Verifica di avere quattro pod in esecuzione per il frontend, di cui tre per il traffico di produzione e uno per le versioni canary. Ciò significa che le modifiche alla versione canary interesseranno solo 1 utente su 4 (25%).

   kubectl get pods -n production -l app=$APP_NAME -l role=frontend
   

4. Recupera l'indirizzo IP esterno per i servizi di produzione.

   Nota: potrebbero essere necessari diversi minuti prima che tu possa visualizzare l'indirizzo IP esterno del bilanciatore del carico.

   kubectl get service $APP_NAME -n production
   

   Quando il bilanciatore del carico restituisce l'indirizzo IP, vai al passaggio successivo.
5. Memorizza l'IP esterno per utilizzarlo in un secondo momento.

   export PRODUCTION_IP=$(kubectl get -o jsonpath="{.status.loadBalancer.ingress[0].ip}"  --namespace=production services $APP_NAME)
   

6. Rivedi l'applicazione Controlla l'output della versione del servizio. Dovrebbe essere visualizzato Hello World v1.0

   curl http://$PRODUCTION_IP
   

Complimenti! Hai eseguito il deployment dell'app di esempio. Ora configurerai i trigger per il deployment continuo delle modifiche.

5. Automatizzare i deployment per i rami Git

In questa sezione configurerai un trigger che eseguirà un job Cloud Build al commit di qualsiasi ramo diverso da main. Il file Cloud Build utilizzato qui creerà automaticamente uno spazio dei nomi e un deployment per qualsiasi ramo esistente o nuovo, consentendo agli sviluppatori di visualizzare l'anteprima del codice prima dell'integrazione con il ramo principale.

1. Configura il trigger:il componente chiave di questo trigger è l'utilizzo del parametro branchName per trovare una corrispondenza con main e del parametro invertRegex, impostato su true, che modifica il pattern branchName in modo che corrisponda a qualsiasi valore diverso da main. Per riferimento, puoi trovare le seguenti righe in build/branch-trigger.json.

     "branchName": "main",
     "invertRegex": true
   

   Inoltre, le ultime righe del file Cloud Build utilizzato con questo trigger creano uno spazio dei nomi denominato in base al ramo che ha attivato il job, quindi eseguono il deployment dell'applicazione e del servizio nel nuovo spazio dei nomi. Per riferimento, puoi trovare le seguenti righe in build/branch-cloudbuild.yaml

     kubectl get ns ${BRANCH_NAME} || kubectl create ns ${BRANCH_NAME}
     kubectl apply --namespace ${BRANCH_NAME} --recursive -f k8s/deployments/dev
     kubectl apply --namespace ${BRANCH_NAME} --recursive -f k8s/services
   

   Ora che hai compreso i meccanismi in uso, crea il trigger con il comando gcloud riportato di seguito.

   gcloud beta builds triggers create cloud-source-repositories \
     --trigger-config build/branch-trigger.json
   

2. Per esaminare il trigger, vai alla pagina Trigger di Cloud Build nella console.Vai a Trigger
3. Crea un nuovo ramo:

   git checkout -b new-feature-1
   

4. Modifica il codice per indicare v1.1Edit src/app.py e cambia la risposta da 1.0 a 1.1

   @app.route('/')
   def hello_world():
       return 'Hello World v1.1'
   

5. Esegui il commit della modifica e il push nel repository remoto:

   git add . && git commit -m "updated" && git push gcp new-feature-1
   

6. Per esaminare la build in corso, vai alla pagina Cronologia di Cloud Build nella console.Vai a BuildUna volta completata la build, continua con il passaggio successivo.
7. Recupera l'indirizzo IP esterno per il servizio di ramo appena implementato.

   Nota: potrebbero essere necessari diversi minuti prima che tu possa visualizzare l'indirizzo IP esterno del bilanciatore del carico.

   kubectl get service $APP_NAME -n new-feature-1
   

   Quando il bilanciatore del carico restituisce l'indirizzo IP, vai al passaggio successivo.
8. Memorizza l'IP esterno per utilizzarlo in un secondo momento.

   export BRANCH_IP=$(kubectl get -o jsonpath="{.status.loadBalancer.ingress[0].ip}"  --namespace=new-feature-1 services $APP_NAME)
   

9. Rivedi l'applicazione. Controlla l'output della versione del servizio. Dovrebbe essere visualizzato Hello World v1.0

   curl http://$BRANCH_IP
   

6. Automatizzare i deployment per il ramo principale di Git

Prima che il codice venga rilasciato in produzione, è prassi rilasciarlo a un piccolo sottoinsieme di traffico live prima di eseguire la migrazione di tutto il traffico al nuovo codebase.

In questa sezione, implementerai un trigger che viene attivato quando il codice viene eseguito il commit nel ramo principale. Il trigger esegue il deployment canary che riceve il 25% di tutto il traffico live alla nuova revisione.

1. Configura il trigger per il ramo principale:

   gcloud beta builds triggers create cloud-source-repositories \
     --trigger-config build/main-trigger.json
   

2. Per esaminare il nuovo trigger, vai alla pagina Trigger di Cloud Build nella console.Vai a Trigger
3. Unisci il branch alla linea principale ed esegui il push al repository remoto:

   git checkout main
   git merge new-feature-1
   git push gcp main
   

4. Per esaminare la build in corso, vai alla pagina Cronologia di Cloud Build nella console.Vai a BuildUna volta completata la build, continua con il passaggio successivo.
5. Esamina più risposte dal server Esegui il comando seguente e tieni presente che circa il 25% delle risposte mostra la nuova risposta di Hello World v1.1

   while true; do curl -w "\n" http://$PRODUCTION_IP; sleep 1;  done
   

   Quando è tutto pronto per continuare, premi Ctrl+c per uscire dal ciclo.

7. Automatizzare i deployment per i tag Git

Dopo aver convalidato il deployment canary con un piccolo sottoinsieme di traffico, rilasci il deployment al resto del traffico live.

In questa sezione, configurerai un trigger che viene attivato quando crei un tag nel repository. Il trigger etichetta l'immagine con il tag appropriato, quindi esegue il deployment degli aggiornamenti in produzione, assicurando che il 100% del traffico acceda all'immagine con tag.

1. Configura l'attivatore del tag:

   gcloud beta builds triggers create cloud-source-repositories \
     --trigger-config build/tag-trigger.json
   

2. Per esaminare il nuovo trigger, vai alla pagina Trigger di Cloud Build nella console.Vai a Trigger
3. Crea un nuovo tag e invialo al repository remoto:

   git tag 1.1
   git push gcp 1.1
   

4. Per esaminare la build in corso, vai alla pagina Cronologia di Cloud Build nella console.Vai a Build
5. Esamina più risposte dal server. Esegui il seguente comando e tieni presente che il 100% delle risposte mostra la nuova risposta Hello World v1.1. Questa operazione potrebbe richiedere un po' di tempo, poiché i nuovi pod vengono implementati e controllati in GKE.

   while true; do curl -w "\n" http://$PRODUCTION_IP; sleep 1;  done
   

   Quando è tutto pronto per continuare, premi Ctrl+c per uscire dal ciclo. Congratulazioni. Hai creato trigger CI/CD in Cloud Build per rami e tag per eseguire il deployment delle tue app in GKE.

8. Esegui la pulizia

Elimina il progetto

Attenzione: l'eliminazione di un progetto ha i seguenti effetti: tutto il contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per questo tutorial, quando lo eliminerai, eliminerai anche tutto il lavoro effettuato nel progetto.

1. In Cloud Console, vai alla pagina Gestisci risorse.
2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
3. Nella finestra di dialogo, digita l'ID progetto, quindi fai clic su Chiudi per eliminare il progetto.