Utilizzo della toolchain GKE Enterprise con Active Assist

---

Questo documento fa parte di una serie che illustra i pattern di architettura che le imprese possono utilizzare per ottimizzare il proprio impatto sul cloud su larga scala utilizzando Active Assist. Il tutorial mostra come creare una pipeline di automazione per i consigli di Active Assist che funzioni con la toolchain GKE Enterprise. È rivolto a chi utilizza Config Sync per gestire i propri ambienti GKE Enterprise e Config Connector per gestire le risorse Google Cloud . Le altre parti della serie sono:

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

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

• Scala l'utilizzo del portafoglio di Active Assist nella tua organizzazione.
• Inserisci Active Assist nella pipeline di integrazione e distribuzione continua (CI/CD).
• Controllo della revisione e dell'attivazione dei consigli di Active Assist utilizzando elementi 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 di 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 di Config Connector che implementi nei progetti della tua Google Cloud organizzazione.
• 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 Config Sync. Utilizzano Config Connector per attivare e gestire le Google Cloud risorse nell' Google Cloud organizzazione.
• Un cluster GKE che utilizza Config Sync per il controllo della versione e il rilevamento della deriva. In questo cluster è installato anche Config Connector. Config Connector consente al cluster di gestire Google Cloud le risorse dell' Google Cloud organizzazione.
• Un trigger Cloud Build che attiva una build quando un modello viene eseguito push nel repository DRY di GitHub.
• Un trigger di Cloud Build pianificato che attiva una compilazione periodicamente. Il job di compilazione utilizza una funzione kpt. La funzione invoca le API Active Assist Recommender per recuperare i consigli attivi. Esamina e analizza i consigli per determinare se le Google Cloud risorse 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 sottoposto a commit nel ramo main.
3. Il job Cloud Build esegue l'idratazione dei modelli chiamando i settaggi kpt. Il job spinge i file di configurazione idratati nel repository GitHub idratato. Secret Manager viene utilizzato per archiviare le chiavi di deployment di 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 Cloudse è necessario crearne o aggiornarne alcune a seguito delle modifiche al Kubernetes Resource Model (KRM) applicate da Config Sync.
6. Un attivatore Cloud Build pianificato viene eseguito periodicamente per invocare l'API Recommender al fine di 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 consigli attivi.
8. La funzione kpt crea un problema GitHub che mostra un confronto tra la configurazione corrente della risorsa e la 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 contenere i file di configurazione idratati generati utilizzando i settati di kpt.
• Crea un cluster GKE con Config Sync e Config Connector.
• Crea una funzione kpt di esempio per recuperare i consigli di Active Assist per i progetti gestiti da Config Connector.
• Crea un trigger 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 consigli di Active Assist disponibili per le risorse gestite da Config Connector.
• Testa la pipeline end-to-end con i consigli sugli stub forniti nel repository GitHub di 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
• Google Kubernetes Engine (GKE) Enterprise edition

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi Google Cloud utenti potrebbero avere diritto a una prova gratuita.

Al termine delle attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione 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. Utilizza questo ID nella sezione successiva quando configuri l'ambiente. Questo progetto viene chiamato build nel tutorial.

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

   Enable the APIs

   Per questo tutorial utilizzi le credenziali predefinite dell'applicazione. Se ti viene chiesto di creare 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, 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 del progetto del progetto Google Cloud build attivo:

   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 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 la compilazione della pipeline. I consigli di Active Assist vengono generati in base ai modelli di utilizzo e alle metriche di sistema. Ogni categoria di consigli può utilizzare un periodo di tempo predefinito diverso per analizzare i dati e le metriche di utilizzo 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 consigli di esempio (stub) che utilizzi per eseguire la pipeline end-to-end.

In alternativa, se esegui la pipeline in un progetto di esempio con risorse e consigli esistenti, puoi apportare le modifiche necessarie al codice campione ed 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 assegnato 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 ci sono consigli di Active Assist che devono essere esaminati. Per maggiori informazioni sulla creazione di token 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 token 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 assegnato 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 eseguire l'idratazione dei 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 deployment ai repository GitHub, consulta la documentazione di GitHub relativa alla gestione delle chiavi di deployment.

Carica le chiavi GitHub in Secret Manager

1. In Cloud Shell, crea un segreto per memorizzare la chiave privata della coppia di chiavi di deployment:

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

2. Crea un secret per archiviare il token PAT:

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

Crea un cluster GKE

In questa sezione, crei un cluster GKE con il plug-in Config Connector, crei un'identità e configuri Config Connector. Devi anche configurare Config Sync. Puoi utilizzare Config Sync per creare una configurazione comune in tutta la tua infrastruttura, inclusi 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 venga sempre applicato ai 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 di 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 eseguire il push nel repository idratato

Nelle sezioni seguenti, creerai un trigger Cloud Build che viene attivato quando i modelli vengono sottoposti a push nel ramo principale del tuo repository YOUR_PRIVATE_DRY_REPO. Questo attivatore esegue i passaggi per eseguire l'idratazione dei modelli KRM di configurazione come dati nel repository YOUR_PRIVATE_DRY_REPO e invia i file di configurazione idratati al repository YOUR_PRIVATE_HYDRATED_REPO.

Connetti Cloud Build ai tuoi repository GitHub

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

1. Vai alla pagina del marketplace di 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 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 da GoogleCloudBuild. Viene visualizzata la 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"
   

Creare un trigger Cloud Build pianificato per i consigli 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 consigli di Active Assist.

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

Genera un'immagine Cloud Build

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

1. In Cloud Shell, crea ed esegui il push di un'immagine Docker 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 configurare l'attivatore Cloud Build pianificato:

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

2. Crea l'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 attivatore:

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

Crea un job Cloud Scheduler per richiamare l'attivatore

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 serviziorecommender-parser.

2. Concedi all'account di servizio le autorizzazioni per invocare 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 l'attivatore 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 YOUR_PRIVATE_DRY_REPO repository:

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 chiesto di inserire le credenziali di 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 nel 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 verifichi 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 denominato 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 sia nel progetto:

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

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

Eseguire 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). Utilizza questi stub per eseguire la pipeline end-to-end. Lo stub imita un payload del consiglio di Active Assist e contiene un consiglio per modificare il tipo di macchina dell'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 l'attivatore Cloud Build pianificato per eseguire il job che utilizza una funzione kpt per recuperare i consigli di Active Assist. Verifica inoltre che nel tuo repository YOUR_PRIVATE_DRY_REPO sia stato creato un problema GitHub.

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

   Apri la pagina Trigger di build

2. Seleziona l'attivatore ActiveAssistScheduledRecommendations.

3. Per testare manualmente l'attivatore, fai clic su Esegui nella voce corrispondente nell'elenco dei trigger.

   L'attivatore crea un problema GitHub nel YOUR_PRIVATE_DRY_REPO repository. 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 corrente per l'istanza Compute Engine è di tipo n1-standard-1. Il consiglio di assistenza attiva è di cambiarlo in un tipo g1-small.

   I revisori del controllo versione della tua azienda possono esaminare i problemi automatici 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 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 Google Cloud serverless.
• Scopri come integrare i consigli di Policy Intelligence in una pipeline Infrastructure as Code (IaC).