Desenvolva e implemente apps contentorizadas através de um pipeline de CI/CD

Last reviewed 2022-11-18 UTC

Este guia de implementação descreve como configurar e usar um sistema de desenvolvimento, integração contínua (IC) e entrega contínua (EC) através de um conjunto integrado de Google Cloud ferramentas. Pode usar este sistema para desenvolver e implementar aplicações no Google Kubernetes Engine (GKE).

Este guia mostra-lhe como criar a arquitetura descrita no artigo Pipeline de implementação para desenvolver e fornecer apps contentorizadas.

Este guia de implementação destina-se a programadores de software e operadores. Ao concluí-lo, desempenha as seguintes funções:

  • Primeiro, atua como operador para configurar o pipeline de CI/CD. Os principais componentes desta pipeline são o Cloud Build, o Artifact Registry e o Cloud Deploy.
  • Em seguida, atua como programador para alterar uma aplicação através do Cloud Code. Quando atua como programador, vê a experiência integrada que este pipeline oferece.
  • Por fim, atua como operador e segue os passos para implementar uma aplicação em produção.

Este guia de implementação pressupõe que está familiarizado com a execução de comandos gcloud no Google Cloud e com a implementação de contentores de aplicações no GKE.

Arquitetura

O diagrama seguinte mostra os recursos usados neste guia de implementação:

Desenvolva e implemente o sistema com o Cloud Code, o Cloud Build, o Artifact Registry, o Cloud Deploy e o GKE

Para ver detalhes sobre os componentes usados nesta arquitetura, consulte o artigo Pipeline de implementação para desenvolver e fornecer apps contentorizadas.

Objetivos

Enquanto operador, faz o seguinte:

  • Configure a pipeline de CI e a pipeline de CD. Esta configuração inclui o seguinte:
    • Configure as autorizações necessárias.
    • Crie os clusters do GKE para os ambientes de preparação e de produção.
    • Crie um repositório nos Cloud Source Repositories para o código-fonte.
    • Crie um repositório no Artifact Registry para o contentor da aplicação.
    • Crie um acionador do Cloud Build no repositório principal do GitHub.
    • Crie um pipeline de entrega e destinos do Cloud Deploy. Os destinos são o ambiente de teste e o ambiente de produção.
  • Inicie o processo de CI/CD para implementar na fase de testes e, em seguida, promover para produção.

Enquanto programador, faz uma alteração à aplicação. Para o fazer, siga estes passos:

  • Clone o repositório para trabalhar com um ambiente de desenvolvimento pré-configurado.
  • Faça uma alteração à aplicação no seu espaço de trabalho do programador.
  • Crie e teste a alteração. Os testes incluem um teste de validação para a governação.
  • Veja e valide a alteração num cluster de desenvolvimento. Este cluster é executado no minikube.
  • Confirme a alteração no repositório principal.

Custos

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

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, on the project selector page, 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.

    Go to project selector

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

  3. Enable the Artifact Registry, Cloud Build, Cloud Deploy, Cloud Source Repositories, Google Kubernetes Engine, Resource Manager, and Service Networking 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

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

    Activate Cloud Shell

    Prepare o seu ambiente

    Nesta secção, atua como operador da aplicação e faz o seguinte:

    • Configure as autorizações necessárias.
    • Crie os clusters do GKE para os ambientes de preparação e de produção.
    • Clone o repositório de origem.
    • Crie um repositório nos Cloud Source Repositories para o código-fonte.
    • Crie um repositório no Artifact Registry para a aplicação de contentor.

    Configure as autorizações

    Nesta secção, concede as autorizações necessárias para configurar o pipeline de CI/CD.

    1. Se estiver a trabalhar numa nova instância do Cloud Shell Editor, especifique o projeto a usar para este guia de implementação:

      gcloud config set project PROJECT_ID
      

      Substitua PROJECT_ID pelo ID do projeto que selecionou ou criou para este guia de implementação.

      Se for apresentada uma caixa de diálogo, clique em Autorizar.

    2. Certifique-se de que a conta de serviço predefinida do Compute Engine tem autorizações suficientes para executar tarefas no Cloud Deploy e extrair contentores do Artifact Registry. O Cloud Build e o Cloud Deploy usam esta conta de serviço predefinida.

      Esta conta de serviço pode já ter as autorizações necessárias. Este passo garante que as autorizações necessárias são concedidas para projetos que desativam as concessões de funções automáticas para contas de serviço predefinidas.

      gcloud projects add-iam-policy-binding PROJECT_ID \
          --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
          --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
          --role="roles/clouddeploy.jobRunner"
      
      gcloud projects add-iam-policy-binding PROJECT_ID \
          --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
          --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
          --role="roles/artifactregistry.reader"
      
    3. Conceda o privilégio da conta de serviço do Cloud Build para invocar implementações com o Cloud Deploy e atualizar o pipeline de entrega e as definições de destino:

      gcloud projects add-iam-policy-binding PROJECT_ID \
          --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
          --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \
          --role="roles/clouddeploy.operator"
      

      Para mais informações sobre esta função do IAM, consulte a função clouddeploy.operator.

    4. Conceda o privilégio da conta de serviço do Cloud Build e do Cloud Deploy para implementação no GKE:

      gcloud projects add-iam-policy-binding PROJECT_ID \
          --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
          --format="value(projectNumber)")-compute@developer.gserviceaccount.com \
          --role="roles/container.admin"
      

      Para mais detalhes acerca desta função de IAM, consulte a função container.admin.

    5. Conceda à conta de serviço do Cloud Build as autorizações necessárias para invocar operações do Cloud Deploy:

      gcloud projects add-iam-policy-binding PROJECT_ID \
          --member=serviceAccount:$(gcloud projects describe PROJECT_ID \
          --format="value(projectNumber)")@cloudbuild.gserviceaccount.com \
          --role="roles/iam.serviceAccountUser"
      

      Quando o Cloud Build invoca o Cloud Deploy, usa uma conta de serviço do Compute Engine para criar uma versão, motivo pelo qual esta autorização é necessária.

      Para mais detalhes acerca desta função do IAM, consulte a função iam.serviceAccountUser.

    Concedeu as autorizações necessárias para o pipeline de CI/CD.

    Crie os clusters do GKE

    Nesta secção, cria os ambientes de preparação e produção, que são ambos clusters do GKE. (Não precisa de configurar o cluster de desenvolvimento aqui, porque usa o minikube.)

    1. Crie os clusters do GKE de preparação e produção:

      gcloud container clusters create-auto staging \
          --region us-central1 \
          --project=$(gcloud config get-value project) \
          --async
      
      gcloud container clusters create-auto prod \
          --region us-central1 \
          --project=$(gcloud config get-value project) \
          --async
      

      O cluster de preparação é onde testa as alterações ao seu código. Depois de verificar que a implementação na fase de testes não afetou negativamente a aplicação, implemente-a na produção.

    2. Execute o seguinte comando e certifique-se de que o resultado tem STATUS: RUNNING para os clusters de preparação e produção:

      gcloud container clusters list
      
    3. Recupere as credenciais dos seus ficheiros kubeconfig para os clusters de preparação e produção.

      gcloud container clusters get-credentials staging --region us-central1
      
      gcloud container clusters get-credentials prod --region us-central1
      

      Usa estas credenciais para interagir com os clusters do GKE, por exemplo, para verificar se uma aplicação está a ser executada corretamente.

    Criou os clusters do GKE para o ambiente de preparação e produção.

    Abra o IDE e clone o repositório

    Para clonar o repositório e ver a aplicação no seu ambiente de desenvolvimento, faça o seguinte:

    1. Clone o repositório do GitHub para o Cloud Shell.

      Abra no Cloud Shell

    2. Clique em Confirm.

      O Cloud Shell Editor abre e clona o repositório de amostras.

      Agora, pode ver o código da aplicação no editor do Cloud Shell.

    3. Especifique o projeto a usar para este guia de implementação:

      gcloud config set project PROJECT_ID
      

      Se for apresentada uma caixa de diálogo, clique em Autorizar.

    Agora, tem o código-fonte da aplicação no seu ambiente de desenvolvimento.

    Este repositório de origem inclui os ficheiros do Cloud Build e do Cloud Deploy necessários para o pipeline de CI/CD.

    Crie repositórios para o código-fonte e para os contentores

    Nesta secção, configura um repositório nos Cloud Source Repositories para o código fonte e um repositório no Artifact Registry para armazenar os contentores criados pelo pipeline de CI/CD.

    1. Crie um repositório nos Cloud Source Repositories para armazenar o código fonte e associe-o ao processo de CI/CD:

      gcloud source repos create cicd-sample
      
    2. Certifique-se de que as configurações do Cloud Deploy segmentam o projeto correto:

      sed -i s/project-id-placeholder/$(gcloud config get-value project)/g deploy/*
      git config --global credential.https://source.developers.google.com.helper gcloud.sh
      git remote add google https://source.developers.google.com/p/$(gcloud config get-value project)/r/cicd-sample
      
    3. Envie o código-fonte para o repositório:

      git push --all google
      
    4. Crie um repositório de imagens no Artifact Registry:

      gcloud artifacts repositories create cicd-sample-repo \
          --repository-format=Docker \
          --location us-central1
      

    Agora, tem um repositório para o código-fonte nos Cloud Source Repositories e um para o contentor da aplicação no Artifact Registry. O repositório dos Cloud Source Repositories permite-lhe clonar o código fonte e associá-lo ao pipeline de CI/CD.

    Configure a pipeline de CI/CD

    Nesta secção, atua como operador da aplicação e configura o pipeline de CI/CD. O pipeline usa o Cloud Build para CI e o Cloud Deploy para CD. Os passos do pipeline são definidos no acionador do Cloud Build.

    1. Crie um contentor do Cloud Storage para o Cloud Build armazenar o ficheiro artifacts.json (que acompanha os artefactos gerados pelo Skaffold para cada compilação):

      gcloud storage buckets create gs://$(gcloud config get-value project)-gceme-artifacts/
      

      Armazenar o ficheiro artifacts.json de cada compilação num local central é uma boa prática porque oferece rastreabilidade, o que facilita a resolução de problemas.

    2. Reveja o ficheiro cloudbuild.yaml, que define o acionador do Cloud Build e já está configurado no repositório de origem que clonou.

      Este ficheiro define o acionador invocado sempre que existe um novo envio para o ramo principal do repositório de código-fonte.

      Os seguintes passos para o pipeline de CI/CD estão definidos no ficheiro cloudbuild.yaml:

      • O Cloud Build usa o Skaffold para criar o contentor da aplicação.

      • O Cloud Build coloca o ficheiro artifacts.json da compilação no contentor do Cloud Storage.

      • O Cloud Build coloca o contentor da aplicação no Artifact Registry.

      • O Cloud Build executa testes no contentor da aplicação.

      • O comando gcloud deploy apply regista os seguintes ficheiros no serviço Cloud Deploy:

        • deploy/pipeline.yaml, que é o pipeline de entrega
        • deploy/staging.yaml e deploy/prod.yaml, que são os ficheiros de destino

        Quando os ficheiros são registados, o Cloud Deploy cria o pipeline e os destinos, se ainda não existirem, ou recria-os se a configuração tiver sido alterada. Os destinos são os ambientes de preparação e produção.

      • O Cloud Deploy cria um novo lançamento para o pipeline de implementação.

        Esta versão faz referência ao contentor da aplicação que foi criado e testado no processo de CI.

      • O Cloud Deploy implementa o lançamento no ambiente de preparação.

      O pipeline de fornecimento e os destinos são geridos pelo Cloud Deploy e estão separados do código-fonte. Esta desvinculação significa que não precisa de atualizar o pipeline de entrega e os ficheiros de destino quando é feita uma alteração ao código fonte da aplicação.

    3. Crie o acionador do Cloud Build:

      gcloud beta builds triggers create cloud-source-repositories \
          --name="cicd-sample-main" \
          --repo="cicd-sample" \
          --branch-pattern="main" \
          --build-config="cloudbuild.yaml"
      

      Este acionador indica ao Cloud Build para monitorizar o repositório de origem e usar o ficheiro cloudbuild.yaml para reagir a quaisquer alterações ao repositório. Este acionador é invocado sempre que houver um novo envio para o ramo principal.

    4. Aceda à página do Cloud Build na Google Cloud consola.

      Aceda ao Cloud Build

      Repare que não existem compilações para a sua aplicação.

    Já configurou os pipelines de CI e CD e criou um acionador no ramo principal do repositório.

    Faça uma alteração à sua aplicação no espaço de trabalho do programador

    Nesta secção, atua como programador de aplicações.

    À medida que desenvolve a sua aplicação, faz e valida alterações iterativas à aplicação através do Cloud Code como espaço de trabalho de desenvolvimento:

    • Fazer uma alteração à aplicação.
    • Crie e teste o novo código.
    • Implemente a aplicação no cluster do minikube e valide as alterações visíveis para o utilizador.
    • Envie a alteração para o repositório principal.

    Quando esta alteração é confirmada no repositório principal, o acionador do Cloud Build inicia o pipeline de CI/CD.

    Crie, teste e execute a aplicação

    Nesta secção, cria, testa, implementa e acede à sua aplicação.

    Use a mesma instância do Editor do Cloud Shell que usou na secção anterior. Se fechou o editor, abra o editor do Cloud Shell no navegador acedendo a ide.cloud.google.com.

    1. No terminal, inicie o minikube:

      minikube start
      

      O minikube configura um cluster do Kubernetes local no Cloud Shell. Esta configuração demora alguns minutos a ser executada. Após a conclusão, o processo do minikube é executado em segundo plano na instância do Cloud Shell.

    2. No painel na parte inferior do editor do Cloud Shell, selecione Cloud Code.

    3. No painel estreito apresentado entre o terminal e o editor, selecione Executar no Kubernetes.

      Se vir uma mensagem com a indicação Use current context (minikube) to run the app?, clique em Sim.

      Este comando compila o código-fonte e executa testes. Esta ação pode demorar alguns minutos. Os testes incluem testes de unidades e um passo de validação pré-configurado que verifica as regras definidas para o ambiente de implementação. Isto garante que recebe um aviso sobre problemas de implementação mesmo enquanto trabalha no seu ambiente de desenvolvimento.

      O separador Output mostra o progresso do Skaffold à medida que cria e implementa a sua aplicação.

      Mantenha este separador aberto durante toda esta secção.

      Quando a compilação e os testes terminam, o separador Output indica Update succeeded, e mostra dois URLs.

      À medida que cria e testa a sua app, o Cloud Code transmite os registos e os URLs no separador Output. À medida que faz alterações e executa testes no ambiente de desenvolvimento, pode ver a versão da app do ambiente de desenvolvimento e verificar se está a funcionar corretamente.

      A saída também indica Watching for changes..., o que significa que o modo de visualização está ativado. Enquanto o Cloud Code estiver no modo de observação, o serviço deteta quaisquer alterações guardadas no seu repositório e recria e reimplementa automaticamente a app com as alterações mais recentes.

    4. No terminal do Cloud Code, mantenha o ponteiro sobre o primeiro URL na saída (http://localhost:8080).

    5. Na sugestão apresentada, selecione Abrir pré-visualização Web.

      Em segundo plano, o Cloud Code está a encaminhar automaticamente o tráfego para o serviço cicd-sample em execução no minikube.

    6. No navegador, atualize a página.

      O número junto a Contador aumenta, mostrando que a app está a responder à atualização.

      No navegador, mantenha esta página aberta para poder ver a aplicação à medida que faz alterações no seu ambiente local.

    Já criou e testou a sua aplicação no ambiente de desenvolvimento. Implementou a aplicação no cluster de desenvolvimento em execução no minikube e viu o comportamento da aplicação visível para o utilizador.

    Faça uma alteração

    Nesta secção, faz uma alteração à aplicação e vê a alteração à medida que a app é executada no cluster de desenvolvimento.

    1. No editor do Cloud Shell, abra o ficheiro index.html.

    2. Pesquise a string Sample App Info e altere-a para sample app info, para que o título passe a usar letras minúsculas.

      O ficheiro é guardado automaticamente, o que aciona uma recompilação do contentor da aplicação.

      O Cloud Code deteta a alteração e volta a implementá-la automaticamente. O separador Saída mostra Update initiated. Esta reimplementação demora alguns minutos a ser executada.

      Esta funcionalidade de nova implementação automática está disponível para qualquer aplicação em execução num cluster do Kubernetes.

    3. Quando a compilação estiver concluída, aceda ao navegador onde tem a app aberta e atualize a página.

      Quando atualizar, vê que o texto passa a usar letras minúsculas.

    Esta configuração oferece-lhe recarregamento automático para qualquer arquitetura, com quaisquer componentes. Quando usa o Cloud Code e o minikube, tudo o que está a ser executado no Kubernetes tem esta funcionalidade de recarregamento rápido de código.

    Pode depurar aplicações implementadas num cluster do Kubernetes no Cloud Code. Estes passos não são abordados neste guia de implementação, mas para ver detalhes, consulte o artigo Depurar uma aplicação Kubernetes.

    Confirme o código

    Agora que fez uma alteração à aplicação, pode confirmar o código.

    1. Configure a sua identidade do Git:

      git config --global user.email "YOU@EXAMPLE.COM"
      git config --global user.name "NAME"
      

      Substitua o seguinte:

      • YOU@EXAMPLE.COM: o endereço de email associado à sua conta do GitHub.
      • NAME: o nome associado à sua conta do GitHub.
    2. No terminal, confirme o código:

      git add .
      git commit -m "use lowercase for: sample app info"
      

      Não precisa de executar o comando git push aqui. Isso é mais tarde.

    No ambiente de desenvolvimento, fez uma alteração à aplicação, criou e testou a alteração, e validou o comportamento destas alterações para o utilizador. Os testes no ambiente de desenvolvimento incluem verificações de governação, que lhe permitem corrigir problemas que causam problemas no ambiente de produção.

    Neste guia de implementação, quando consolida o código no repositório principal, não passa por uma revisão de código. No entanto, uma revisão de código ou uma aprovação de alterações é um processo recomendado para o desenvolvimento de software.

    Para mais informações sobre as práticas recomendadas de aprovação de alterações, consulte o artigo Simplificar a aprovação de alterações.

    Implemente uma alteração na produção

    Nesta secção, atua como operador da aplicação e faz o seguinte:

    • Acionar o pipeline de CI/CD, que implementa o lançamento no ambiente de preparação.
    • Promova e aprove o lançamento para produção.

    Inicie o pipeline de CI/CD e implemente na fase de testes

    Nesta secção, inicia o pipeline de CI/CD invocando o acionador do Cloud Build. Este acionador é invocado sempre que uma alteração é confirmada no repositório principal. Também pode iniciar o sistema de CI com um acionador manual.

    1. No editor do Cloud Shell, execute o seguinte comando para acionar uma compilação:

      git push google
      

      Esta compilação inclui a alteração que fez a cicd-sample.

    2. Regresse ao painel de controlo do Cloud Build e veja que foi criada uma compilação.

    3. Clique em Running: cicd-sample - cicd-sample-main no registo de compilação à direita e procure o texto azul que indica o início e o fim de cada passo.

      O passo 0 mostra o resultado das instruções skaffold build e skaffold test do ficheiro cloudbuild.yaml. As tarefas de compilação e teste no Passo 0 (a parte de CI do pipeline) foram aprovadas, pelo que as tarefas de implementação do Passo 1 (a parte de CD do pipeline) são executadas.

      Este passo termina com a seguinte mensagem:

      Created Cloud Deploy rollout ROLLOUT_NAME in target staging

    4. Abra a página Pipelines de fornecimento do Cloud Deploy e clique no pipeline cicd-sample delivery.

      A aplicação está implementada na fase de testes, mas não na produção.

    5. Verifique se a aplicação está a funcionar com êxito na preparação:

      kubectl proxy --port 8001 --context gke_$(gcloud config get-value project)_us-central1_staging
      

      Este comando configura um proxy kubectl para aceder à aplicação.

    6. Aceda à aplicação a partir do Cloud Shell:

      1. No editor do Cloud Shell, abra um novo separador do terminal.

      2. Envie um pedido para localhost para incrementar um contador:

        curl -s http://localhost:8001/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter
        

        Pode executar este comando várias vezes e ver o valor do contador aumentar de cada vez.

        À medida que vê a app, repare que o texto que alterou está na versão da aplicação implementada na preparação.

      3. Feche este segundo separador.

      4. No primeiro separador, prima Control+C para parar o proxy.

    Acionou o acionador do Cloud Build para iniciar o processo de CI, que inclui a criação da aplicação, a respetiva implementação no ambiente de preparação e a execução de testes para verificar se a aplicação está a funcionar na preparação.

    O processo de CI é bem-sucedido quando o código é compilado e os testes são aprovados no ambiente de preparação. O êxito do processo de CI inicia o sistema de CD no Cloud Deploy.

    Promova o lançamento para produção

    Nesta secção, promove o lançamento da fase de testes para a produção. O destino de produção é pré-configurado para exigir aprovação, pelo que o aprova manualmente.

    Para a sua própria pipeline de CI/CD, é recomendável usar uma estratégia de implementação que inicie a implementação gradualmente antes de fazer uma implementação completa em produção. O lançamento gradual da implementação pode facilitar a deteção de problemas e, se necessário, restaurar um lançamento anterior.

    Para promover o lançamento para produção, faça o seguinte:

    1. Abra a vista geral dos pipelines de implementação do Cloud Deploy e selecione o pipeline cicd-sample.

    2. Promova a implementação da fase de testes para a produção. Para tal, faça o seguinte:

      1. No diagrama do pipeline na parte superior da página, clique no botão azul Promover na caixa de preparação.

      2. Na janela apresentada, clique no botão Promover na parte inferior.

      A implementação ainda não está em execução na produção. Está a aguardar a aprovação manual necessária.

    3. Aprovar manualmente a implementação:

      1. Na visualização do pipeline, clique no botão Rever entre as caixas de preparação e produção.

      2. Na janela apresentada, clique no botão Rever.

      3. Na janela seguinte, clique em Aprovar.

      4. Regresse à vista geral dos pipelines de fornecimento do Cloud Deploy e selecione o pipeline cicd-sample.

    4. Depois de a visualização da pipeline mostrar a caixa de produção a verde (o que significa uma implementação bem-sucedida), verifique se a aplicação está a funcionar em produção configurando um proxy kubectl que usa para aceder à aplicação:

      kubectl proxy --port 8002 --context gke_$(gcloud config get-value project)_us-central1_prod
      
    5. Aceda à aplicação a partir do Cloud Shell:

      1. No editor do Cloud Shell, abra um novo separador do terminal.

      2. Incrementar o contador:

        curl -s http://localhost:8002/api/v1/namespaces/default/services/cicd-sample:8080/proxy/ | grep -A 1 Counter
        

        Pode executar este comando várias vezes e ver o valor do contador aumentar de cada vez.

      3. Feche este segundo separador do terminal.

      4. No primeiro separador, prima Control+C para parar o proxy.

    Promoveu e aprovou a implementação de produção. A aplicação com a sua alteração recente está agora em produção.

    Limpar

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

    Opção 1: elimine o projeto

    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.

    Opção 2: elimine os recursos individuais

    1. Elimine o pipeline do Cloud Deploy:

      gcloud deploy delivery-pipelines delete cicd-sample --region=us-central1 --force
      
    2. Elimine o acionador do Cloud Build:

      gcloud beta builds triggers delete cicd-sample-main
      
    3. Elimine os clusters de preparação e produção:

      gcloud container clusters delete staging
      
      gcloud container clusters delete prod
      
    4. Elimine o repositório nos Cloud Source Repositories:

      gcloud source repos delete cicd-sample
      
    5. Elimine os contentores do Cloud Storage:

      gcloud storage rm -r gs://$(gcloud config get-value project)-gceme-artifacts/
      
      gcloud storage rm -r gs://$(gcloud config get-value project)_clouddeploy/
      
    6. Elimine o repositório no Artifact Registry:

      gcloud artifacts repositories delete cicd-sample-repo \
          --location us-central1
      

    O que se segue?