Utilizzo della toolchain di Anthos con Active Assist

---

Questo documento fa parte di una serie che tratta 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 suggerimenti di Active Assist che funzionano con la toolchain di Anthos. È destinato a chi utilizza Anthos Config Management per gestire i propri ambienti Anthos e Config Connector per gestire le risorse Google Cloud. Le altre parti della serie sono le seguenti:

• Modelli per l'utilizzo di Active Assist su larga scala
• Utilizzo delle pipeline serverless con Active Assist
• Utilizzo dello strumento catena di strumenti Anthos con Active Assist (questo documento)

La pipeline di automazione che crei in questo tutorial può aiutarti a raggiungere:

• Scalabilità dell'utilizzo del portafoglio Active Assist nella tua organizzazione.
• Includere Active Assist nella pipeline di integrazione e distribuzione continue (CI/CD)
• Controllare la revisione e l'attivazione 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 architetturale mostra i componenti utilizzati in questo tutorial.

I componenti vengono utilizzati nei seguenti modi:

• Un repository GitHub non si ripete (DRY), che viene utilizzato per i modelli di Config Connector che esegui il deployment nei progetti della tua organizzazione Google Cloud.
• Uno o più repository GitHub specifici per un progetto o un ambiente e contenenti file di configurazione idratati. Questi repository idratati sono destinati agli ambienti gestiti da Anthos Config Management. Utilizzano Config Connector per attivare e gestire le risorse Google Cloud nell'organizzazione Google Cloud.
• Un cluster Anthos che utilizza Anthos Config Management per il controllo delle versioni e il rilevamento delle deviazioni. In questo cluster è installato anche Config Connector. Config Connector consente al cluster di gestire le risorse Google Cloud all'interno dell'organizzazione Google Cloud.
• Un trigger Cloud Build che attiva una build quando viene eseguito il push di un modello nel repository DRY di GitHub.
• Un trigger Cloud Build pianificato che attiva periodicamente una build. Il job di compilazione utilizza una funzione kpt. La funzione voca le API Active Assist Recommender per recuperare i suggerimenti attivi. Esamina e analizza i suggerimenti per determinare se le risorse 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 fatto il check-in nel ramo main.
3. Il job Cloud Build idrata i modelli richiamando i setter kpt. Il job esegue il push dei file di configurazione idratati nel repository GitHub idrato. Secret Manager viene utilizzato per archiviare le chiavi di deployment GitHub per il repository privato.
4. Config Sync monitora le modifiche al repository idrato e applica gli aggiornamenti trovati nel repository al cluster gestito.
5. Config Connector monitora le modifiche e applica le risorse Google Cloud nel caso in cui sia necessario creare o aggiornare le risorse in seguito alle modifiche al modello di risorse Kubernetes (KRM) applicate da Config Sync.
6. Un trigger Cloud Build pianificato esegue periodicamente un comando per richiamare l'API Recommender al recupero dei 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 GitHub che mostra un confronto della configurazione attuale della risorsa e della configurazione consigliata per la risorsa. Con questo approccio, i problemi 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 conservare i file di configurazione idrata generati utilizzando i setter kpt.
• Crea un cluster Anthos con Anthos Config Management, Config Sync e Config Connector.
• Creare 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 nel ramo main del repository DRY.
• Creare un job Cloud Build pianificato che venga 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 vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

• Cloud Build
• Cloud Run
• Firestore
• Pub/Sub
• Container Registry
• Cloud Scheduler

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.

Al termine di questo tutorial, puoi evitare una fatturazione continua eliminando le risorse che hai creato. Per scoprire di più, vedi Pulizia.

Prima di iniziare

1. Nella console Google Cloud, vai alla pagina del selettore dei progetti.

   Vai al selettore progetti

2. Seleziona o crea un progetto Google Cloud.

   Nota: se non prevedi di conservare le risorse che crei in questa procedura, crea un progetto invece di selezionarne uno esistente. Dopo aver completato questi passaggi, puoi eliminare il progetto e rimuovere tutte le risorse associate.
3. Prendi nota dell'ID progetto Google Cloud. Utilizzerai questo ID nella sezione successiva quando configuri l'ambiente. In questo tutorial il progetto viene chiamato build.

4. Abilita le API Cloud Build, Firestore, App Engine, Pub/Sub, Cloud Run, Cloud Scheduler e Cloud Source Repositories .

   Abilita le API

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

5. Verifica che la fatturazione sia attivata per il tuo progetto Google Cloud. Scopri come verificare se la fatturazione è abilitata per un progetto.

Configurazione dell'ambiente

In questo tutorial, eseguirai tutti i comandi in Cloud Shell.

1. In Google Cloud Console, attiva Cloud Shell.

   Attiva Cloud Shell

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

   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 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 a pattern di utilizzo e metriche di sistema. Ogni categoria di suggerimenti può utilizzare una finestra di tempo predefinita diversa per analizzare i dati sull'utilizzo e le metriche 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 utilizzi per eseguire la pipeline end-to-end.

In alternativa, se esegui la pipeline in un progetto di esempio con risorse e suggerimenti esistenti, puoi apportare le modifiche appropriate al codice campione e quindi 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 tuo repository DRY.

3. Crea un token di accesso personale (PAT) per creare problemi in questo repository. La pipeline crea problemi di 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

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

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

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

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 gestire le chiavi di deployment.

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

In questa sezione creerai un cluster Anthos con il componente aggiuntivo Config Connector, creerai un'identità e configurerai Config Connector. Configura anche Config Sync, un altro componente di Anthos Config Management. Puoi utilizzare Anthos Config Management per creare una configurazione comune in tutta l'infrastruttura, inclusi i criteri personalizzati, e applicarla sia on-premise che nel cloud. Anthos Config Management valuta i cambiamenti e li applica a tutti i cluster Kubernetes, in modo che lo stato desiderato venga sempre applicato ai tuoi 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 sezioni seguenti della guida all'installazione con il componente aggiuntivo di GKE per creare un'identità e configurare Config Connector.

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

3. Installare Config Sync nel cluster Anthos che hai creato. Quando configuri Anthos Config Management e Config Sync, devi:

   1. Utilizza un token per concedere 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 idrato

Nelle sezioni seguenti, creerai un trigger di Cloud Build che viene attivato quando viene eseguito il push dei modelli nel ramo principale del tuo 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 repository GitHub

In questa sezione, connetti i repository YOUR_PRIVATE_DRY_REPO e YOUR_PRIVATE_HYDRATED_REPO a GitHub.

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 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 Install (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 Authorize Google Cloud Build by GoogleCloudBuild. 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 Install (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 Authorize Google Cloud Build by GoogleCloudBuild. 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 che viene 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 all'account di servizio Cloud Build l'autorizzazione per 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 Cloud Build pianificato per i suggerimenti di Active Assist

Nota: utilizzi gli stub per testare la pipeline in questo tutorial. Quando utilizzi la pipeline per i progetti Google Cloud, assicurati di assegnare 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 ci sono suggerimenti attivi per le risorse nel tuo repository YOUR_PRIVATE_HYDRATED_REPO. La funzione kpt crea anche un problema di GitHub nel tuo repository YOUR_PRIVATE_HYDRATED_REPO se sono presenti suggerimenti attivi per la configurazione delle risorse che devono essere esaminati e attivati.

Genera un'immagine di Cloud Build

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

1. In Cloud Shell, crea ed esegui il push di un'immagine Docker a 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. 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 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 viene visualizzato il seguente messaggio:

   There is no App Engine app in the project.

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

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

Esegui il push dei due file di configurazione di Cloud Build che hai creato nel 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 nel repository privato.

Rivedi il risultato del job Cloud Build

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

   Verifica che l'istanza di Compute Engine sia nel progetto:

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

   Il tipo di 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 suggerimenti di esempio (stub). Si usano questi stub per eseguire la pipeline end-to-end. Lo stub imita un payload di suggerimenti di Active Assist e consiglia di modificare il tipo di macchina per l'istanza di Compute Engine di cui è stato eseguito il deployment da un tipo di istanza n1-standard-1 a un 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. Inoltre, verifichi che venga creato un problema di 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 di 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. Consigliamo di passare a un tipo g1-small.

   I revisori del controllo della versione nella tua azienda possono esaminare i problemi di GitHub automatico e intervenire se appropriato 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 questo tutorial, quando lo elimini elimini anche tutti gli altri lavori 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. Nella console Google Cloud, vai alla pagina Gestisci risorse.

   Vai a Gestisci risorse

2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi

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