Utilizzo della toolchain GKE Enterprise con Active Assist

---

Questo documento fa parte di una serie che illustra i pattern architetturali che le aziende possono utilizzare per ottimizzare la propria impronta cloud su larga scala utilizzando Active Assist. Il tutorial mostra come creare una pipeline di automazione per i consigli di Active Assist che funziona con la toolchain 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 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 pipeline di integrazione continua e distribuzione continua (CI/CD).
• Controllo della revisione e dell'attivazione dei suggerimenti di Active Assist utilizzando costrutti come problemi e richieste pull di GitHub.

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 Don't Repeat Yourself (DRY), utilizzato per i modelli Config Connector che deploy su più progetti nella tua organizzazione Google Cloud .
• Uno o più repository GitHub specifici per un progetto o un ambiente e che contengono file di configurazione idratati. Questi repository idratati sono per gli ambienti gestiti da Config Sync. Utilizzano Config Connector per attivare e gestire le risorse Google Cloud nell'organizzazione Google Cloud .
• Un cluster GKE che utilizza Config Sync per il controllo delle versioni e il rilevamento della deriva. Su questo cluster è installato anche Config Connector. Config Connector consente al cluster di gestire le risorse Google Cloud nell'organizzazione Google Cloud .
• Un trigger Cloud Build che attiva una build quando un modello viene inserito nel repository GitHub DRY.
• Un trigger di Cloud Build pianificato che attiva una build periodicamente. 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 Google Cloud risorse gestite da Config Connector devono essere ridimensionate o ottimizzate. La funzione kpt crea un problema di 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 viene creato o modificato un modello e viene eseguito il check-in nel ramo main.
3. Il job Cloud Build esegue l'idratazione dei modelli richiamando i setter kpt. 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 gli aggiornamenti trovati nel repository al cluster gestito.
5. Config Connector monitora le modifiche e attiva le risorse Google Cloud se è necessario creare o aggiornare risorse in seguito alle modifiche del Kubernetes Resource Model (KRM) applicate da Config Sync.
6. Un trigger Cloud Build pianificato viene eseguito periodicamente per richiamare l'API Recommender per recuperare i consigli 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 di GitHub che mostra un confronto tra la configurazione attuale della risorsa e la configurazione consigliata per la risorsa. Con questo approccio, i problemi di GitHub vengono creati nel repository DRY, il che semplifica il monitoraggio 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 i 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 venga attivato quando un modello viene inviato 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 consigli stub forniti nel repository GitHub per questo tutorial.

Costi

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

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

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il calcolatore prezzi.

I nuovi utenti di Google Cloud potrebbero avere diritto a una prova senza costi.

Al termine delle attività descritte in questo documento, puoi evitare l'addebito di ulteriori costi eliminando le risorse che hai creato. Per ulteriori informazioni, vedi 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.

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
   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 . Utilizzerai questo ID nella sezione successiva quando configurerai l'ambiente. Questo progetto viene indicato nel tutorial come progetto build.

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

   Roles required to enable APIs

   To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

   Enable the APIs

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

5. Verify that billing is enabled for your Google Cloud project.

Configurazione dell'ambiente

In questo tutorial, esegui 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 di progetto del progetto build Google Cloud corrente:

   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 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 contenente il codice dell'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, crei i componenti per creare la pipeline. I consigli di Active Assist vengono generati in base a modelli di utilizzo e metriche di sistema. Ogni categoria di consigli può utilizzare una diversa finestra temporale predefinita per analizzare i dati di utilizzo e le metriche in base ai quali vengono generati i consigli. Per testare la pipeline end-to-end, il repository che hai clonato in un passaggio precedente fornisce esempi di consigli (stub) che utilizzi per eseguire la pipeline end-to-end.

In alternativa, se esegui la pipeline in un progetto di esempio che contiene risorse e consigli esistenti, puoi apportare le modifiche appropriate alcodice campioneio e quindi eseguire la pipeline.

Configurare repository GitHub privati di esempio

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

Configurare 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 GitHub se sono presenti suggerimenti di Active Assist che devono essere esaminati. Per maggiori 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 che hai generato:

   export GITHUB_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN
   

   Sostituisci YOUR_PERSONAL_ACCESS_TOKEN con il tuo token.

Configurare un repository GitHub privato idratato

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 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 ti consente di eseguire il deployment nel tuo repository GitHub privato quando esegui un job Cloud Build per inserire 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 scoprire come aggiungere le chiavi di distribuzione ai repository GitHub, consulta la documentazione di GitHub relativa alla gestione delle chiavi di distribuzione.

Carica le chiavi GitHub in 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. Configuri anche Config Sync. Puoi utilizzare Config Sync per creare una configurazione comune nell'intera infrastruttura, compresi 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 venga sempre replicato 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 GKE per creare un'identità e configurare Config Connector.

   1. Creare 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 Config Sync l'accesso in sola lettura a Git. Utilizza il token GitHub che hai creato quando hai configurato un repository GitHub DRY privato. Il token è disponibile tramite la variabile di ambiente $GITHUB_TOKEN.
   2. Configura Config Sync utilizzando gcloud. Imposta 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 nel repository idratato

Nelle sezioni seguenti, creerai un trigger Cloud Build che viene attivato quando i modelli vengono inviati al ramo principale del repository YOUR_PRIVATE_DRY_REPO. Questo trigger esegue i passaggi che idratano i modelli KRM config-as-data nel repository YOUR_PRIVATE_DRY_REPO ed esegue il push dei file di configurazione idratati nel repository YOUR_PRIVATE_HYDRATED_REPO.

Connetti Cloud Build ai tuoi repository GitHub

In questa sezione, connetti 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 Configura con Google Cloud Build.

3. Se richiesto, accedi a GitHub.

4. Seleziona Solo repository selezionati.

   Utilizza il menu a discesa Seleziona repository per attivare l'accesso ai tuoi 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 da GoogleCloudBuild. Viene visualizzata la console Google Cloud .

8. Selezionare il tuo progetto Google Cloud .

9. Seleziona la casella di controllo del 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 da GoogleCloudBuild. Viene visualizzata la console Google Cloud .

13. Selezionare il tuo progetto Google Cloud .

14. Seleziona la casella di controllo del 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, quindi 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 il trigger:

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

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

Nota: in questo tutorial utilizzi 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 consigli di Active Assist.

Nelle sezioni seguenti, crei un trigger 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 repository YOUR_PRIVATE_HYDRATED_REPO. La funzione kpt crea anche un problema GitHub nel tuo repository YOUR_PRIVATE_HYDRATED_REPO se sono presenti consigli attivi per la configurazione delle risorse che devono essere esaminati e attuati.

Genera un'immagine Cloud Build

In questa sezione genererai un'immagine Cloud Build che contiene i componenti kpt, gh e Node.

1. In Cloud Shell, crea ed esegui il push di un'immagine Docker su 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 repository idratato

1. In Cloud Shell, crea il file di configurazione necessario per configurare 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. Recupera l'ID di questo trigger:

   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 al 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 che hai 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 visualizzi 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 su 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

Potrebbe esserti chiesto di inserire le credenziali GitHub quando esegui il push nel tuo repository privato.

Esamina il risultato del job Cloud Build

Quando esegui il commit e il push delle modifiche al repository YOUR_PRIVATE_DRY_REPO, viene attivato il job Cloud Build. Se il job Cloud Build viene eseguito correttamente, vengono create diverse risorse. In questa sezione verificherai se le risorse vengono create al termine 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 tuo progetto PROJECT_ID.

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

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

   Il tipo MACHINE_TYPE per 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 consigli di esempio (stub). Utilizzi questi stub per eseguire la pipeline end-to-end. Lo stub imita un payload di suggerimento di Active Assist e ha un suggerimento per modificare 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 Cloud Build pianificato per eseguire il job che utilizza una funzione kpt per recuperare i suggerimenti di Active Assist. Verifichi anche che venga creato un problema di GitHub nel 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 nella 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 Compute Engine è il tipo n1-standard-1. Il suggerimento di Active Assist è di modificarlo in un tipo g1-small.

   I revisori del controllo delle versioni della tua azienda possono esaminare i problemi automatizzati di GitHub e intervenire di conseguenza.

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 che hai 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. 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 Google Cloud.
• Scopri come integrare i suggerimenti di Policy Intelligence in una pipeline Infrastructure as Code (IaC).