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

1. Panoramica

In questo lab imparerai a configurare una pipeline di distribuzione continua per GKE con Cloud Build. Questo lab evidenzia come attivare job Cloud Build per diversi eventi Git e un semplice pattern per le release canary automatizzate in GKE.

Devi completare questi passaggi:

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

2. Prima di iniziare

Per questa guida di riferimento, devi avere un progetto Google Cloud. Puoi crearne uno nuovo o selezionare un progetto già creato:

  1. Seleziona o crea un progetto Google Cloud.

VAI ALLA PAGINA SELETTORE PROGETTO

  1. Abilita la fatturazione per il tuo progetto.

ATTIVA LA FATTURAZIONE

3. preparazione dell'ambiente

  1. Crea le 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 creerai istanze dei vari file di configurazione univoci per il tuo ambiente attuale.Per esaminare un esempio dei modelli che vengono aggiornati, esegui questo comando.
    cat k8s/deployments/dev/frontend-dev.yaml.tmpl
    Esegui la sostituzione delle variabili eseguendo il comando followign.
    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 dal 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 tuo cluster GKE.
    gcloud container clusters create ${CLUSTER} \
    --project=${PROJECT_ID} \
    --zone=${ZONE}
  8. Concedi a Cloud Build i diritti al 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 corso...

In questa sezione creerai ed eseguirai il deployment dell'applicazione di produzione iniziale che utilizzerai durante 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 manuale in ambienti canary e di produzione:crea i deployment e i servizi di produzione e canary 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 instrada il traffico a entrambi i deployment canary e di produzione.
  3. Rivedi il numero di pod in esecuzioneVerifica che siano in esecuzione quattro pod 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. di Gemini Advanced. 
    kubectl get service $APP_NAME -n production
    Dopo che il bilanciatore del carico ha restituito l'indirizzo IP, vai al passaggio successivo
  5. Archivia 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. Esamina l'applicazione. Controlla l'output della versione del servizio. Dovrebbe essere scritto Hello World v1.0
    curl http://$PRODUCTION_IP

Complimenti! Hai eseguito il deployment dell'app di esempio. In seguito, configurerai un trigger per il deployment continuo delle modifiche.

5. Automazione dei deployment per i rami Git

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

  1. Configura l'attivatore:il componente chiave di questo attivatore è l'utilizzo del parametro branchName per trovare una corrispondenza con main e del parametro invertRegex, che è impostato su true e modifica il pattern branchName in modo che corrisponda a qualsiasi valore diverso da main. Come riferimento, puoi trovare le righe seguenti in build/branch-trigger.json.
      "branchName": "main",
  "invertRegex": true
    Inoltre, le ultime righe del file Cloud Build utilizzate con questo trigger creano uno spazio dei nomi denominato in base al ramo che ha attivato il job, quindi esegue il deployment dell'applicazione e del servizio all'interno del nuovo spazio dei nomi. Come riferimento, puoi trovare le seguenti righe nella sezione 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 ed esegui il push al 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, vai al passaggio successivo
  7. Recupera l'indirizzo IP esterno per il ramo di cui è stato eseguito il deployment. di Gemini Advanced. 
    kubectl get service $APP_NAME -n new-feature-1
    Dopo che il bilanciatore del carico ha restituito l'indirizzo IP, vai al passaggio successivo
  8. Archivia 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. Esamina l'output dell'applicazione. Controlla l'output della versione del servizio. Dovrebbe essere scritto Hello World v1.0
    curl http://$BRANCH_IP

6. Automazione dei deployment per il ramo principale Git

Prima del rilascio del codice nella versione di produzione, è comune rilasciarlo a un piccolo sottoinsieme di traffico in tempo reale prima di eseguire la migrazione di tutto il traffico al nuovo codebase.

In questa sezione implementerai un trigger che viene attivato quando viene eseguito il commit del codice nel ramo principale. Il trigger esegue il deployment del deployment canary, che riceve il 25% di tutto il traffico in tempo reale verso la 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 ramo alla riga 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, vai al passaggio successivo
  5. Esamina più risposte dal serverEsegui questo comando e nota 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 vuoi continuare, premi Ctrl+c per uscire dal loop.

7. Automatizzare i deployment per i tag Git

Dopo aver convalidato il deployment canary con un piccolo sottoinsieme di traffico, rilascialo per il resto del traffico in tempo reale.

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

  1. Configura l'attivatore di 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 ed esegui il push 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 serverEsegui il comando seguente e nota che il 100% delle risposte mostra la nuova risposta di Hello World v1.1. L'operazione potrebbe richiedere alcuni istanti, poiché viene eseguito il deployment dei nuovi pod e viene eseguito il controllo di integrità in GKE.
    while true; do curl -w "\n" http://$PRODUCTION_IP; sleep 1;  done
    Quando vuoi continuare, premi Ctrl+c per uscire dal cerchio.Congratulazioni! Hai creato trigger CI/CD in Cloud Build per rami e tag al fine di eseguire il deployment delle tue app in GKE.

8. Esegui la pulizia

Elimina il progetto

  1. Nella console Cloud, 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.