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

Eseguire l'onboarding di una nuova applicazione

L'architettura di riferimento contiene una fabbrica di applicazioni. Questa factory è 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 di applicazioni per eseguire l'onboarding di una nuova applicazione dai repository di base. L'onboarding dell'applicazione prevede i seguenti passaggi:

1. Crea la definizione dell'applicazione: crea la definizione dell'applicazione in un file Terraform e la memorizzi 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 dell'applicazione è costituita da:

   1. Una landing zone per la nuova applicazione include la definizione dello spazio dei nomi, account di servizio e delle norme 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. Questa operazione viene eseguita per sbloccare gli sviluppatori in modo che possano utilizzare l'ambiente di sviluppo e iniziare a iterare. La landing zone nei cluster di staging e produzione viene creata con l'approccio GitOps. Questo approccio viene illustrato più avanti in questo documento, quando è il momento di promuovere la release in questi cluster.

   2. Il repository dell'infrastruttura del repository di avvio 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 prende il codice nel repository dell'infrastruttura e crea le risorse in base alla loro definizione.

   4. Un repository dell'applicazione dal repository di avvio dell'applicazione che ospita il codice sorgente dell'applicazione.

3. Crea le risorse CI/CD dell'applicazione: utilizzi l'infrastruttura dell'applicazione per creare le 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.

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

   Vai alla pagina Cloud Build

2. Fai clic su Attivatore create-app.

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 sull'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 dal trigger.

   • "app": "sample" specifica il nome dell'applicazione.

   • "runtime": "python" indica alla fabbrica 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 di GitHub che verrà associato ai repository creati per l'applicazione. Poiché non hai ancora creato un team GitHub, trasmettilo come stringa vuota.

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

   Vai alla pagina Cronologia di Cloud Build.

   È disponibile una nuova pipeline per il trigger create-app. 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 su 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 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 l'attivatore tf-apply per creare l'infrastruttura dell'applicazione.

1. Nella console Google Cloud :

   Vai alla pagina Cloud Build .

   Fai clic sul trigger tf-apply.

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

3. Richiama il trigger:

   curl "WEBHOOK_URL" -d '{}'

   Nell'esempio di codice precedente:

   • Sostituisci WEBHOOK_URL con l'URL ottenuto dal trigger.

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

   Vai alla pagina Cronologia di Cloud Build.

   È disponibile una nuova pipeline per il trigger tf-apply. Attendi il completamento.

Questo trigger crea l'infrastruttura dell'applicazione.

Esamina l'infrastruttura dell'applicazione:

Esamina 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, sample.

   kubectl get namespaces sample
   

   L'output è simile al seguente:

   NAME     STATUS   AGE
   sample   Active   15m
   

4. Controlla il account di servizio nello spazio dei nomi.

   kubectl get serviceaccounts -n sample
   

   Oltre a quello predefinito, è presente un account di servizio. L'output è simile al seguente:

   NAME         SECRETS   AGE
   default      0         15m
   sample-ksa   0         15m
   

Repository dell'infrastruttura

In un browser web, vai su 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 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 gli altri rami hanno regole di protezione, quindi non puoi eseguire il push del codice direttamente in questi rami. Per eseguire il push del 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 :

  Vai alla pagina Cloud Build

  È presente 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, identifichi il ramo in cui è stato eseguito il push, acceda alla cartella corrispondente in quel ramo ed esegua Terraform. Ad esempio, se il codice viene inviato al ramo cicd-trigger, il trigger esegue Terraform nella cartella cicd-trigger del ramo cicd-trigger. Allo stesso modo, quando viene eseguito un push sul ramo dev, il trigger esegue Terraform sulla 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 container nelle configurazioni Dockerfile e kustomize che descrivono le configurazioni necessarie dell'applicazione e skaffold.yaml che definisce i passaggi di deployment da utilizzare da Cloud Deploy per la CD.

Crea risorse CI/CD per le applicazioni

Ora che hai creato lo scheletro dell'applicazione, esegui il trigger deploy-infra-sample per creare le risorse CI/CD. Puoi richiamare il trigger manualmente utilizzando il relativo URL webhook o eseguendo un commit nel repository Git sample-infra.

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

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

      Viene eseguito il check-out del branch predefinito cicd-trigger.

   3. Aggiungi una nuova riga al file env/cicd-trigger/main.tf, esegui il commit della modifica e 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 vengono inviate le modifiche, viene avviato il trigger Cloud Deploy deploy-infra-sample.

2. Monitora lo stato del trigger:

   Vai alla pagina della cronologia di Cloud Build per visualizzare la pipeline e attendi il 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. È collegato al repository del codice dell'applicazione sample. Il trigger viene richiamato quando viene eseguito il push nel repository dell'applicazione ed esegue i passaggi di build come 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.

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

Il trigger deploy-app-sample è connesso al repository dell'applicazione denominato sample. Puoi richiamare il trigger manualmente, utilizzando l'URL webhook, o tramite un push al repository dell'applicazione.

1. Aggiungi una nuova riga in un file nel repository sample ed esegui il push delle modifiche per richiamare il trigger 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 organizzazione 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 vengono inviate le modifiche, viene avviato il trigger Cloud Deploy deploy-app-sample.

2. Monitora lo stato del trigger:

   Vai alla pagina della cronologia di Cloud Build per visualizzare la pipeline e attendi il 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 di sviluppo:

   Vai alla pagina della pipeline Cloud Deploy.

   Fai clic sulla pipeline sample. È stato avviato il deployment nel cluster GKE di sviluppo. Attendi il completamento.

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

1. Recupera le credenziali per il cluster di sviluppo.

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

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

3. Nella barra degli strumenti di Cloud Shell, fai clic su

   preview Anteprima web, poi 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.

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 iterarle. In questo tutorial, apporti modifiche al repository del codice dell'applicazione e le esegui il deployment nell'ambiente di sviluppo.

1. In Cloud Shell, cambia directory impostandola sul repository sample 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 il codice viene inviato al repository GitHub, viene attivato il trigger webhook deploy-app-sample.

4. Monitora lo stato del trigger nella pagina della cronologia di Cloud Build e attendi il completamento.

5. Vai alla pagina della pipeline Cloud Deploy

   Fai clic sulla pipeline sample. È stato avviato il deployment nel cluster GKE di sviluppo. Attendi il completamento.

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

1. Recupera le credenziali per il cluster di sviluppo se hai aperto una nuova Cloud Shell:

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

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

3. Nella barra degli strumenti di Cloud Shell, fai clic su

   preview Anteprima web, poi 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.

Promuovere la modifica nei cluster di staging e di produzione

Prima di promuovere l'applicazione negli ambienti di staging e produzione, devi creare la landing zone per l'applicazione nei cluster GKE per questi ambienti. Quando hai eseguito l'onboarding dell'applicazione, la landing zone per lo sviluppo è stata creata automaticamente nel cluster GKE di sviluppo aggiungendo codice a acm-gke-infrastructure-repo nel ramo di sviluppo.

Crea la zona di destinazione nei cluster GKE di gestione temporanea e di produzione

1. Crea la landing zone nel cluster GKE di staging: devi creare una richiesta di pull da dev al ramo di staging in acm-gke-infrastructure-repo e unirla.

   1. Vai su GitHub e passa al repository acm-gke-infrastructure-repo. Fai clic su Pull requests e poi sul pulsante New pull request. Nel menu Base, scegli staging e nel menu Confronta, scegli dev. Fai clic sul pulsante Create pull request.

   2. In genere, una persona che ha accesso al repository esamina le modifiche e poi unisce la richiesta di pull per assicurarsi che solo le modifiche previste vengano promosse nell'ambiente di staging. 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 la richiesta di pull. Se sei un amministratore del repository, unisci la richiesta di pull. In caso contrario, chiedi all'amministratore di unirlo.

   Config Sync sincronizza le modifiche che arrivano nel ramo di staging del repository acm-gke-infrastructure-repo con il cluster GKE di staging, il che comporta la creazione della landing page per l'applicazione nel cluster GKE di staging.

2. Crea la landing zone nei cluster GKE di produzione: devi creare una richiesta di pull dallo staging al ramo di produzione e unirla.

   1. Fai clic su Pull requests e poi sul pulsante New pull request. Nel menu Base, scegli prod e nel menu Confronta, scegli staging. 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 unirlo.

   Config Sync sincronizza le modifiche che arrivano nel ramo di produzione del repository acm-gke-infrastructure-repo con i cluster GKE di produzione, il che comporta la creazione della landing page per l'applicazione sui cluster GKE di produzione.

Promuovere le modifiche dallo sviluppo alla versione temporanea

Ora che hai creato la landing zone per l'applicazione nei cluster GKE di staging e produzione, promuovi l'applicazione dall'ambiente di sviluppo a quello di staging.

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

2. In Cloud Shell, esegui questo 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
    

3. Controlla il deployment di staging:

   Vai alla pagina della pipeline Cloud Deploy

   Fai clic sulla pipeline sample. È stato avviato il deployment nel cluster GKE di staging. Attendi il completamento.

4. Verifica che il deployment di staging sia stato eseguito correttamente:

   1. Recupera le credenziali per il cluster di staging:

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

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

   3. Nella barra degli strumenti di Cloud Shell, fai clic su

      preview Anteprima web, poi 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.

Promuovere le modifiche dalla versione temporanea alla produzione

Ora promuovi la release dalla versione temporanea alla produzione. Hai due cluster di produzione e Cloud Deploy ha una destinazione per ciascuno di essi denominata rispettivamente prod1 e prod2.

1. In Cloud Shell, esegui questo 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
    

2. Il rilascio ai cluster di produzione richiede l'approvazione, quindi l'implementazione attende la tua approvazione. 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. In qualità di proprietario del progetto, hai accesso all'approvazione del rilascio.

3. Approva il rilascio in prod1:

   Esegui questo comando per recuperare il nome del rollout 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
    

4. Una volta concessa l'approvazione, inizia il rilascio di prod1. Monitora l'avanzamento nella pagina della pipeline Cloud Deploy.

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

6. Anche il rilascio in prod2 richiede l'approvazione. Approva il rilascio nel cluster prod2:

   Esegui questo comando per recuperare il nome del rollout 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
    

7. Una volta concessa l'approvazione, inizia il rilascio di prod2. Monitora l'avanzamento nella pagina della pipeline Cloud Deploy.

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

   1. Esiste un ingress multi-cluster creato nei cluster di produzione e utilizzi un bilanciatore del carico per accedere all'applicazione di produzione. Queste configurazioni di Multi Cluster Ingress 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 inoltra la richiesta 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 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!
      

      In questo modo, viene confermato che l'applicazione è implementata come previsto nei cluster di produzione.

Testare la resilienza dell'applicazione

In questa sezione, testa la resilienza dell'applicazione in esecuzione in produzione riavviando uno dei due nodi dei cluster GKE di produzione senza influire sull'applicazione.

L'applicazione in produzione utilizza l'ingresso multi-cluster ed è accessibile tramite un IP del bilanciatore del carico. Quando si accede all'applicazione tramite questo IP, Ingress multi-cluster la indirizza a una delle due istanze dell'applicazione in esecuzione su due cluster GKE diversi. Quando uno dei cluster GKE non è integro e l'istanza dell'applicazione in esecuzione non è raggiungibile, l'ingresso multicluster 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 continua a gestire 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 è 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.

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

   I due gruppi di istanze vengono riavviati, mentre gli altri gruppi hanno un segno di spunta verde.

   

5. 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 è disponibile, l'applicazione è disponibile e l'output è il seguente:

    My new feature!
    

   Ciò dimostra che la tua applicazione è resiliente e a disponibilità elevata.

Gestire l'applicazione

Quando hai creato questa applicazione dalla fabbrica di applicazioni, hai ottenuto repository Git, infrastruttura e pipeline CI/CD separati per l'applicazione. Hai utilizzato queste risorse per eseguire il deployment dell'applicazione e aggiungere una nuova funzionalità. Per gestire ulteriormente l'applicazione, devi interagire solo con questi repository Git e con la pipeline senza dover aggiornare la fabbrica di applicazioni. Puoi personalizzare le pipeline e i repository Git dell'applicazione in base ai tuoi requisiti. In qualità di proprietario dell'applicazione, puoi definire chi ha accesso alle pipeline e ai repository Git della tua applicazione per gestirla.