CI/CD moderno con GKE: applica il flusso di lavoro per sviluppatori

Last reviewed 2023-09-11 UTC

Standard

---

Questo tutorial mostra come eseguire l'onboarding di una nuova applicazione, sviluppare una funzionalità per l'applicazione ed eseguire il deployment dell'applicazione in produzione utilizzando tecniche di integrazione continua/distribuzione continua (CI/CD) moderne con Google Kubernetes Engine (GKE).

Questo documento fa parte di una serie:

• CI/CD moderna con GKE: un framework di distribuzione del software
• CI/CD moderna con GKE: crea un sistema CI/CD (architettura di riferimento)
• CI/CD moderno con GKE: applica il flusso di lavoro per sviluppatori (questo documento)

In questo tutorial utilizzi 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 è rivolto agli architetti aziendali e agli sviluppatori di applicazioni, nonché ai team di sicurezza IT, DevOps e SRE (Site Reliability Engineering). Per comprendere i concetti trattati in questo documento, è utile avere una certa esperienza con gli strumenti e i processi di deployment automatizzati.

Architettura

In questo tutorial imparerai a creare una nuova applicazione. Quindi, sviluppa una nuova funzionalità ed esegui il deployment dell'applicazione negli ambienti di sviluppo, gestione temporanea e 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 diagramma seguente:

A partire dal repository di codice per CI, il flusso di lavoro include i seguenti passaggi:

1. Condividi il codice sorgente dell'applicazione tramite i repository delle applicazioni.

2. Quando esegui il commit del codice ed esegui il push del codice nel repository di applicazioni, viene attivata automaticamente una pipeline CI in Cloud Build. Il processo CI crea ed esegue il push di un'immagine container ad Artifact Registry.

3. Il processo CI crea anche una release CD per l'applicazione in Cloud Deploy.

4. La release CD genera manifest Kubernetes con rendering completo per dev utilizzando skaffold e ne esegue il deployment nel cluster GKE di sviluppo.

5. La release CD viene quindi promossa da dev a target di gestione temporanea, che genera manifest di gestione temporanea con rendering completo e ne esegue il deployment nel cluster GKE di gestione temporanea.

6. Quindi, la release CD viene promossa dalla gestione temporanea alla produzione, che genera manifest di produzione con rendering completo ed esegue il deployment nei cluster GKE di produzione.

Per ulteriori informazioni sugli strumenti e sull'infrastruttura utilizzati in questo flusso di lavoro, consulta Approccio CI/CD moderno con GKE: creazione di un sistema CI/CD.

Obiettivi

• Eseguire 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 gestione temporanea e poi rilasciala in produzione.

• Testa 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. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

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 in questa serie.

prepara l'ambiente

1. Se continui direttamente da CI/CD moderna con GKE: creazione di un sistema CI/CD, vai alla sezione successiva. Tuttavia, se hai una nuova sessione o è 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

Puoi utilizzare la fabbrica delle applicazioni per eseguire l'onboarding di una nuova applicazione dai repository di base. L'onboarding per la richiesta prevede i seguenti passaggi:

1. Crea la definizione dell'applicazione: crei la definizione dell'applicazione in un file Terraform e la archivi in application-factory-repo, che funge da catalogo delle applicazioni.

2. Crea l'infrastruttura dell'applicazione: esegui Terraform sul file di definizione dell'applicazione per creare l'infrastruttura dell'applicazione. L'infrastruttura delle applicazioni è costituita da quanto segue:

   1. 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 in un cluster GKE di sviluppo solo durante l'onboarding di una nuova applicazione. Ciò viene fatto per sbloccare gli sviluppatori in modo che possano utilizzare l'ambiente di sviluppo e iniziare l'iterazione. La zona di destinazione nei cluster di gestione temporanea e produzione viene creata con l'approccio GitOps. Questo approccio viene illustrato più avanti in questo documento, quando tutto è pronto per promuovere la release nei cluster.

   2. Il repository dell'infrastruttura dal repository di base 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.

   3. Un trigger di Cloud Build dell'infrastruttura che acquisisce il codice nel repository dell'infrastruttura e crea le risorse in base alla relativa definizione.

   4. Un repository di applicazioni dal repository Application Starter che ospita il codice sorgente dell'applicazione.

3. Crea le risorse CI/CD dell'applicazione: utilizzerai l'infrastruttura dell'applicazione per creare risorse CI/CD per l'applicazione.

Nota: l'architettura di riferimento consente di automatizzare l'intera procedura di onboarding e deployment dell'applicazione. Per aiutarti a comprendere meglio l'architettura, questo documento suddivide i passaggi.

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.

1. Nella console Google Cloud, vai alla pagina Cloud Build:

   Vai alla pagina di Cloud Build

2. Fai clic su create-app attivatore.

3. Fai clic su MOSTRA ANTEPRIMA URL per visualizzare l'URL necessario per richiamare il webhook.

4. In Cloud Shell, richiama il trigger effettuando una richiesta curl all'URL ottenuto dal passaggio precedente e passandogli 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 al produttore di applicazioni 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. Dato che non hai ancora creato un team GitHub, passalo come stringa vuota.

5. Controlla la pipeline per il trigger create-app:

   Vai alla pagina Cronologia di Cloud Build.

   È presente una nuova pipeline per create-app trigger. Al termine, la definizione dell'applicazione viene creata in application-factory-repo.

6. Esamina il file di definizione dell'applicazione:

   1. In un browser web, vai a GitHub e accedi al tuo account.

   2. Fai clic sull'icona dell'immagine e poi su Your organizations. Scegli la tua organizzazione.

   3. Fai clic sul repository application-factory-repo, vai alla cartella apps/python e apri il nuovo file denominato sample.tf creato dal trigger di create-app. Esamina 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 il trigger tf-apply per creare l'infrastruttura dell'applicazione.

1. Nella console Google Cloud:

   Vai alla pagina di Cloud Build .

   Fai clic su tf-apply trigger.

2. Fai clic su "MOSTRA ANTEPRIMA URL" per visualizzare l'URL richiesto per richiamare il webhook.

3. Richiama l'attivatore:

   curl "WEBHOOK_URL" -d '{}'
   

   Nell'esempio di codice precedente:

   • Sostituisci WEBHOOK_URL con l'URL ottenuto dall'attivatore.

4. Controlla la pipeline per il trigger tf-apply:

   Vai alla pagina Cronologia di Cloud Build.

   È presente una nuova pipeline per tf-apply trigger. Attendi il completamento dell'operazione.

Questo trigger crea l'infrastruttura dell'applicazione.

Esamina l'infrastruttura dell'applicazione:

Esaminare i vari componenti dell'infrastruttura dell'applicazione.

Zona di destinazione

1. 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.

2. Recupera le credenziali per il cluster GKE di sviluppo.

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
   

3. 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
   

4. 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 anche 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 codice per creare l'infrastruttura per i diversi ambienti dell'applicazione.

Trigger dell'infrastruttura

• Nella console Google Cloud:

  Vai alla pagina di Cloud Build

  È presente un nuovo trigger denominato deploy-infra-sample.

• Questo trigger è connesso al repository sample-infra in modo che quando viene eseguito il push del codice al repository, il trigger viene richiamato e identifica il ramo in cui è stato eseguito il push, quindi va alla cartella corrispondente su quel ramo ed esegue Terraform da lì. Ad esempio, se il push del codice viene eseguito sul ramo cicd-trigger, il trigger esegue Terraform sulla cartella cicd-trigger del ramo cicd-trigger. Analogamente, quando viene eseguito un push al ramo dev, il trigger esegue Terraform sulla cartella dev del ramo dev e così via.

Repository di applicazioni

• Vai a GitHub e visualizza i repository nella tua organizzazione. Esiste un nuovo repository con il nome sample. Questo repository ospita il codice sorgente e i passaggi per creare container in Dockerfile, nelle configurazioni kustomize che descrivono le configurazioni necessarie dell'applicazione e in skaffold.yaml che definisce i passaggi di deployment per Cloud Deploy per CD.

Crea risorse CI/CD dell'applicazione

Ora che hai creato lo scheletro 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 nel repository Git sample-infra.

1. Per richiamare il trigger di Cloud Build, aggiungi una nuova riga in un file nel repository. Quindi, esegui il push delle modifiche:

   1. 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 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 GitHub
      • GITHUB_USERNAME: il nome utente associato al tuo account GitHub

   2. 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.

      È stato effettuato il check-out del ramo predefinito cicd-trigger.

   3. 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
      

   4. 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.

2. Monitora lo stato dell'attivatore:

   Vai alla pagina della cronologia di Cloud Build per visualizzare la pipeline e attendere il suo completamento.

Esamina le risorse CICD dell'applicazione

Esamina le varie risorse CI/CD create per l'applicazione.

1. 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 di codice dell'applicazione sample. Il trigger viene richiamato quando viene eseguito un push nel repository dell'applicazione ed esegue i passaggi di build definiti nella configurazione del trigger. Per visualizzare i passaggi eseguiti dall'attivatore quando viene richiamato, fai clic sul nome dell'attivatore e poi sul pulsante APRI EDITOR.

2. Vai alla pagina Artifact Registry e visualizza il nuovo repository con il nome sample.

   Questo repository di artefatti archivia gli artefatti dell'applicazione.

3. 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 di applicazioni denominato sample. Puoi richiamare il trigger manualmente, utilizzando l'URL webhook o mediante un push al repository delle applicazioni.

1. Aggiungi una nuova riga in un file nel repository sample ed esegui il push delle modifiche per richiamare il trigger di Cloud Build:

   1. Clona il repository Git sample:

      In Cloud Shell:

      git clone https://github.com/GITHUB_ORG/sample
      
      cd sample
      

      Sostituisci GITHUB_ORG con la tua prganizzazione GitHub.

   2. Aggiungi una nuova riga al file skaffold.yaml.

        echo "" >> skaffold.yaml
      

   3. Esegui il commit e il push delle modifiche:

      git add .
      git commit -m "A dummy commit to invoke CI/CD trigger"
      git push
      

   4. Non appena viene eseguito il push delle modifiche, viene avviato il trigger di Cloud Deploy deploy-app-sample.

2. Monitora lo stato dell'attivatore:

   Vai alla pagina della cronologia di Cloud Build per visualizzare la pipeline e attendere il suo completamento.

   L'attivatore 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 Cloud Deploy che esegue il deployment dell'applicazione nel cluster GKE di sviluppo.

3. Controlla il deployment nel cluster dev:

   Vai alla pagina della pipeline di Cloud Deploy.

   Fai clic sulla pipeline sample. Il deployment nel cluster GKE di sviluppo è stato avviato. Attendi il completamento dell'operazione.

Verifica che il deployment dell'applicazione sia stato eseguito correttamente :

1. Recupera le credenziali del cluster di sviluppo.

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
   

2. 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
   

3. 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!
   

4. 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 eseguirne l'iterazione. In questo tutorial imparerai a modificare il repository del codice dell'applicazione e a eseguirne il deployment nell'ambiente di sviluppo.

1. In Cloud Shell, cambia la directory in sample repository già clonato:

2. Aggiorna l'applicazione per generare un messaggio diverso:

     sed -i "s/Hello World/My new feature/g" main.py
   

3. 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 nel repository GitHub, il trigger webhook deploy-app-sample viene avviato.

4. Monitora lo stato del trigger nella pagina della cronologia di Cloud Build e attendi che venga completato.

5. Vai alla pagina della pipeline di Cloud Deploy

   Fai clic sulla pipeline sample. Il deployment nel cluster GKE di sviluppo è stato avviato. Attendi il completamento dell'operazione.

Verifica che il deployment dell'applicazione sia stato eseguito correttamente :

1. Ottieni le credenziali al cluster di sviluppo se hai aperto un nuovo Cloud Shell:

   gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a
   

2. 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
   

3. 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!
   

4. 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 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 il codice a acm-gke-infrastructure-repo nel ramo dev.

Crea una zona di destinazione nella gestione temporanea e nella produzione di cluster GKE

1. Crea una zona di destinazione nel cluster GKE di gestione temporanea: devi creare una richiesta di pull da sviluppo al ramo di gestione temporanea in acm-gke-infrastructure-repo e unirla.

   1. Vai a GitHub e accedi al repository acm-gke-infrastructure-repo. Fai clic su Pull requests, quindi sul pulsante New pull request. Nel menu Base, scegli gestione temporanea e nel menu Confronta scegli dev. Fai clic sul pulsante Create pull request.

   2. In genere, un utente che ha accesso al repository esamina le modifiche e quindi 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 semplificate in modo che l'amministratore del repository sia in grado di 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 che arrivano sul ramo temporaneo del repository acm-gke-infrastructure-repo con il cluster GKE di gestione temporanea che comporta la creazione di una zona di destinazione per l'applicazione sul cluster GKE di gestione temporanea.

2. Crea una zona di destinazione nei cluster GKE di produzione: devi creare una richiesta di pull dalla gestione temporanea al ramo di produzione e unirla.

   1. Fai clic su Pull requests, quindi sul pulsante New pull request. Nel menu Base scegli prod e nel menu Confronta scegli gestione temporanea. Fai clic sul pulsante Create pull request.

   2. Se sei un amministratore del repository, unisci la richiesta di pull. In caso contrario, chiedi all'amministratore di unirli.

   Config Sync sincronizza le modifiche che arrivano nel ramo di produzione del repository acm-gke-infrastructure-repo con i cluster GKE di produzione che comportano la creazione di una zona di destinazione per l'applicazione sui cluster GKE di produzione.

Promuovi le modifiche da sviluppo a 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 all'ambiente di gestione temporanea.

1. 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
     

2. 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
    

3. 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 il completamento dell'operazione.

4. Verifica che il deployment gestione temporanea sia stato eseguito correttamente:

   1. Recupera le credenziali al cluster di gestione temporanea:

      gcloud container clusters get-credentials gke-staging-us-central1 --zone us-central1-a
      

   2. 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
      

   3. 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!
      

   4. In Cloud Shell, premi CTRL+C per terminare il port forwarding.

Promuovi 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, rispettivamente denominati prod1 e prod2.

1. 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
    

2. Le release nei cluster di produzione richiedono l'approvazione, quindi l'implementazione attende fino a quando non la approvi. Per visualizzarla:

   Vai alla pagina della pipeline di Cloud Deploy

   Fai clic su sample pipeline. L'implementazione in prod1 richiede l'approvazione e il ruolo clouddeploy.approver è necessario per l'approvazione. Dato che sei il proprietario del progetto, puoi accedere per approvare la release.

3. Approva la release in 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 l'uscita:

    gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet
    

4. Dopo aver ricevuto l'approvazione, inizia la release prod1. Monitora l'avanzamento nella pagina della pipeline di Cloud Deploy.

5. Una volta completato il deployment di prod1, avvia la release di prod2.

    gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=prod2 --quiet
    

6. La release in prod2 richiede anche 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 l'uscita:

    gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet
    

   Nota: Cloud Deploy consente di eseguire deployment paralleli in più cluster GKE in modo da poter eseguire il deployment su più cluster di produzione contemporaneamente. Per maggiori dettagli, consulta Deployment parallelo con Cloud Deploy.

7. Dopo aver ricevuto l'approvazione, inizia la release prod2. Monitora l'avanzamento nella pagina della pipeline di Cloud Deploy.

8. Verifica che il deployment nel cluster di produzione sia andato a buon fine dopo il completamento delle pipeline di Cloud Deploy in prod1 e prod2.

   1. Viene creato un Ingress multi-cluster nei cluster di produzione e utilizzi un bilanciatore del carico per accedere all'applicazione di produzione. Queste configurazioni di 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.

   2. Elenca la regola di forwarding associata al bilanciatore del carico per trovare l'indirizzo IP.

      gcloud compute forwarding-rules list
      

   3. 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
      

   4. Apri un browser web e inserisci il seguente URL 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 il deployment dell'applicazione viene 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 nodi dei due cluster GKE di produzione senza influire sull'applicazione.

L'applicazione in produzione utilizza Ingress multi-cluster ed è accessibile tramite l'IP di un bilanciatore del carico. Quando si accede all'applicazione tramite questo IP, Ingress multi-cluster la instrada a una delle due istanze dell'applicazione in esecuzione su due diversi cluster GKE. Se uno dei cluster GKE non è integro e non è possibile raggiungere l'istanza dell'applicazione in esecuzione su di esso, il traffico in entrata multi-cluster continua a inviare il traffico all'istanza in stato integro dell'applicazione in esecuzione sull'altro cluster GKE. Ciò rende l'interruzione del cluster invisibile all'utente finale e l'applicazione gestisce continuamente le richieste.

Per testare la resilienza:

1. 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  ""}'
   

2. 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 riporta 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.

3. 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.

4. Controlla lo stato del gruppo di istanze.

   Vai alla pagina Gruppi di istanze

   È in corso il riavvio dei due gruppi di istanze, mentre gli altri gruppi presentano un segno di spunta verde.

   

5. Apri un browser web e inserisci il seguente URL 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 dal fabbrica dell'applicazione, hai ottenuto repository Git, pipeline di infrastruttura e 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 con la pipeline senza dover aggiornare il data di fabbrica dell'applicazione. Puoi personalizzare le pipeline dell'applicazione e i repository Git 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

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:
• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.
1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

   Vai a 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 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 monitoraggio e logging ibridi e multi-cloud.
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.