Desenvolver e implantar apps conteinerizados usando um pipeline de CI/CD

Last reviewed 2022-11-18 UTC

Neste tutorial, veja como configurar e usar um sistema de desenvolvimento, integração contínua (CI) e entrega contínua (CD) com um conjunto integrado de ferramentas do Google Cloud. Use esse sistema para desenvolver e implantar aplicativos no Google Kubernetes Engine (GKE).

Neste guia, mostramos como criar a arquitetura descrita no Pipeline de implantação para desenvolvimento e entrega de aplicativos em contêineres.

Este guia de implantação é destinado a desenvolvedores e operadores de software, e você desempenha os seguintes papéis à medida que o conclui:

  • Primeiro, você vai atuar como operador para configurar o pipeline de CI/CD. Os principais componentes desse pipeline são o Cloud Build, o Artifact Registry e o Cloud Deploy.
  • Depois, você vai atuar como desenvolvedor para alterar um aplicativo usando o Cloud Code. Ao atuar como desenvolvedor, você vai ver a experiência integrada que esse pipeline oferece.
  • Por fim, você vai atuar como operador e seguir as etapas para implantar um aplicativo na produção.

Para seguir este tutorial, você precisa saber executar comandos do gcloud no Google Cloud e implantar contêineres de aplicativos no GKE.

Arquitetura

O diagrama a seguir mostra os recursos usados neste guia de implantação:

Sistema de desenvolvimento e implantação com o Cloud Code, o Cloud Build, o Artifact Registry, o Cloud Deploy e o GKE

Para detalhes sobre os componentes usados nessa arquitetura, consulte Pipeline de implantação para desenvolvimento e entrega de aplicativos em contêineres.

Objetivos

Ao atuar como operador, você vai fazer o seguinte:

  • Configurar o pipeline de CI e o de CD. Essa configuração inclui:
    • Configurar as permissões necessárias.
    • Criar os clusters do GKE para os ambientes de preparo e de produção.
    • Criar um repositório no Cloud Source Repositories para o código-fonte.
    • Criar um repositório no Artifact Registry para o contêiner do aplicativo.
    • Criar um gatilho do Cloud Build no repositório principal do GitHub.
    • Criar um pipeline de entrega do Cloud Deploy e os destinos. Os destinos são o ambiente de preparo e de produção.
  • Iniciar o processo de CI/CD para implantar no preparo e depois promover para a produção.

Como desenvolvedor, você vai fazer uma alteração no aplicativo. Para isso, faça o seguinte:

  • Clone o repositório para trabalhar com um ambiente de desenvolvimento pré-configurado.
  • Faça uma alteração no aplicativo no espaço de trabalho do desenvolvedor.
  • Crie e teste a alteração. Os testes incluem um teste de validação para governança.
  • Visualize e valide a alteração em um cluster de desenvolvimento. Esse cluster é executado no minikube.
  • Confirme a alteração no repositório principal.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Make sure 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.

    Enable the APIs

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

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

Preparar o ambiente

Nesta seção, você vai atuar como o operador do aplicativo e fazer o seguinte:

  • Configurar as permissões necessárias.
  • Criar os clusters do GKE para os ambientes de preparo e de produção.
  • Clonar o repositório de origem.
  • Criar um repositório no Cloud Source Repositories para o código-fonte.
  • Criar um repositório no Artifact Registry para o aplicativo do contêiner.

Configurar permissões

Nesta seção, você vai conceder as permissões necessárias para configurar o pipeline de CI/CD.

  1. Se você estiver trabalhando em uma nova instância do editor do Cloud Shell, especifique o projeto a ser usado neste tutorial:

    gcloud config set project PROJECT_ID
    

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

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

  2. Verifique se a conta de serviço padrão do Compute Engine tem permissões suficientes para executar jobs no Cloud Deploy e extrair contêineres do Artifact Registry. O Cloud Build e o Cloud Deploy usam essa conta de serviço padrão.

    A conta de serviço já pode ter as permissões necessárias. Essa etapa garante que as permissões necessárias sejam concedidas aos projetos que desativam as concessões automáticas de papéis para contas de serviço padrão.

    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 de conta de serviço do Cloud Build para invocar implantaçõ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 esse papel do IAM, consulte o papel clouddeploy.operator.

  4. Conceda o privilégio de conta de serviço do Cloud Build e do Cloud Deploy para o 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 sobre esse papel do IAM, consulte o papel container.admin.

  5. Conceda à conta de serviço do Cloud Build as permissõ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, ele usa uma conta de serviço do Compute Engine para criar uma versão, o que torna esta permissão necessária.

    Para mais detalhes sobre esse papel do IAM, consulte o papel iam.serviceAccountUser.

Você já concedeu as permissões necessárias para o pipeline de CI/CD.

Criar os clusters do GKE

Nesta seção, você vai criar os ambientes de preparo e de produção, que são clusters do GKE. Não é necessário configurar o cluster de desenvolvimento aqui, porque ele usa o minikube.

  1. Crie os clusters do GKE de preparo e de 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 preparo é o local em que você testa as alterações no código. Depois de verificar se a implantação no preparo não afetou negativamente o aplicativo, implante na produção.

  2. Execute o seguinte comando e verifique se a saída tem STATUS: RUNNING para os clusters de preparo e de produção:

    gcloud container clusters list
    
  3. Recupere as credenciais para os arquivos kubeconfig dos clusters de preparo e de produção.

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

    Use essas credenciais para interagir com os clusters do GKE, como verificar se um aplicativo está sendo executado corretamente.

Você criou os clusters do GKE para os ambientes de preparo e de produção.

Abrir o ambiente de desenvolvimento integrado e clonar o repositório

Para clonar o repositório e visualizar o aplicativo no ambiente de desenvolvimento, faça o seguinte:

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

    Abrir no Cloud Shell

  2. Clique em Confirmar.

    O editor do Cloud Shell abre e clona o repositório de amostra.

    Agora você pode ver o código do aplicativo no editor do Cloud Shell.

  3. Especifique o projeto que será usado neste guia de implantação:

    gcloud config set project PROJECT_ID
    

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

Agora você tem o código-fonte do aplicativo no ambiente de desenvolvimento.

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

Criar repositórios para o código-fonte e os contêineres

Nesta seção, você vai configurar um repositório no Cloud Source Repositories para o código-fonte e outro no Artifact Registry para armazenar os contêineres criados pelo pipeline de CI/CD.

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

    gcloud source repos create cicd-sample
    
  2. Verifique se as configurações do Cloud Deploy se destinam ao 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 você tem um repositório para o código-fonte no Cloud Source Repositories e outro para o contêiner do aplicativo no Artifact Registry. O repositório do Cloud Source Repositories permite clonar e conectar o código-fonte ao pipeline de CI/CD.

Configurar o pipeline de CI/CD

Nesta seção, você vai atuar como o operador do aplicativo e configurar o pipeline de CI/CD. O pipeline usa o Cloud Build para CI e o Cloud Deploy para CD. As etapas do pipeline são definidas no gatilho do Cloud Build.

  1. Crie um bucket do Cloud Storage para o Cloud Build para armazenar o arquivo artifacts.json, que rastreia os artefatos gerados pelo Skaffold para cada build:

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

    Armazenar o arquivo artifacts.json de cada build em um ponto central é uma prática recomendada, porque fornece rastreabilidade, o que facilita a solução de problemas.

  2. Analise o arquivo cloudbuild.yaml, que define o gatilho do Cloud Build e já está configurado no repositório de origem clonado.

    Esse arquivo define o gatilho invocado sempre que há um novo envio para a ramificação principal do repositório de código-fonte.

    As etapas a seguir para o pipeline de CI/CD são definidas no arquivo cloudbuild.yaml:

    • O Cloud Build usa o Skaffold para criar o contêiner do aplicativo.

    • O Cloud Build coloca o arquivo artifacts.json do build no bucket do Cloud Storage.

    • O Cloud Build coloca o contêiner do aplicativo no Artifact Registry.

    • O Cloud Build executa testes no contêiner do aplicativo.

    • O comando gcloud deploy apply registra os seguintes arquivos com o serviço Cloud Deploy:

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

      Quando os arquivos são registrados, o Cloud Deploy cria o pipeline e os destinos, se ainda não existirem, ou os recria se a configuração mudou. Os destinos são os ambientes de preparo e de produção.

    • O Cloud Deploy cria uma nova versão para o pipeline de entrega.

      Essa versão faz referência ao contêiner do aplicativo que foi criado e testado no processo de CI.

    • O Cloud Deploy implanta a versão no ambiente de preparo.

    O pipeline de entrega e os destinos são gerenciados pelo Cloud Deploy e são separados do código-fonte. Essa separação significa que você não precisa atualizar o pipeline de entrega e os arquivos de destino quando é feita uma alteração no código-fonte do aplicativo.

  3. Crie o gatilho 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 gatilho instrui o Cloud Build a observar o repositório de origem e a usar o arquivo cloudbuild.yaml para reagir a qualquer alteração no repositório. O gatilho é invocado sempre que há um novo envio para a ramificação principal.

  4. Acesse a página de visão geral do Cloud Functions no console do Google Cloud.

    Acessar o Cloud Build

    Observe que não há compilações para seu aplicativo.

Você configurou os pipelines de CI e CD e criou um gatilho na ramificação principal do repositório.

Fazer uma alteração no aplicativo no espaço de trabalho do desenvolvedor

Nesta seção, você vai atuar como o desenvolvedor do aplicativo.

À medida que desenvolve o aplicativo, você faz e verifica alterações iterativas usando o Cloud Code como espaço de trabalho de desenvolvimento:

  • Faça uma alteração no aplicativo.
  • Crie e teste o novo código.
  • Implante o aplicativo no cluster do minikube e verifique as alterações voltadas para o usuário.
  • Envie a alteração para o repositório principal.

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

Criar, testar e executar o aplicativo

Nesta seção, você vai criar, testar, implantar e acessar o aplicativo.

Use a mesma instância do editor do Cloud Shell da seção anterior. Se o tiver fechado, abra o editor do Cloud Shell no navegador em ide.cloud.google.com.

  1. No terminal, inicie o minikube:

    minikube start
    

    O minikube configura um cluster local do Kubernetes no seu Cloud Shell. Essa configuração leva alguns minutos para 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 fino que aparece entre o terminal e o editor, selecione Executar no Kubernetes.

    Se você vir uma solicitação Use current context (minikube) to run the app?, clique em Sim.

    Esse comando cria o código-fonte e executa testes. Isso pode levar alguns minutos. Eles incluem testes de unidade e uma etapa de validação pré-configurada que verifica as regras definidas para o ambiente de implantação. Isso faz com que você receba avisos sobre problemas de implantação enquanto ainda está trabalhando no ambiente de desenvolvimento.

    A guia Saída mostra o progresso do Skaffold durante a criação e a implantação do aplicativo.

    Deixe essa guia aberta nesta seção.

    Quando o build e os testes terminarem, a guia Saída vai mostrar Update succeeded e também dois URLs.

    À medida que você cria e testa o aplicativo, o Cloud Code faz o streaming dos registros e URLs na guia Saída. Ao fazer alterações e executar testes no ambiente de desenvolvimento, é possível ver a versão do aplicativo nesse ambiente e verificar se ele está funcionando corretamente.

    A saída também mostra Watching for changes..., ou seja, o modo de observação está ativado. Enquanto o Cloud Code estiver no modo de observação, o serviço vai detectar todas as alterações salvas no seu repositório, bem como recriar e reimplantar automaticamente o aplicativo com as alterações mais recentes.

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

  5. Na dica exibida, selecione Abrir visualização na Web.

    Em segundo plano, o Cloud Code automaticamente faz o encaminhamento de portas do tráfego para o serviço cicd-sample em execução no minikube.

  6. No navegador, atualize a página.

    O número ao lado de Contador aumenta, mostrando que o aplicativo está respondendo à atualização.

    No navegador, mantenha esta página aberta para ver o aplicativo enquanto você faz alterações no ambiente local.

Você criou e testou seu aplicativo no ambiente de desenvolvimento. Você implantou o aplicativo no cluster de desenvolvimento em execução no minikube e viu o comportamento voltado para o usuário do aplicativo.

Faça uma alteração

Nesta seção, você vai fazer uma alteração no aplicativo e ver a alteração à medida que o aplicativo é executado no cluster de desenvolvimento.

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

  2. Procure e altere a string Sample App Info para sample app info, para que o título fique em letras minúsculas.

    O arquivo é salvo automaticamente, acionando uma recriação do contêiner do aplicativo.

    O Cloud Code detecta a alteração e a reimplanta automaticamente. A guia Saída mostra Update initiated. A reimplantação leva alguns minutos para ser executada.

    Esse recurso de reimplantação automática está disponível para qualquer aplicativo em execução em um cluster do Kubernetes.

  3. Quando a criação estiver concluída, acesse o navegador em que o aplicativo está aberto e atualize a página.

    Ao atualizar, observe que o texto agora está em letras minúsculas.

Essa configuração permite o recarregamento automático de qualquer arquitetura, com qualquer componente. Ao usar o Cloud Code e o minikube, tudo o que é executado no Kubernetes tem essa funcionalidade de recarga dinâmica de código.

É possível depurar aplicativos implantados em um cluster do Kubernetes no Cloud Code. Essas etapas não são abordadas neste guia de implantação, mas para detalhes, consulte Como depurar um aplicativo do Kubernetes.

Confirmar o código

Agora que você fez uma alteração no aplicativo, confirme o código.

  1. Configure a identidade do Git:

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

    Substitua:

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

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

    Não é necessário executar o comando git push agora. Isso será feito depois.

Ao trabalhar no ambiente de desenvolvimento, você fez uma alteração no aplicativo, criou e testou a alteração e verificou o comportamento voltado para o usuário dessas alterações. Os testes no ambiente de desenvolvimento incluem verificações de governança, que permitem corrigir problemas no ambiente de produção.

Neste tutorial, ao confirmar o código no repositório principal, você não vai precisar fazer uma revisão de código. No entanto, a revisão de código ou a aprovação de alterações são processos recomendados no desenvolvimento de software.

Saiba mais sobre as práticas recomendadas para a aprovação de alterações em Como otimizar a aprovação de alterações.

Implantar uma alteração na produção

Nesta seção, você vai atuar como o operador do aplicativo e fazer o seguinte:

  • Acionar o pipeline de CI/CD, que implanta a versão no ambiente de preparo.
  • Promover e aprovar a versão para a produção.

Iniciar o pipeline de CI/CD e implantar no preparo

Nesta seção, você vai iniciar o pipeline de CI/CD invocando o gatilho do Cloud Build. Esse gatilho é invocado sempre que uma alteração é confirmada no repositório principal. Também é possível iniciar o sistema de CI com um gatilho manual.

  1. No editor do Cloud Shell, execute o seguinte comando para acionar um build:

    git push google
    

    Este build inclui a alteração feita em cicd-sample.

  2. Volte para o painel do Cloud Build e veja se um build foi criado.

  3. Clique em Em execução: cicd-sample - cicd-sample-main no registro do build à direita e procure o texto azul que indica o início e o fim de cada etapa.

    A Etapa 0 mostra a saída das instruções skaffold build e skaffold test do arquivo cloudbuild.yaml. As tarefas de criação e teste da Etapa 0 (a parte de CI do pipeline) foram aprovadas. Portanto, as tarefas de implantação da Etapa 1 (a parte de CD do pipeline) passam a ser executadas.

    Esta etapa termina com a seguinte mensagem:

    Created Cloud Deploy rollout ROLLOUT_NAME in target staging

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

    O aplicativo é implantado no preparo, mas não na produção.

  5. Verifique se o aplicativo está funcionando no preparo:

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

    Esse comando configura um proxy do kubectl para acessar o aplicativo.

  6. Acesse o aplicativo no Cloud Shell:

    1. No editor do Cloud Shell, abra uma nova guia do terminal.

    2. Envie uma solicitação para localhost se quiser aumentar um contador:

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

      É possível executar esse comando várias vezes e observar o incremento do valor do contador a cada vez.

      Ao visualizar o aplicativo, observe que o texto alterado está na versão do aplicativo que você implantou no preparo.

    3. Feche essa segunda guia.

    4. Na primeira guia, pressione Control+C para interromper o proxy.

Agora você invocou o gatilho do Cloud Build para iniciar o processo de CI, que inclui criar o aplicativo, fazer a implantação no ambiente de preparo e executar testes para verificar se o aplicativo está funcionando no preparo.

O processo de CI é bem-sucedido quando o código é criado e aprovado em testes no ambiente de preparo. Em seguida, o processo de CI inicia o sistema de CD no Cloud Deploy.

Promover a versão para a produção

Nesta seção, você vai promover a versão do preparo para a produção. O destino de produção vem pré-configurado para exigir aprovação. Portanto, faça a aprovação manualmente.

Para seu próprio pipeline de CI/CD, é bom usar uma estratégia que inicie a implantação gradualmente antes de fazer uma implantação completa na produção. Iniciar a implantação gradualmente pode facilitar a detecção de problemas e, se necessário, a restauração de uma versão anterior.

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

  1. Abra a visão geral dos pipelines de entrega do Cloud Deploy e selecione o pipeline cicd-sample.

  2. Promova a implantação do preparo para a produção. Para isso, siga estas etapas:

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

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

    A implantação ainda não está em execução na produção. Ela está aguardando a aprovação manual necessária.

  3. Aprove manualmente a implantação:

    1. Na visualização do pipeline, clique no botão Revisar entre as caixas do preparo e da produção.

    2. Na janela exibida, clique no botão Revisar.

    3. Na janela seguinte, clique em Aprovar.

    4. Volte à visão geral dos pipelines de entrega do Cloud Deploy e selecione o pipeline cicd-sample.

  4. Depois que a visualização do pipeline mostrar a caixa da produção como verde (o que significa um lançamento bem-sucedido), verifique se o aplicativo está funcionando na produção configurando um proxy do kubectl usado para acessar o aplicativo:

    kubectl proxy --port 8002 --context gke_$(gcloud config get-value project)_us-central1_prod
    
  5. Acesse o aplicativo no Cloud Shell:

    1. No editor do Cloud Shell, abra uma nova guia do terminal.

    2. Aumente o contador:

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

      É possível executar esse comando várias vezes e observar o incremento do valor do contador a cada vez.

    3. Feche essa segunda guia do terminal.

    4. Na primeira guia, pressione Control+C para interromper o proxy.

Você promoveu e aprovou a implantação na produção. O aplicativo com a alteração recente está sendo executado na produção.

Limpar

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que contém eles ou mantenha o projeto e exclua os recursos individuais.

Opção 1: excluir 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: excluir os recursos individuais

  1. Exclua o pipeline do Cloud Deploy:

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

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

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

    gcloud source repos delete cicd-sample
    
  5. Exclua os buckets 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. Exclua o repositório no Artifact Registry:

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

A seguir