Sviluppa ed esegui il deployment di app containerizzate utilizzando una pipeline CI/CD

Last reviewed 2022-11-18 UTC

Questa guida al deployment descrive come configurare e utilizzare un sistema di sviluppo, integrazione continua (CI) e distribuzione continua (CD) utilizzando un set integrato di strumenti Google Cloud. Puoi utilizzare questo sistema per sviluppare ed eseguire il deployment di applicazioni in Google Kubernetes Engine (GKE).

Questa guida mostra come creare l'architettura descritta in pipeline di deployment per lo sviluppo e la distribuzione di app containerizzate.

Questa guida al deployment è destinata sia agli sviluppatori che agli operatori di software e durante il completamento devi svolgere i seguenti ruoli:

  • Innanzitutto, devi agire da operatore per configurare la pipeline CI/CD. I componenti principali di questa pipeline sono Cloud Build, Artifact Registry e Cloud Deploy.
  • Successivamente, agisci come sviluppatore per modificare un'applicazione utilizzando Cloud Code. Quando agisci in qualità di sviluppatore, vedi l'esperienza integrata offerta da questa pipeline.
  • Infine, avrai il ruolo di operatore e seguirai i passaggi per eseguire il deployment di un'applicazione in produzione.

Questa guida al deployment presuppone che tu conosca l'esecuzione dei comandi gcloud su Google Cloud e il deployment dei container di applicazioni in GKE.

Architettura

Il seguente diagramma mostra le risorse utilizzate in questa guida al deployment:

Sviluppa ed esegui il deployment del sistema con Cloud Code, Cloud Build, Artifact Registry, Cloud Deploy e GKE

Per maggiori dettagli sui componenti utilizzati in questa architettura, consulta pipeline di deployment per lo sviluppo e la distribuzione di app containerizzate.

Obiettivi

In qualità di operatore:

  • Configura la pipeline CI e la pipeline CD. Questa configurazione include quanto segue:
    • Configura le autorizzazioni richieste.
    • Creare i cluster GKE per gli ambienti di gestione temporanea e produzione.
    • Crea un repository in Cloud Source Repositories per il codice sorgente.
    • Crea un repository in Artifact Registry per il container dell'applicazione.
    • Crea un trigger di Cloud Build nel repository GitHub principale.
    • Crea una pipeline di distribuzione di Cloud Deploy e le destinazioni. I target sono l'ambiente di gestione temporanea e produzione.
  • Avvia il processo CI/CD per eseguire il deployment nella gestione temporanea e poi promuoverlo in produzione.

In qualità di sviluppatore, apporti una modifica all'applicazione. Per farlo:

  • Clonare il repository in modo che funzioni con un ambiente di sviluppo preconfigurato.
  • Apporta una modifica all'applicazione nell'area di lavoro di sviluppo.
  • Crea e testa la modifica. I test includono un test di convalida per la governance.
  • Visualizza e convalida la modifica in un cluster di sviluppo. Questo cluster viene eseguito su minikube.
  • Esegui il commit della modifica nel repository principale.

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono essere idonei a una prova senza costi aggiuntivi.

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

  1. Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

  2. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  3. Abilita le API Artifact Registry, Cloud Build, Cloud Deploy, Cloud Source Repositories, Google Kubernetes Engine, Resource Manager, and Service Networking.

    Abilita le API

  4. Nella console Google Cloud, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.

prepara l'ambiente

In questa sezione agisci come operatore dell'applicazione e procedi nel seguente modo:

  • Configura le autorizzazioni richieste.
  • Creare i cluster GKE per gli ambienti di gestione temporanea e produzione.
  • Clonare il repository del codice sorgente.
  • Crea un repository in Cloud Source Repositories per il codice sorgente.
  • Crea un repository in Artifact Registry per l'applicazione container.

Configurare le autorizzazioni

In questa sezione, concederai le autorizzazioni necessarie per configurare la pipeline CI/CD.

  1. Se utilizzi una nuova istanza dell'editor di Cloud Shell, specifica il progetto da utilizzare per questa guida al deployment:

    gcloud config set project PROJECT_ID
    

    Sostituisci PROJECT_ID con l'ID del progetto selezionato o creato per questa guida al deployment.

    Se viene visualizzata una finestra di dialogo, fai clic su Autorizza.

  2. Assicurati che l'account di servizio Compute Engine predefinito disponga di autorizzazioni sufficienti per eseguire job in Cloud Deploy e per eseguire il pull dei container da Artifact Registry. Cloud Build e Cloud Deploy utilizzano questo account di servizio predefinito.

    Questo account di servizio potrebbe già disporre delle autorizzazioni necessarie. Questo passaggio garantisce che vengano concesse le autorizzazioni necessarie ai progetti che disabilitano le concessioni automatiche di ruoli per gli account di servizio predefiniti.

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
        --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
        --role="roles/clouddeploy.jobRunner"
    
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
        --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
        --role="roles/artifactregistry.reader"
    
  3. Concedi il privilegio dell'account di servizio Cloud Build per richiamare i deployment con Cloud Deploy e per aggiornare la pipeline di distribuzione e le definizioni di destinazione:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
        --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \
        --role="roles/clouddeploy.operator"
    

    Per ulteriori informazioni su questo ruolo IAM, consulta il ruolo clouddeploy.operator.

  4. Concedi il privilegio per gli account di servizio Cloud Build e Cloud Deploy per eseguire il deployment in GKE:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
        --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
        --role="roles/container.admin"
    

    Per ulteriori dettagli su questo ruolo IAM, consulta il ruolo del ruolo container.admin.

  5. Concedi all'account di servizio Cloud Build le autorizzazioni necessarie per richiamare le operazioni di Cloud Deploy:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
        --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \
        --role="roles/iam.serviceAccountUser"
    

    Quando Cloud Build richiama Cloud Deploy, utilizza un account di servizio Compute Engine per creare una release, motivo per cui questa autorizzazione è necessaria.

    Per ulteriori dettagli su questo ruolo IAM, consulta il ruolo iam.serviceAccountUser.

Ora hai concesso le autorizzazioni necessarie per la pipeline CI/CD.

Crea i cluster GKE

In questa sezione creerai gli ambienti di gestione temporanea e produzione, che sono entrambi cluster GKE. Non è necessario configurare il cluster di sviluppo qui, perché utilizza minikube.

  1. Crea i cluster GKE di gestione temporanea e produzione:

    gcloud container clusters create-auto staging \
        --region us-central1 \
        --project=$(gcloud config get-value project) \
        --async
    
    gcloud container clusters create-auto prod \
        --region us-central1 \
        --project=$(gcloud config get-value project) \
        --async
    

    Il cluster gestione temporanea è il luogo in cui testi le modifiche al codice. Dopo aver verificato che il deployment nella gestione temporanea non abbia influito negativamente sull'applicazione, esegui il deployment in produzione.

  2. Esegui questo comando e assicurati che l'output abbia STATUS: RUNNING per i cluster di gestione temporanea e produzione:

    gcloud container clusters list
    
  3. Recupera le credenziali per i tuoi file kubeconfig per i cluster di gestione temporanea e produzione.

    gcloud container clusters get-credentials staging --region us-central1
    
    gcloud container clusters get-credentials prod --region us-central1
    

    Puoi utilizzare queste credenziali per interagire con i cluster GKE, ad esempio per verificare che un'applicazione funzioni correttamente.

Hai creato i cluster GKE per l'ambiente di gestione temporanea e produzione.

Apri l'IDE e clona il repository

Per clonare il repository e visualizzare l'applicazione nel tuo ambiente di sviluppo:

  1. Clona il repository GitHub in Cloud Shell.

    Apri in Cloud Shell

  2. Fai clic su Conferma.

    L'editor di Cloud Shell apre e clona il repository di esempio.

    Ora puoi visualizzare il codice dell'applicazione nell'editor di Cloud Shell.

  3. Specifica il progetto da utilizzare per questa guida al deployment:

    gcloud config set project PROJECT_ID
    

    Se viene visualizzata una finestra di dialogo, fai clic su Autorizza.

Ora disponi del codice sorgente per l'applicazione nel tuo ambiente di sviluppo.

Questo repository di codice sorgente include i file di Cloud Build e Cloud Deploy necessari per la pipeline CI/CD.

Crea repository per il codice sorgente e per i container

In questa sezione configurerai un repository in Cloud Source Repositories per il codice sorgente e un repository in Artifact Registry per archiviare i container creati dalla pipeline CI/CD.

  1. Crea un repository in Cloud Source Repositories per archiviare il codice sorgente e collegarlo al processo CI/CD:

    gcloud source repos create cicd-sample
    
  2. Assicurati che le configurazioni di Cloud Deploy abbiano come target il progetto corretto:

    sed -i s/project-id-placeholder/$(gcloud config get-value project)/g deploy/*
    git config --global credential.https://source.developers.google.com.helper gcloud.sh
    git remote add google https://source.developers.google.com/p/$(gcloud config get-value project)/r/cicd-sample
    
  3. Esegui il push del codice sorgente al repository:

    git push --all google
    
  4. Crea un repository di immagini in Artifact Registry:

    gcloud artifacts repositories create cicd-sample-repo \
        --repository-format=Docker \
        --location us-central1
    

Ora hai un repository per il codice sorgente in Cloud Source Repositories e uno per il container dell'applicazione in Artifact Registry. Il repository Cloud Source Repositories consente di clonare il codice sorgente e connetterlo alla pipeline CI/CD.

Configura la pipeline CI/CD

In questa sezione fungerai da operatore dell'applicazione e configurerai la pipeline CI/CD. La pipeline usa Cloud Build per CI e Cloud Deploy per CD. I passaggi della pipeline sono definiti nel trigger di Cloud Build.

  1. Crea un bucket Cloud Storage per Cloud Build per archiviare il file artifacts.json (che tiene traccia degli artefatti generati da Skaffold per ogni build):

    gsutil mb gs://$(gcloud config get-value project)-gceme-artifacts/
    

    Archiviare in una posizione centrale il file artifacts.json di ogni build è una buona pratica perché offre tracciabilità, il che semplifica la risoluzione dei problemi.

  2. Esamina il file cloudbuild.yaml, che definisce il trigger di Cloud Build ed è già configurato nel repository di codice sorgente che hai clonato.

    Questo file definisce il trigger richiamato ogni volta che viene eseguito un nuovo push al ramo principale del repository del codice sorgente.

    I seguenti passaggi per la pipeline CI/CD sono definiti nel file cloudbuild.yaml:

    • Cloud Build usa Skaffold per creare il container di applicazioni.

    • Cloud Build inserisce il file artifacts.json della build nel bucket Cloud Storage.

    • Cloud Build inserisce il container dell'applicazione in Artifact Registry.

    • Cloud Build esegue test sul container dell'applicazione.

    • Il comando gcloud deploy apply registra i seguenti file con il servizio Cloud Deploy:

      • deploy/pipeline.yaml, che è la pipeline di distribuzione
      • deploy/staging.yaml e deploy/prod.yaml, che sono i file di destinazione

      Quando i file sono registrati, Cloud Deploy crea la pipeline e i target se non esistono ancora oppure li ricrea se la configurazione è cambiata. I target sono gli ambienti di gestione temporanea e di produzione.

    • Cloud Deploy crea una nuova release per la pipeline di distribuzione.

      Questa release fa riferimento al container dell'applicazione che è stato creato e testato nel processo CI.

    • Cloud Deploy esegue il deployment della release nell'ambiente di gestione temporanea.

    La pipeline di distribuzione e le destinazioni sono gestite da Cloud Deploy e sono disaccoppiate dal codice sorgente. Questo disaccoppiamento significa che non è necessario aggiornare la pipeline di distribuzione e i file di destinazione quando viene apportata una modifica al codice sorgente dell'applicazione.

  3. Crea il trigger di Cloud Build:

    gcloud beta builds triggers create cloud-source-repositories \
        --name="cicd-sample-main" \
        --repo="cicd-sample" \
        --branch-pattern="main" \
        --build-config="cloudbuild.yaml"
    

    Questo trigger indica a Cloud Build di controllare il repository di codice sorgente e di utilizzare il file cloudbuild.yaml per reagire a qualsiasi modifica al repository. Questo trigger viene richiamato ogni volta che viene eseguito un nuovo push al ramo principale.

  4. Vai alla pagina Cloud Build nella console Google Cloud.

    Vai a Cloud Build

    Tieni presente che non esistono build per la tua applicazione.

A questo punto, hai configurato le pipeline CI e CD e hai creato un trigger sul ramo principale del repository.

Apporta una modifica alla tua applicazione nell'area di lavoro per sviluppatori

In questa sezione avrai il ruolo di sviluppatore dell'applicazione.

Durante lo sviluppo dell'applicazione, apporti e verifichi le modifiche iterative utilizzando Cloud Code come area di lavoro di sviluppo:

  • Apporta una modifica all'applicazione.
  • Creare e testare il nuovo codice.
  • Esegui il deployment dell'applicazione nel cluster minikube e verifica le modifiche rivolte agli utenti.
  • Invia la modifica al repository principale.

Quando viene eseguito il commit di questa modifica nel repository principale, il trigger di Cloud Build avvia la pipeline CI/CD.

Crea, testa ed esegui l'applicazione

In questa sezione imparerai a creare, testare, eseguire il deployment e accedere alla tua applicazione.

Utilizza la stessa istanza dell'editor di Cloud Shell che hai utilizzato nella sezione precedente. Se hai chiuso l'editor, nel browser apri l'editor di Cloud Shell andando su ide.cloud.google.com.

  1. Nel terminale, avvia minikube:

    minikube start
    

    minikube configura un cluster Kubernetes locale in Cloud Shell. L'esecuzione di questa configurazione richiede alcuni minuti. Una volta completato, il processo minikube viene eseguito in background sull'istanza Cloud Shell.

  2. Nel riquadro nella parte inferiore dell'editor di Cloud Shell, seleziona Cloud Code.

  3. Nel riquadro sottile visualizzato tra il terminale e l'editor, seleziona Esegui su Kubernetes.

    Se viene visualizzato il messaggio Use current context (minikube) to run the app?, fai clic su .

    Questo comando crea il codice sorgente ed esegue i test. Questa operazione può richiedere alcuni minuti. I test includono test delle unità e un passaggio di convalida preconfigurato per controllare le regole impostate per l'ambiente di deployment. In questo modo riceverai un avviso in caso di problemi di deployment, anche mentre stai ancora lavorando nel tuo ambiente di sviluppo.

    La scheda Output mostra l'avanzamento di Skaffold durante la creazione e il deployment della tua applicazione.

    Tieni aperta la scheda in tutta la sezione.

    Al termine della build e dei test, la scheda Output indica Update succeeded e mostra due URL.

    Durante la creazione e il test della tua app, Cloud Code trasmette in streaming i log e gli URL nella scheda Output. Man mano che apporti modifiche ed esegui test nel tuo ambiente di sviluppo, puoi vedere la versione dell'app dell'ambiente di sviluppo e verificare che funzioni correttamente.

    L'output riporta anche Watching for changes..., il che significa che la modalità orologio è attivata. Mentre Cloud Code è in modalità di controllo, il servizio rileva eventuali modifiche salvate nel repository e ricrea e esegue automaticamente il deployment dell'app con le modifiche più recenti.

  4. Nel terminale Cloud Code, tieni il puntatore sul primo URL nell'output (http://localhost:8080).

  5. Nella descrizione comando visualizzata, seleziona Apri anteprima web.

    In background, Cloud Code esegue automaticamente il port forwarding del traffico al servizio cicd-sample in esecuzione su minikube.

  6. Aggiorna la pagina nel browser.

    Il numero accanto a Contatore aumenta, a indicare che l'app risponde all'aggiornamento.

    Nel browser, tieni aperta questa pagina in modo da poter visualizzare l'applicazione mentre apporti eventuali modifiche nel tuo ambiente locale.

A questo punto hai creato e testato la tua applicazione nell'ambiente di sviluppo. Hai eseguito il deployment dell'applicazione nel cluster di sviluppo in esecuzione su minikube e hai visualizzato il comportamento dell'applicazione rivolto agli utenti.

apporta una modifica

In questa sezione modificherai l'applicazione e visualizzerai la modifica durante l'esecuzione dell'app nel cluster di sviluppo.

  1. Nell'editor di Cloud Shell, apri il file index.html.

  2. Cerca la stringa Sample App Info e modificala in sample app info, in modo che il titolo ora utilizzi lettere minuscole.

    Il file viene salvato automaticamente, attivando una nuova creazione del container dell'applicazione.

    Cloud Code rileva la modifica ed esegue di nuovo il deployment automaticamente. La scheda Output mostra Update initiated. L'esecuzione di questo nuovo deployment richiede alcuni minuti.

    Questa funzionalità di riesecuzione automatica del deployment è disponibile per qualsiasi applicazione in esecuzione su un cluster Kubernetes.

  3. Al termine della build, vai al browser con l'app aperta e aggiorna la pagina.

    Quando aggiorni la pagina, vedrai che il testo ora utilizza lettere minuscole.

Questa configurazione consente il ricaricamento automatico di qualsiasi architettura, con qualsiasi componente. Quando utilizzi Cloud Code e minikube, tutto ciò che è in esecuzione in Kubernetes ha questa funzionalità di ricaricamento del codice caldo.

Puoi eseguire il debug delle applicazioni di cui è stato eseguito il deployment in un cluster Kubernetes in Cloud Code. Questi passaggi non sono trattati in questa guida al deployment, ma per maggiori dettagli consulta Eseguire il debug di un'applicazione Kubernetes.

Esegui il commit del codice

Ora che hai apportato una modifica all'applicazione, puoi eseguire il commit del codice.

  1. Configura la tua identità Git:

    git config --global user.email "YOU@EXAMPLE.COM"
    git config --global user.name "NAME"
    

    Sostituisci quanto segue:

    • YOU@EXAMPLE.COM: l'indirizzo email collegato al tuo account GitHub.
    • NAME: il nome collegato al tuo account GitHub.
  2. Dal terminale, esegui il commit del codice:

    git add .
    git commit -m "use lowercase for: sample app info"
    

    Non è necessario eseguire il comando git push qui. Ma succede dopo.

Lavorando nell'ambiente di sviluppo, hai apportato una modifica all'applicazione, creato e testato la modifica e verificato il comportamento di queste modifiche rivolto agli utenti. I test nell'ambiente di sviluppo includono controlli di governance, che consentono di risolvere i problemi che causano problemi nell'ambiente di produzione.

In questa guida al deployment, quando esegui il commit del codice nel repository principale, non devi eseguire una revisione del codice. Tuttavia, la revisione del codice o l'approvazione delle modifiche sono consigliati per lo sviluppo del software.

Per ulteriori informazioni sulle best practice per l'approvazione delle modifiche, consulta la sezione Semplificare l'approvazione delle modifiche.

Esegui il deployment di una modifica in produzione

In questa sezione agisci come operatore dell'applicazione e procedi nel seguente modo:

  • Attiva la pipeline CI/CD, che esegue il deployment della release nell'ambiente di gestione temporanea.
  • Promuovi e approva la release di produzione.

Avvia la pipeline CI/CD ed esegui il deployment nella gestione temporanea

In questa sezione, avvierai la pipeline CI/CD richiamando il trigger di Cloud Build. Questo trigger viene richiamato ogni volta che viene eseguito il commit di una modifica nel repository principale. Puoi anche avviare il sistema CI con un trigger manuale.

  1. Nell'editor di Cloud Shell, esegui questo comando per attivare una build:

    git push google
    

    Questa build include la modifica che hai apportato a cicd-sample.

  2. Torna alla dashboard di Cloud Build e controlla che è stata creata una build.

  3. Fai clic su Running: cicd-sample - cicd-sample-main nel log della build a destra e cerca il testo blu che indica l'inizio e la fine di ogni passaggio.

    Il passaggio 0 mostra l'output delle istruzioni skaffold build e skaffold test dal file cloudbuild.yaml. Le attività di build e test nel Passaggio 0 (la parte CI della pipeline) sono state superate, quindi ora vengono eseguite le attività di deployment del Passaggio 1 (la parte CD della pipeline).

    Questo passaggio termina con il seguente messaggio:

    Created Cloud Deploy rollout ROLLOUT_NAME in target staging

  4. Apri la pagina Pipeline di distribuzione di Cloud Deploy e fai clic sulla pipeline cicd-sample delivery.

    Il deployment dell'applicazione viene eseguito in modalità temporanea, ma non in produzione.

  5. Verifica che l'applicazione funzioni correttamente nella gestione temporanea:

    kubectl proxy --port 8001 --context gke_$(gcloud config get-value project)_us-central1_staging
    

    Questo comando configura un proxy kubectl per accedere all'applicazione.

  6. Accedi all'applicazione da Cloud Shell:

    1. Nell'editor di Cloud Shell, apri una nuova scheda Terminale.

    2. Invia una richiesta a localhost per incrementare un contatore:

      curl -s http://localhost:8001/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter
      

      Puoi eseguire questo comando più volte e osservare l'incremento del valore del contatore ogni volta.

      Quando visualizzi l'app, nota che il testo che hai modificato è quello della versione dell'applicazione di cui hai eseguito il deployment in fase di gestione temporanea.

    3. Chiudi questa seconda scheda.

    4. Nella prima scheda, premi Control+C per arrestare il proxy.

Hai richiamato il trigger di Cloud Build per avviare il processo CI, che include la creazione dell'applicazione, il deployment dell'applicazione nell'ambiente di gestione temporanea e l'esecuzione di test per verificare che l'applicazione funzioni in gestione temporanea.

Il processo CI ha esito positivo quando le build del codice e i test vengono superati nell'ambiente di gestione temporanea. Il successo del processo CI avvia quindi il sistema CD in Cloud Deploy.

Promuovi la release in produzione

In questa sezione promuovi la release dalla gestione temporanea alla produzione. Il target di produzione è preconfigurato per richiedere l'approvazione, quindi lo puoi approvare manualmente.

Per la tua pipeline CI/CD, ti consigliamo di utilizzare una strategia di deployment che avvii il deployment gradualmente prima di metterlo in produzione. Il lancio graduale del deployment può facilitare il rilevamento dei problemi e, se necessario, il ripristino di una release precedente.

Per promuovere la release in produzione:

  1. Apri la panoramica delle pipeline di distribuzione di Cloud Deploy e seleziona la pipeline cicd-sample.

  2. Promuovi il deployment dalla gestione temporanea alla produzione. Per farlo:

    1. Nel diagramma della pipeline nella parte superiore della pagina, fai clic sul pulsante blu Promuovi nella casella temporanea.

    2. Nella finestra che si apre, fai clic sul pulsante Promuovi in basso.

    Il deployment non è ancora in esecuzione in produzione. È in attesa dell'approvazione manuale richiesta.

  3. Approva manualmente il deployment:

    1. Nella visualizzazione della pipeline, fai clic sul pulsante Rivedi tra le caselle di gestione temporanea e produzione.

    2. Nella finestra che si apre, fai clic sul pulsante Rivedi.

    3. Nella finestra successiva, fai clic su Approva.

    4. Torna alla panoramica delle pipeline di distribuzione di Cloud Deploy e seleziona la pipeline cicd-sample.

  4. Dopo che la visualizzazione della pipeline mostra la casella di produzione in verde (che indica un'implementazione riuscita), verifica che l'applicazione funzioni in produzione configurando un proxy kubectl che utilizzi per accedere all'applicazione:

    kubectl proxy --port 8002 --context gke_$(gcloud config get-value project)_us-central1_prod
    
  5. Accedi all'applicazione da Cloud Shell:

    1. Nell'editor di Cloud Shell, apri una nuova scheda Terminale.

    2. Incrementa il contatore:

      curl -s http://localhost:8002/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter
      

      Puoi eseguire questo comando più volte e osservare l'incremento del valore del contatore ogni volta.

    3. Chiudi questa seconda scheda del terminale.

    4. Nella prima scheda, premi Control+C per arrestare il proxy.

Ora hai promosso e approvato il deployment in produzione. L'applicazione con la modifica recente è ora in esecuzione in produzione.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questa guida al deployment, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Opzione 1: elimina il 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.

Opzione 2: elimina le singole risorse

  1. Elimina la pipeline di Cloud Deploy:

    gcloud deploy delivery-pipelines delete cicd-sample --region=us-central1 --force
    
  2. Elimina il trigger di Cloud Build:

    gcloud beta builds triggers delete cicd-sample-main
    
  3. Elimina i cluster di gestione temporanea e produzione:

    gcloud container clusters delete staging
    
    gcloud container clusters delete prod
    
  4. Elimina il repository in Cloud Source Repositories:

    gcloud source repos delete cicd-sample
    
  5. Elimina i bucket Cloud Storage:

    `gsutil rm -r gs://$(gcloud config get-value project)-gceme-artifacts/
    
     gsutil rm -r gs://$(gcloud config get-value project)_clouddeploy/
     ```
    
  6. Elimina il repository in Artifact Registry:

    gcloud artifacts repositories delete cicd-sample-repo \
        --location us-central1
    

Passaggi successivi