Utilizzo della Toolchain di GKE Enterprise con Active Assist

---

Questo documento fa parte di una serie che illustra i pattern architetturali che le aziende possono utilizzare per ottimizzare l'impronta del cloud su larga scala utilizzando Active Assist. Il tutorial mostra come creare una pipeline di automazione per i suggerimenti di Active Assist che funzioni con la Toolchain di GKE Enterprise. È destinato alle persone che utilizzano Config Sync per gestire i propri ambienti GKE Enterprise e Config Connector per gestire le risorse Google Cloud. Le altre parti della serie sono le seguenti:

• Pattern per l'utilizzo di Active Assist su larga scala
• Utilizzo di pipeline serverless con Active Assist
• Utilizzo della Toolchain di GKE Enterprise con Active Assist (questo documento)

La pipeline di automazione che crei in questo tutorial può aiutarti a ottenere quanto segue:

• Scalare l'utilizzo del portafoglio Active Assist nella tua organizzazione.
• Integrare Active Assist nella tua pipeline di integrazione continua e distribuzione continua (CI/CD).
• Controllo della revisione e dell'attuazione dei suggerimenti di Active Assist utilizzando costrutti come problemi di GitHub e richieste di pull.

Questo tutorial utilizza anche kpt, un toolkit open source sviluppato da Google per aiutarti a gestire, manipolare, personalizzare e applicare i file di dati di configurazione delle risorse Kubernetes.

Architettura

Il seguente diagramma dell'architettura mostra i componenti utilizzati in questo tutorial.

I componenti vengono utilizzati nei seguenti modi:

• Un repository GitHub non si ripete (DRY), utilizzato per i modelli di Config Connector di cui esegui il deployment nei progetti nella tua organizzazione Google Cloud.
• Uno o più repository GitHub specifici per un progetto o ambiente e contengono file di configurazione idratati. Questi repository idratati sono destinati agli ambienti gestiti da Config Sync. Utilizzano Config Connector per azionare e gestire le risorse Google Cloud nell'organizzazione Google Cloud.
• Un cluster GKE che utilizza Config Sync per il controllo della versione e il rilevamento di deviazioni. In questo cluster è installato anche Config Connector. Config Connector consente al cluster di gestire le risorse Google Cloud nell'organizzazione Google Cloud.
• Un trigger di Cloud Build che attiva una build quando viene eseguito il push di un modello al repository DRY di GitHub.
• Un trigger di Cloud Build pianificato che attiva periodicamente una build. Il job di compilazione utilizza una funzione kpt. La funzione richiama le API Active Assist Recommender per recuperare i suggerimenti attivi. Esamina e analizza i suggerimenti per determinare se le risorse di Google Cloud gestite da Config Connector devono essere ridimensionate o ottimizzate. La funzione kpt crea un problema GitHub nel repository DRY con i dettagli della modifica consigliata se le risorse Google Cloud gestite da Config Connector devono essere ridimensionate o ottimizzate.

Il flusso di lavoro per questa architettura è il seguente:

1. I team autorizzati con accesso al repository DRY creano e gestiscono i modelli di Config Connector nel repository.
2. Un job Cloud Build viene attivato quando un modello viene creato o modificato e controllato nel ramo main.
3. Il job Cloud Build idrata i modelli richiamando kpt setter. Il job esegue il push dei file di configurazione idratati nel repository GitHub idratato. Secret Manager viene utilizzato per archiviare le chiavi di deployment GitHub per il repository privato.
4. Config Sync monitora le modifiche al repository idratato e applica al cluster gestito gli aggiornamenti trovati nel repository.
5. Config Connector monitora le modifiche e attiva le risorse Google Cloud se è necessario creare o aggiornare risorse in seguito alle modifiche al Modello di risorse Kubernetes (KRM) applicate da Config Sync.
6. Un trigger di Cloud Build pianificato viene eseguito periodicamente per richiamare l'API Recommender al fine di recuperare i suggerimenti attivi per i progetti gestiti da Config Connector.
7. Il job Cloud Build pianificato esegue una funzione kpt personalizzata per richiamare l'API Recommender e recuperare e analizzare i suggerimenti attivi.
8. La funzione kpt crea un problema su GitHub che mostra un confronto tra la configurazione attuale della risorsa e quella consigliata per la risorsa. Con questo approccio, i problemi di GitHub vengono creati nel repository DRY, in modo da tenere più facilmente traccia delle modifiche al repository.

Obiettivi

• Crea i seguenti repository GitHub di esempio:
  • Un repository DRY per i KRM di Config Connector.
  • Un repository per contenere file di configurazione idratati generati utilizzando i setter kpt.
• Crea un cluster GKE con Config Sync e Config Connector.
• Crea una funzione kpt di esempio per recuperare i suggerimenti di Active Assist per i progetti gestiti da Config Connector.
• Crea un trigger di Cloud Build che viene attivato quando viene eseguito il push di un modello al ramo main del repository DRY.
• Crea un job Cloud Build pianificato che viene eseguito periodicamente per recuperare i suggerimenti di Active Assist disponibili per le risorse gestite da Config Connector.
• Testa la pipeline end-to-end con i suggerimenti stub forniti nel repository GitHub per questo tutorial.

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

• Cloud Build
• Cloud Run
• Firestore
• Pub/Sub
• Container Registry
• Cloud Scheduler
• Versione Google Kubernetes Engine (GKE) Enterprise

Per generare una stima dei costi basata sull'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

1. In the Google Cloud console, go to the project selector page.

   Go to project selector

2. Select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.
3. Prendi nota dell'ID progetto Google Cloud. Potrai usare questo ID nella sezione successiva quando configuri l'ambiente. Nel tutorial viene fatto riferimento a questo progetto come progetto build.

4. Enable the Cloud Build, Firestore, App Engine, Pub/Sub, Cloud Run, Cloud Scheduler e Cloud Source Repositories APIs.

   Enable the APIs

   Per questo tutorial vengono utilizzate le credenziali dell'applicazione predefinite. Se ti viene chiesto di creare le credenziali nella pagina Aggiungi credenziali al progetto, fai clic su Annulla.

5. Make sure that billing is enabled for your Google Cloud project.

Configurazione dell'ambiente

In questo tutorial eseguirai tutti i comandi in Cloud Shell.

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

2. Imposta le variabili per l'ID e il numero del progetto Google Cloud build attuale:

   export RECO_MGR_PROJECT=PROJECT_ID
   gcloud config set project $RECO_MGR_PROJECT
   export RECO_MGR_PROJECT_NUMBER=$(gcloud projects describe $RECO_MGR_PROJECT --format='value(projectNumber)')
   

   Sostituisci PROJECT_ID con l'ID progetto che hai annotato nella sezione precedente.

3. Imposta le variabili per la regione di deployment:

   export REGION=us-central1
   export ZONE=us-central1-a
   

4. Clona il repository che contiene il codice per l'app di esempio utilizzata in questo tutorial:

   git clone https://github.com/GoogleCloudPlatform/activeassist-anthos-toolchain.git
   

5. Vai alla directory del progetto:

   cd activeassist-anthos-toolchain
   

Crea la pipeline

In questa sezione creerai i componenti per creare la pipeline. I suggerimenti di Active Assist vengono generati in base ai pattern di utilizzo e alle metriche di sistema. Ogni categoria di suggerimenti può utilizzare una diversa finestra di tempo predefinita per analizzare i dati e le metriche sull'utilizzo in base ai suggerimenti generati. Per testare la pipeline end-to-end, il repository che hai clonato in un passaggio precedente fornisce suggerimenti (stub) di esempio che puoi utilizzare per eseguire la pipeline end-to-end.

In alternativa, se esegui la pipeline in un progetto di esempio che dispone di risorse e suggerimenti esistenti, puoi apportare le modifiche appropriate al codice campione ed eseguire la pipeline.

Configura repository GitHub privati di esempio

Nelle sezioni seguenti, configurerai i repository GitHub di esempio per questo tutorial.

Configura un repository GitHub DRY privato

1. Crea un repository GitHub privato per il repository DRY. Prendi nota del nome che assegni al repository.

2. In Cloud Shell, crea una variabile di ambiente per il tuo nome utente GitHub e il nome del repository DRY:

   export REPO_OWNER=YOUR_GITHUB_USERNAME
   export DRY_REPO_NAME=YOUR_PRIVATE_DRY_REPO
   

   Sostituisci quanto segue:

   • YOUR_GITHUB_USERNAME: il tuo nome utente GitHub.
   • YOUR_PRIVATE_DRY_REPO: il nome del repository DRY.

3. Crea un token di accesso personale (PAT) per creare problemi in questo repository. La pipeline crea problemi su GitHub se sono presenti suggerimenti di Active Assist che devono essere esaminati. Per ulteriori informazioni sulla creazione di PAT in GitHub, consulta la documentazione di GitHub.

   Quando imposti un ambito per questo token, seleziona Controllo completo dei repository privati.

4. In Cloud Shell, crea una variabile di ambiente per il PAT generato:

   export GITHUB_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN
   

   Sostituisci YOUR_PERSONAL_ACCESS_TOKEN con il tuo token.

Configura un repository GitHub idratato privato

1. Crea un repository GitHub privato per il repository idratato. Prendi nota del nome che assegni al repository.

2. In Cloud Shell, imposta una variabile di ambiente per il repository idratato:

   export HYDRATED_REPO_NAME=YOUR_PRIVATE_HYDRATED_REPO
   export HYDRATED_REPO='[e-mail]:$REPO_OWNER/$HYDRATED_REPO_NAME.git'
   

   Sostituisci YOUR_PRIVATE_HYDRATED_REPO con il nome del tuo repository idratato.

3. Crea una coppia di chiavi di deployment:

   ssh-keygen -t rsa -b 4096 \
   -C 'active-assist-robot' \
   -N '' \
   -f $(pwd)/active-assist-robot
   

   Una chiave di deployment consente di eseguire il deployment nel repository GitHub privato quando esegui un job Cloud Build per idratare i file di configurazione.

4. Stampa la chiave generata:

   cat $(pwd)/active-assist-robot.pub
   

5. Aggiungi la chiave di deployment al repository GitHub privato. Assicurati di selezionare Consenti accesso in scrittura quando aggiungi la chiave di deployment. Per informazioni su come aggiungere chiavi di deployment ai repository GitHub, consulta la documentazione di GitHub per la gestione delle chiavi di deployment.

Carica chiavi GitHub su Secret Manager

1. In Cloud Shell, crea un secret per archiviare la chiave privata dalla coppia di chiavi di deployment:

   gcloud secrets create github-ssh-key \
     --data-file=$(pwd)/active-assist-robot
   

2. Crea un secret per archiviare il PAT:

   echo $GITHUB_TOKEN | gcloud secrets create github-pat --data-file=-
   

Crea un cluster GKE

In questa sezione creerai un cluster GKE con il componente aggiuntivo Config Connector, creerai un'identità e configurerai Config Connector. Devi anche configurare Config Sync. Puoi utilizzare Config Sync per creare una configurazione comune nell'intera infrastruttura, compresi i criteri personalizzati, e applicarla sia on-premise che nel cloud. Config Sync valuta le modifiche e le applica a tutti i cluster Kubernetes in modo che lo stato desiderato sia sempre rispecchiato nei cluster.

1. In Cloud Shell, crea un nuovo cluster GKE con il componente aggiuntivo Config Connector abilitato:

   gcloud container clusters create sample-ops \
     --machine-type n1-standard-4 \
     --zone $ZONE \
     --release-channel regular \
     --addons ConfigConnector \
     --workload-pool=$RECO_MGR_PROJECT.svc.id.goog \
     --enable-stackdriver-kubernetes \
     --enable-ip-alias
   

2. Completa le seguenti sezioni della guida Installazione con il componente aggiuntivo di GKE per creare un'identità e configurare Config Connector.

   1. Creazione di un'identità
   2. Configurazione di Config Connector

3. Installa Config Sync nel cluster GKE che hai creato. Quando configuri Config Sync, devi:

   1. Utilizza un token per concedere a Git l'accesso di sola lettura a Config Sync. Utilizza il token GitHub che hai creato durante la configurazione di un repository GitHub DRY privato. Il token è disponibile tramite la variabile di ambiente $GITHUB_TOKEN.
   2. Configura Config Sync utilizzando gcloud. Configura le seguenti impostazioni:
      1. sourceFormat: hierarchy
      2. syncRepo: https://github.com/YOUR_GITHUB_USERNAME/YOUR_PRIVATE_HYDRATED_REPO
      3. syncBranch: main
      4. secretType: token
      5. policyDir: non compilare questa opzione

Crea un trigger di Cloud Build per il push al repository idratato

Nelle sezioni seguenti creerai un trigger di Cloud Build che viene attivato quando viene eseguito il push dei modelli al ramo principale del repository YOUR_PRIVATE_DRY_REPO. Questo trigger esegue i passaggi per l'idratazione dei modelli KRM config-as-data nel repository YOUR_PRIVATE_DRY_REPO ed esegue il push dei file di configurazione idratati al tuo repository YOUR_PRIVATE_HYDRATED_REPO.

Connetti Cloud Build ai tuoi repository GitHub

In questa sezione, dovrai connettere i repository GitHub YOUR_PRIVATE_DRY_REPO e YOUR_PRIVATE_HYDRATED_REPO a Cloud Build.

1. Vai alla pagina del marketplace GitHub per l'app Cloud Build.

   Vai alla pagina dell'app Cloud Build

2. Fai clic su Setup with Google Cloud Build (Configura con Google Cloud Build).

3. Se richiesto, accedi a GitHub.

4. Seleziona Seleziona solo i repository.

   Utilizza il menu a discesa Seleziona repository per abilitare l'accesso ai repository YOUR_PRIVATE_DRY_REPO e YOUR_PRIVATE_HYDRATED_REPO tramite l'app Cloud Build.

5. Fai clic su Installa.

6. Accedi a Google Cloud. Viene visualizzata la pagina Autorizzazione e ti viene chiesto di autorizzare l'app Google Cloud Build a connettersi a Google Cloud.

7. Fai clic su Autorizza Google Cloud Build by GoogleCloud Build. Il sistema ti reindirizzerà alla console Google Cloud.

8. Selezionare il tuo progetto Google Cloud.

9. Seleziona la casella di controllo per il consenso e fai clic su Avanti.

10. Fai clic su Installa.

11. Accedi a Google Cloud. Viene visualizzata la pagina Autorizzazione e ti viene chiesto di autorizzare l'app Google Cloud Build a connettersi a Google Cloud.

12. Fai clic su Autorizza Google Cloud Build by GoogleCloud Build. Il sistema ti reindirizzerà alla console Google Cloud.

13. Selezionare il tuo progetto Google Cloud.

14. Seleziona la casella di controllo per il consenso e fai clic su Avanti.

15. Nella pagina Seleziona repository visualizzata, seleziona i seguenti repository GitHub:

    • YOUR_PRIVATE_DRY_REPO
    • YOUR_PRIVATE_HYDRATED_REPO

16. Fai clic su Connetti e poi su Fine.

Crea un trigger di Cloud Build per il repository DRY

1. In Cloud Shell, esegui questo comando:

   envsubst < cloudbuild.template.yaml > cloudbuild.yaml
   

   Il comando genera un file cloudbuild.yaml.

2. Crea l'attivatore:

   gcloud beta builds triggers create github \
     --name ActiveAssistDemo \
     --repo-name=$DRY_REPO_NAME \
     --repo-owner=$REPO_OWNER \
     --branch-pattern="main" \
     --build-config=cloudbuild.yaml
   

3. Concedi all'account di servizio Cloud Build l'autorizzazione ad accedere a Secret Manager:

   gcloud secrets add-iam-policy-binding github-ssh-key  \
     --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
     --role="roles/secretmanager.secretAccessor"
   
   gcloud secrets add-iam-policy-binding github-pat  \
     --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
     --role="roles/secretmanager.secretAccessor"
   

Crea un trigger di Cloud Build pianificato per i suggerimenti di Active Assist

Nota: in questo tutorial utilizzerai gli stub per testare la pipeline. Quando utilizzi la pipeline per i tuoi progetti Google Cloud, assicurati di concedere all'account di servizio Cloud Build le autorizzazioni necessarie per recuperare i suggerimenti di Active Assist.

Nelle sezioni seguenti creerai un trigger di Cloud Build pianificato che viene eseguito periodicamente. Questo trigger recupera i suggerimenti di Active Assist utilizzando una funzione kpt e determina se sono presenti suggerimenti attivi per le risorse nel tuo repository YOUR_PRIVATE_HYDRATED_REPO. La funzione kpt crea anche un problema GitHub nel tuo repository YOUR_PRIVATE_HYDRATED_REPO se sono presenti suggerimenti attivi per la configurazione delle risorse che devono essere esaminati e applicati.

Genera un'immagine Cloud Build

In questa sezione, generi un'immagine di Cloud Build con i componenti kpt, gh e Node.

1. In Cloud Shell, crea un'immagine Docker ed eseguine il push in Container Registry:

   gcloud auth configure-docker
   
   docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function
   
   docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1
   

Crea un trigger di Cloud Build per il tuo repository idratato

1. In Cloud Shell, crea il file di configurazione necessario per impostare il trigger di Cloud Build pianificato:

    envsubst < cloudbuild-scheduled-recommendations.template.yaml > cloudbuild-scheduled-recommendations.yaml
   

2. Crea il trigger di Cloud Build:

   gcloud beta builds triggers create github \
     --name ActiveAssistScheduledRecommendations \
     --repo-name=YOUR_PRIVATE_HYDRATED_REPO \
     --repo-owner=$REPO_OWNER \
     --branch-pattern="main" \
     --build-config=cloudbuild-scheduled-recommendations.yaml
   

3. Ottieni l'ID di questo attivatore:

   export TRIGGER_ID=`gcloud beta builds triggers describe \
     ActiveAssistScheduledRecommendations \
     --format="value(id)"`
   

Crea un job Cloud Scheduler per richiamare il trigger

1. In Cloud Shell, crea un account di servizio:

   gcloud iam service-accounts create build-invoker \
      --description "Service Account used by Cloud Scheduler to invoke the sample scheduled Cloud Build job" \
      --display-name "recommender-scheduler-sa" \
      --project $RECO_MGR_PROJECT
   

   I job Cloud Scheduler utilizzano questo account di servizio per eseguire il servizio recommender-parser.

2. Concedi all'account di servizio le autorizzazioni per richiamare un job Cloud Build:

   gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \
     --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \
     --role roles/cloudbuild.builds.editor \
     --project $RECO_MGR_PROJECT
   
    gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \
      --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \
      --role roles/serviceusage.serviceUsageConsumer \
      --project $RECO_MGR_PROJECT
   

3. Crea un job Cloud Scheduler per richiamare il trigger creato nel passaggio precedente:

   gcloud scheduler jobs create http scheduled-build \
      --project $RECO_MGR_PROJECT \
      --time-zone "America/Los_Angeles" \
      --schedule="0 */3 * * *" \
      --uri="https://cloudbuild.googleapis.com/v1/projects/${RECO_MGR_PROJECT}/triggers/${TRIGGER_ID}:run" \
      --description="Scheduler job to invoke Cloud Build" \
      --oauth-service-account-email="build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com" \
      --headers="Content-Type=application/json" \
      --http-method="POST" \
   

   Seleziona Y se viene visualizzato il seguente messaggio:

   There is no App Engine app in the project.

   Se ti viene chiesto di scegliere la regione in cui vuoi collocare l'applicazione App Engine, seleziona la regione us-central.

Esegui il commit e il push dei file di configurazione di Cloud Build in GitHub

Esegui il push dei due file di configurazione di Cloud Build che hai creato nel tuo repository YOUR_PRIVATE_DRY_REPO:

git remote add dry https://github.com/$REPO_OWNER/$DRY_REPO_NAME.git

git add cloudbuild.yaml
git add cloudbuild-scheduled-recommendations.yaml
git commit -m "Added cloudbuild configuration YAMLs"
git push dry main

È possibile che ti venga richiesto di inserire le credenziali GitHub quando esegui il push al repository privato.

Esamina il risultato del job di Cloud Build

Quando esegui il commit delle modifiche e ne esegui il push nel repository YOUR_PRIVATE_DRY_REPO, viene attivato il job di Cloud Build. Se il job Cloud Build viene eseguito correttamente, vengono create diverse risorse. In questa sezione verificherai se le risorse vengono create dopo il completamento del job Cloud Build.

1. In Cloud Shell, nel cluster sample-ops, verifica di avere uno spazio dei nomi chiamato activeassist-kcc:

   kubectl get ns | grep activeassist-kcc
   

2. Config Connector esegue il deployment di un'istanza Compute Engine di esempio in esecuzione nel progetto PROJECT_ID.

   Convalida che l'istanza Compute Engine si trovi nel progetto:

    gcloud compute instances list | grep \
    computeinstance-sample-cloudmachine
   

   Il tipo di MACHINE_TYPE di questa macchina è n1-standard-1.

Esegui test end-to-end

Per consentirti di testare la pipeline end-to-end, il repository che hai clonato per questo tutorial fornisce suggerimenti di esempio (stub). Questi stub vengono utilizzati per eseguire la pipeline end-to-end. Lo stub imita un payload di suggerimento di Active Assist e suggerisce di cambiare il tipo di macchina per l'istanza Compute Engine di cui è stato eseguito il deployment dal tipo di istanza n1-standard-1 al tipo di istanza g1-small.

In questa sezione, richiami manualmente il trigger di Cloud Build pianificato per eseguire il job che utilizza una funzione kpt per recuperare i suggerimenti di Active Assist. Puoi anche verificare che sia stato creato un problema GitHub nel tuo repository YOUR_PRIVATE_DRY_REPO.

1. Apri la pagina Trigger di build nella console Google Cloud.

   Apri la pagina Trigger di build

2. Seleziona l'attivatore ActiveAssistScheduledRecommendations.

3. Per testare manualmente il trigger, fai clic su Esegui sulla voce del trigger nell'elenco dei trigger.

   Il trigger crea un problema GitHub nel tuo repository YOUR_PRIVATE_DRY_REPO. Il problema è simile al seguente:

   gcloud auth configure-docker
   
   docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function
   
   docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1
   

   Nel problema di esempio, l'output della funzione kpt mostra che il tipo MACHINE_TYPE attuale per l'istanza di Compute Engine è di tipo n1-standard-1. Il consiglio di Active Assist è di cambiarlo in un tipo g1-small.

   I revisori del controllo della versione della tua azienda possono esaminare i problemi automatizzati di GitHub e intervenire come opportuno per la tua azienda.

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

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à descritte in questo documento, quando lo elimini elimini anche tutto il 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 appspot.com URL, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.
1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Passaggi successivi

• Scopri di più sulle tecnologie serverless di Google Cloud.
• Scopri come integrare i suggerimenti di Policy Intelligence in una pipeline Infrastructure as Code (IaC).