Usar a cadeia de ferramentas do GKE Enterprise com o Active Assist

---

Este documento faz parte de uma série que aborda padrões de arquitetura que as empresas podem usar para otimizar a respetiva presença na nuvem em grande escala através do Active Assist. O tutorial mostra como criar um pipeline de automatização para recomendações do Active Assist que funciona com a cadeia de ferramentas do GKE Enterprise. Destina-se a pessoas que usam o Config Sync para gerir os respetivos ambientes do GKE Enterprise e o Config Connector para gerir recursos. Google Cloud As outras partes da série são as seguintes:

• Padrões de utilização do Active Assist em grande escala
• Usar pipelines sem servidor com o Active Assist
• Usar a cadeia de ferramentas do GKE Enterprise com o Active Assist (este documento)

O pipeline de automatização que criar neste tutorial pode ajudar a alcançar o seguinte:

• Expandir a utilização do portefólio do Active Assist na sua organização.
• Integrar o Active Assist no seu pipeline de integração contínua e implementação contínua (CI/CD).
• Controlar a revisão e a ação das recomendações do Active Assist através de construções como problemas e pedidos de envio do GitHub.

Este tutorial também usa o kpt, um conjunto de ferramentas de código aberto desenvolvido pela Google para ajudar a gerir, manipular, personalizar e aplicar ficheiros de dados de configuração de recursos do Kubernetes.

Arquitetura

O diagrama de arquitetura seguinte mostra os componentes que usa neste tutorial.

Os componentes são usados das seguintes formas:

• Um repositório do GitHub não se repita (DRY), que é usado para modelos do Config Connector que implementa em projetos na sua organização Google Cloud .
• Um ou mais repositórios do GitHub específicos de um projeto ou de um ambiente e que contêm ficheiros de configuração preenchidos. Estes repositórios preenchidos destinam-se aos ambientes que o Config Sync gere. Usam o Config Connector para acionar e gerir Google Cloud recursos na Google Cloud organização.
• Um cluster do GKE que usa o Config Sync para controlo de versões e deteção de desvio. Este cluster também tem o Config Connector instalado. O Config Connector permite que o cluster faça a gestão de Google Cloud recursos em toda a Google Cloud organização.
• Um acionador do Cloud Build que aciona uma compilação quando um modelo é enviado para o repositório DRY do GitHub.
• Um acionador do Cloud Build agendado que aciona uma compilação periodicamente. A tarefa de compilação usa uma função kpt. A função invoca as APIs do recomendador do Active Assist para obter recomendações ativas. Revisa e analisa as recomendações para determinar se os Google Cloud recursos que o Config Connector gere precisam de ser redimensionados ou otimizados. A função kpt cria um problema do GitHub no repositório DRY com os detalhes da alteração recomendada se for necessário redimensionar ou otimizar os recursos geridos pelo Config Connector. Google Cloud

O fluxo de trabalho para esta arquitetura é o seguinte:

1. As equipas autorizadas com acesso ao repositório DRY criam e gerem modelos do Config Connector no repositório.
2. Uma tarefa do Cloud Build é acionada quando um modelo é criado ou modificado e registado no ramo main.
3. A tarefa do Cloud Build preenche os modelos invocando os definidores do kpt. A tarefa envia os ficheiros de configuração hidratados para o repositório do GitHub hidratado. O Secret Manager é usado para armazenar chaves de implementação do GitHub para o repositório privado.
4. O Config Sync monitoriza as alterações ao repositório preenchido e aplica as atualizações encontradas no repositório ao cluster gerido.
5. O Config Connector monitoriza as alterações e aciona Google Cloud recursos se for necessário criar ou atualizar recursos como resultado das alterações do modelo de recursos do Kubernetes (KRM) aplicadas pelo Config Sync.
6. Um acionador do Cloud Build agendado é executado periodicamente para invocar a API Recommender para obter recomendações ativas para os projetos geridos pelo Config Connector.
7. A tarefa do Cloud Build agendada executa uma função kpt personalizada para invocar a API Recommender e obter e analisar as recomendações ativas.
8. A função kpt cria um problema do GitHub que mostra uma comparação da configuração de recursos atual e da configuração recomendada para o recurso. Com esta abordagem, os problemas do GitHub são criados no repositório DRY, o que facilita o acompanhamento das alterações ao repositório.

Objetivos

• Crie os seguintes repositórios de exemplo do GitHub:
  • Um repositório DRY para KRMs do Config Connector.
  • Um repositório para armazenar ficheiros de configuração hidratados gerados com definidores do kpt.
• Crie um cluster do GKE com o Config Sync e o Config Connector.
• Crie uma função kpt de exemplo para obter recomendações do Active Assist para projetos geridos pelo Config Connector.
• Crie um acionador do Cloud Build que seja acionado quando um modelo é enviado para o ramo main do repositório DRY.
• Crie uma tarefa agendada do Cloud Build que seja executada periodicamente para obter as recomendações do Active Assist disponíveis para os recursos que estão a ser geridos pelo Config Connector.
• Teste o pipeline completo com as recomendações de teste simulado fornecidas no repositório do GitHub para este tutorial.

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

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

Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Quando terminar as tarefas descritas neste documento, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpe.

Antes de começar

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. Tome nota do Google Cloud ID do projeto. Vai usar este ID na secção seguinte quando configurar o seu ambiente. Este projeto é referido ao longo do tutorial como o projeto 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

   Usa as credenciais da aplicação predefinidas para este tutorial. Se lhe for pedido que crie credenciais na página Adicione credenciais ao seu projeto, clique em Cancelar.

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

Configurar o seu ambiente

Neste tutorial, executa todos os comandos no Cloud Shell.

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

   Activate Cloud Shell

2. Defina variáveis para o ID do projeto e o número do projeto do projeto build Google Cloud atual:

   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)')
   

   Substitua PROJECT_ID pelo ID do projeto que anotou na secção anterior.

3. Defina variáveis para a região de implementação:

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

4. Clone o repositório que contém o código da app de exemplo usada neste tutorial:

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

5. Aceda ao diretório do projeto:

   cd activeassist-anthos-toolchain
   

Crie a pipeline

Nesta secção, cria os componentes para criar o pipeline. As recomendações do Active Assist são geradas com base nos padrões de utilização e nas métricas do sistema. Cada categoria de recomendações pode usar um período predefinido diferente para analisar os dados de utilização e as métricas com base nas recomendações geradas. Para testar o pipeline ponto a ponto, o repositório que clonou num passo anterior fornece recomendações de exemplo (simulações) que usa para executar o pipeline ponto a ponto.

Em alternativa, se estiver a executar o pipeline num projeto de exemplo com recursos e recomendações existentes, pode fazer as alterações adequadas ao código de exemplo e, em seguida, executar o pipeline.

Configure exemplos de repositórios privados do GitHub

Nas secções seguintes, configura os repositórios de exemplo do GitHub para este tutorial.

Configure um repositório do GitHub DRY privado

1. Crie um repositório privado do GitHub para o repositório DRY. Tome nota do nome que atribui ao repositório.

2. No Cloud Shell, crie uma variável de ambiente para o seu nome de utilizador do GitHub e o nome do repositório DRY:

   export REPO_OWNER=YOUR_GITHUB_USERNAME
   export DRY_REPO_NAME=YOUR_PRIVATE_DRY_REPO
   

   Substitua o seguinte:

   • YOUR_GITHUB_USERNAME: o seu nome de utilizador do GitHub.
   • YOUR_PRIVATE_DRY_REPO: o nome do seu repositório DRY.

3. Crie um token de acesso pessoal (PAT) para criar problemas neste repositório. O pipeline cria problemas do GitHub se existirem recomendações do Active Assist que precisam de ser revistas. Para mais informações sobre a criação de PATs no GitHub, consulte a documentação do GitHub.

   Quando define um âmbito para este token, selecione Controlo total dos repositórios privados.

4. No Cloud Shell, crie uma variável de ambiente para o PAT que gerou:

   export GITHUB_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN
   

   Substitua YOUR_PERSONAL_ACCESS_TOKEN pelo seu próprio token.

Configure um repositório do GitHub privado preenchido

1. Crie um repositório privado do GitHub para o repositório preenchido. Tome nota do nome que atribui ao repositório.

2. No Cloud Shell, defina uma variável de ambiente para o repositório preenchido:

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

   Substitua YOUR_PRIVATE_HYDRATED_REPO pelo nome do seu repositório preenchido.

3. Crie um par de chaves de implementação:

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

   Uma chave de implementação permite-lhe implementar no seu repositório privado do GitHub quando executa uma tarefa do Cloud Build para preencher ficheiros de configuração.

4. Imprima a chave gerada:

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

5. Adicione a chave de implementação ao repositório privado do GitHub. Certifique-se de que seleciona Permitir acesso de escrita quando adicionar a chave de implementação. Para saber como adicionar chaves de implementação a repositórios do GitHub, consulte a documentação do GitHub sobre a gestão de chaves de implementação.

Carregue chaves do GitHub para o Secret Manager

1. No Cloud Shell, crie um segredo para armazenar a chave privada do par de chaves de implementação:

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

2. Crie um segredo para armazenar o PAT:

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

Crie um cluster do GKE

Nesta secção, cria um cluster do GKE com o suplemento do Config Connector, cria uma identidade e configura o Config Connector. Também configura o Config Sync. Pode usar o Config Sync para criar uma configuração comum em toda a sua infraestrutura, incluindo políticas personalizadas, e aplicá-la no local e na nuvem. O Config Sync avalia as alterações e implementa-as em todos os clusters do Kubernetes para que o estado pretendido seja sempre refletido nos seus clusters.

1. No Cloud Shell, crie um novo cluster do GKE com o suplemento Config Connector ativado:

   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. Conclua as secções seguintes no guia Instalar com o suplemento do GKE para criar uma identidade e configurar o Config Connector.

   1. Criar uma identidade
   2. Configurar o Config Connector

3. Instale o Config Sync no cluster do GKE que criou. Quando configura o Config Sync, tem de fazer o seguinte:

   1. Use um token para conceder acesso só de leitura ao Git ao Config Sync. Use o token do GitHub que criou quando configurou um repositório DRY privado do GitHub. O token está disponível através da variável de ambiente $GITHUB_TOKEN.
   2. Configure o Config Sync com o gcloud. Defina as seguintes definições:
      1. sourceFormat: hierarchy
      2. syncRepo: https://github.com/YOUR_GITHUB_USERNAME/YOUR_PRIVATE_HYDRATED_REPO
      3. syncBranch: main
      4. secretType: token
      5. policyDir: não preencha esta opção

Crie um acionador do Cloud Build para enviar para o repositório hidratado

Nas secções seguintes, cria um acionador do Cloud Build que é acionado quando os modelos são enviados para o ramo principal do seu repositório.YOUR_PRIVATE_DRY_REPO Este acionador executa os passos que preenchem os modelos KRM de configuração como dados no repositório YOUR_PRIVATE_DRY_REPO e envia os ficheiros de configuração preenchidos para o seu repositório YOUR_PRIVATE_HYDRATED_REPO.

Associe o Cloud Build aos seus repositórios do GitHub

Nesta secção, associa os repositórios do YOUR_PRIVATE_DRY_REPO e do YOUR_PRIVATE_HYDRATED_REPO ao Cloud Build.

1. Aceda à página do GitHub Marketplace para a app Cloud Build.

   Aceda à página da app Cloud Build

2. Clique em Configurar com o Google Cloud Build.

3. Se lhe for pedido, inicie sessão no GitHub.

4. Selecione Selecionar apenas repositórios.

   Use o menu pendente Selecionar repositórios para ativar o acesso aos seus repositórios YOUR_PRIVATE_DRY_REPO e YOUR_PRIVATE_HYDRATED_REPO através da app Cloud Build.

5. Clique em Instalar.

6. Inicie sessão em Google Cloud. É apresentada a página Autorização e é-lhe pedido que autorize a app Google Cloud Build a estabelecer ligação a Google Cloud.

7. Clique em Autorizar o Google Cloud Build por GoogleCloudBuild. É redirecionado para a consola Google Cloud .

8. Selecione o seu projeto do Google Cloud .

9. Selecione a caixa de verificação de consentimento e clique em Seguinte.

10. Clique em Instalar.

11. Inicie sessão em Google Cloud. É apresentada a página Autorização e é-lhe pedido que autorize a app Google Cloud Build a estabelecer ligação a Google Cloud.

12. Clique em Autorizar o Google Cloud Build por GoogleCloudBuild. É redirecionado para a consola Google Cloud .

13. Selecione o seu projeto do Google Cloud .

14. Selecione a caixa de verificação de consentimento e clique em Seguinte.

15. Na página Selecionar repositório apresentada, selecione os seguintes repositórios do GitHub:

    • YOUR_PRIVATE_DRY_REPO
    • YOUR_PRIVATE_HYDRATED_REPO

16. Clique em Associar e, de seguida, em Concluído.

Crie um acionador do Cloud Build para o repositório DRY

1. No Cloud Shell, execute o seguinte comando:

   envsubst < cloudbuild.template.yaml > cloudbuild.yaml
   

   O comando gera um ficheiro cloudbuild.yaml.

2. Crie o acionador:

   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. Conceda à conta de serviço do Cloud Build autorização para aceder ao 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"
   

Crie um acionador do Cloud Build agendado para recomendações do Active Assist

Nota: usa stubs para testar o pipeline neste tutorial. Quando usar o pipeline para os seus projetos, certifique-se de que concede à conta de serviço do Cloud Build as autorizações de que precisa para obter recomendações do Active Assist.
Google Cloud

Nas secções seguintes, vai criar um acionador do Cloud Build agendado que é executado periodicamente. Este acionador obtém recomendações do Active Assist através de uma função kpt e determina se existem recomendações ativas para os recursos no seu repositório.YOUR_PRIVATE_HYDRATED_REPO A função kpt também cria um problema do GitHub no seu repositório se existirem recomendações ativas para a configuração de recursos que precisam de ser revistas e acionadas.YOUR_PRIVATE_HYDRATED_REPO

Gere uma imagem do Cloud Build

Nesta secção, vai gerar uma imagem do Cloud Build com os componentes kpt, gh e Node.

1. No Cloud Shell, crie e envie uma imagem Docker para o 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
   

Crie um acionador do Cloud Build para o seu repositório hidratado

1. No Cloud Shell, crie o ficheiro de configuração necessário para configurar o acionador do Cloud Build agendado:

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

2. Crie o acionador do 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. Obtenha o ID deste acionador:

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

Crie uma tarefa do Cloud Scheduler para invocar o acionador

1. No Cloud Shell, crie uma conta de serviço:

   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
   

   As tarefas do Cloud Scheduler usam esta conta de serviço para executar o serviço recommender-parser.

2. Conceda à conta de serviço as autorizações para invocar uma tarefa do 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. Crie uma tarefa do Cloud Scheduler para invocar o acionador que criou no passo anterior:

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

   Se vir a seguinte mensagem, selecione Y:

   There is no App Engine app in the project.

   Se lhe for pedido que escolha a região onde quer que a sua aplicação do App Engine esteja localizada, selecione a região us-central.

Confirme e envie os ficheiros de configuração do Cloud Build para o GitHub

Envie os dois ficheiros de configuração do Cloud Build que criou para o seu repositório: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

Pode ser-lhe pedido que introduza as suas credenciais do GitHub quando envia conteúdo para o seu repositório privado.

Reveja o resultado da tarefa do Cloud Build

Quando confirma e envia alterações para o seu repositório YOUR_PRIVATE_DRY_REPO, a tarefa do Cloud Build é acionada. Se a tarefa do Cloud Build for executada com êxito, são criados vários recursos. Nesta secção, vai validar se os recursos são criados após a conclusão da tarefa do Cloud Build.

1. No Cloud Shell, no cluster sample-ops, valide se tem um espaço de nomes denominado activeassist-kcc:

   kubectl get ns | grep activeassist-kcc
   

2. O Config Connector implementa uma instância do Compute Engine de exemplo em execução no seu projeto.PROJECT_ID

   Valide se a instância do Compute Engine está no projeto:

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

   O tipo MACHINE_TYPE desta máquina é n1-standard-1.

Execute testes ponto a ponto

Para lhe permitir testar o pipeline ponto a ponto, o repositório que clonou para este tutorial fornece recomendações de exemplo (stubs). Use estes stubs para executar o pipeline completo. O stub imita um payload de recomendação do Active Assist e tem uma recomendação para alterar o tipo de máquina da instância do Compute Engine implementada a partir do tipo de instância n1-standard-1 para o tipo de instância g1-small.

Nesta secção, invoca o acionador do Cloud Build agendado manualmente para executar a tarefa que usa uma função kpt para obter recomendações do Active Assist. Também verifica se foi criado um problema do GitHub no seu repositório do YOUR_PRIVATE_DRY_REPO.

1. Abra a página Acionadores de compilação na Google Cloud consola.

   Abra a página Acionadores de versão

2. Selecione o acionador ActiveAssistScheduledRecommendations.

3. Para testar manualmente o acionador, clique em Executar na entrada do acionador na lista de acionadores.

   O acionador cria um problema do GitHub no seu YOUR_PRIVATE_DRY_REPO repositório. O problema é semelhante ao seguinte:

   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
   

   No exemplo de problema, o resultado da função kpt mostra que o tipo atual da instância do Compute Engine é o tipo n1-standard-1.MACHINE_TYPE A recomendação do Active Assist é alterá-lo para um tipo g1-small.

   Os revisores do controlo de versões na sua empresa podem rever problemas automatizados do GitHub e tomar as medidas adequadas para a sua empresa.

Limpar

Para evitar incorrer em custos na sua conta do Google Cloud pelos recursos usados neste tutorial, elimine o projeto que contém os recursos ou mantenha o projeto e elimine os recursos individuais.

Atenção: a eliminação de um projeto tem os seguintes efeitos:
• Tudo no projeto é eliminado. Se usou um projeto existente para as tarefas neste documento, quando o elimina, também elimina qualquer outro trabalho que tenha feito no projeto.
• Os IDs dos projetos personalizados são perdidos. Quando criou este projeto, pode ter criado um ID do projeto personalizado que quer usar no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, elimine os recursos selecionados no projeto em vez de eliminar o projeto inteiro.
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.

O que se segue?

• Saiba mais sobre as tecnologias Google Cloud sem servidor.
• Leia acerca de como integrar as recomendações da inteligência de políticas numa pipeline de infraestrutura como código (IaC).