CI/CD moderno com o GKE: crie um sistema de CI/CD

Esta arquitetura de referência oferece-lhe um método e uma infraestrutura iniciais para criar um sistema de integração contínua/implementação contínua (IC/DC) moderno através de ferramentas como o Google Kubernetes Engine, o Cloud Build, o Skaffold, o kustomize, o Config Sync, o Policy Controller, o Artifact Registry e o Cloud Deploy.

Este documento faz parte de uma série:

Este documento destina-se a arquitetos empresariais e programadores de aplicações, bem como a equipas de segurança de TI, DevOps e engenharia de fiabilidade do site. Alguma experiência com ferramentas e processos de implementação automatizados é útil para compreender os conceitos neste documento.

Fluxo de trabalho de CI/CD

Para criar um sistema de CI/CD moderno, primeiro tem de escolher ferramentas e serviços que executem as funções principais do sistema. Esta arquitetura de referência foca-se na implementação das funções essenciais de um sistema de CI/CD que são apresentadas no seguinte diagrama:

Várias equipas gerem ou partilham a responsabilidade pelo sistema de CI/CD.

Esta implementação de referência usa as seguintes ferramentas para cada componente:

  • Para a gestão de código fonte: GitHub
    • Armazena o código de configuração e da aplicação.
    • Permite-lhe rever as alterações.
  • Para a gestão da configuração de aplicações: kustomize
    • Define a configuração pretendida de uma aplicação.
    • Permite-lhe reutilizar e expandir primitivas ou esquemas de configuração.
  • Para integração contínua: Cloud Build
    • Testa e valida o código-fonte.
    • Cria artefactos que o ambiente de implementação consome.
  • Para a entrega contínua: Cloud Deploy
    • Define o processo de implementação de código em vários ambientes.
    • Oferece reversão para alterações com falhas.
  • Para a configuração da infraestrutura: Config Sync
    • Aplica de forma consistente a configuração do cluster e da política.
  • Para a aplicação de políticas: Policy Controller
    • Fornece um mecanismo que pode usar para definir o que é permitido executar num determinado ambiente com base nas políticas da organização.
  • Para a orquestração de contentores: Google Kubernetes Engine
    • Executa os artefactos criados durante a CI.
    • Oferece metodologias de dimensionamento, verificação de funcionamento e implementação para cargas de trabalho.
  • Para artefactos de contentores: Artifact Registry
    • Armazena os artefactos (imagens de contentores) criados durante a CI.

Arquitetura

Esta secção descreve os componentes de CI/CD que implementa através desta arquitetura de referência: infraestrutura, pipelines, repositórios de código e zonas de destino.

Para uma discussão geral destes aspetos do sistema de CI/CD, consulte o artigo CI/CD moderno com o GKE: uma framework de entrega de software.

Variantes da arquitetura de referência

A arquitetura de referência tem dois modelos de implementação:

  • Uma variante de vários projetos mais semelhante a uma implementação de produção com limites de isolamento melhorados
  • Uma variante de projeto único, útil para demonstrações

Arquitetura de referência com vários projetos

A versão multi-project da arquitetura de referência simula cenários semelhantes aos de produção. Nestes cenários, diferentes personagens fictícias criam infraestruturas, pipelines de CI/CD e aplicações com limites de isolamento adequados. Estas personas ou equipas só podem aceder aos recursos necessários.

Para mais informações, consulte o artigo CI/CD moderno com o GKE: uma framework de entrega de software.

Para ver detalhes sobre como instalar e aplicar esta versão da arquitetura de referência, consulte o projeto de entrega de software

Arquitetura de referência de projeto único

A versão single-project da arquitetura de referência demonstra como configurar toda a plataforma de fornecimento de software num único projeto Google Cloud . Esta versão pode ajudar todos os utilizadores que não tenham funções de IAM elevadas a instalar e experimentar a arquitetura de referência apenas com a função de proprietário num projeto. Este documento demonstra a versão de projeto único da arquitetura de referência.

Infraestrutura da plataforma

A infraestrutura desta arquitetura de referência consiste em clusters do Kubernetes para suportar ambientes de aplicações de desenvolvimento, preparação e produção. O diagrama seguinte mostra a disposição lógica dos clusters:

O esquema de cluster suporta diferentes cargas de trabalho da plataforma.

Repositórios de código

Com esta arquitetura de referência, configura repositórios para operadores, programadores, plataforma e engenheiros de segurança.

O diagrama seguinte mostra a implementação da arquitetura de referência dos diferentes repositórios de código e como as equipas de operações, desenvolvimento e segurança interagem com os repositórios:

Os repositórios incluem os das práticas recomendadas, bem como os da configuração da aplicação e da plataforma.

Neste fluxo de trabalho, os seus operadores podem gerir as práticas recomendadas para CI/CD e a configuração da aplicação no repositório do operador. Quando os seus programadores incorporam aplicações no repositório de desenvolvimento, recebem automaticamente práticas recomendadas, lógica empresarial para a aplicação e qualquer configuração especializada necessária para que a aplicação funcione corretamente. Entretanto, a sua equipa de operações e segurança pode gerir a consistência e a segurança da plataforma nos repositórios de configuração e políticas.

Zonas de destino da aplicação

Nesta arquitetura de referência, a zona de destino de uma aplicação é criada quando a aplicação é aprovisionada. No documento seguinte desta série, CI/CD moderno com o GKE: aplique o fluxo de trabalho do programador, vai aprovisionar uma nova aplicação que cria a sua própria zona de destino. O diagrama seguinte ilustra os componentes importantes das zonas de destino usadas nesta arquitetura de referência:

O cluster do GKE inclui três espaços de nomes para diferentes aplicações.

Cada espaço de nomes inclui uma conta de serviço que é usada para a Workload Identity Federation para o GKE aceder a serviços fora do contentor do Kubernetes, como o Cloud Storage ou o Spanner. O espaço de nomes também inclui outros recursos, como políticas de rede, para isolar ou partilhar limites com outros espaços de nomes ou aplicações.

O espaço de nomes é criado pela conta de serviço de execução de CD. Recomendamos que as equipas sigam o princípio do menor privilégio para ajudar a garantir que uma conta de serviço de execução de CD só pode aceder aos espaços de nomes necessários.

Pode definir o acesso da conta de serviço no Config Sync e implementá-lo através de funções e associações de funções de controlo de acesso baseado em funções (CABF) do Kubernetes. Com este modelo implementado, as equipas podem implementar quaisquer recursos diretamente nos espaços de nomes que gerem, mas são impedidas de substituir ou eliminar recursos de outros espaços de nomes.

Objetivos

  • Implemente a arquitetura de referência de projeto único.
  • Explore os repositórios de código.
  • Explore o pipeline e a infraestrutura.

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. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    Implemente a arquitetura de referência

    1. No Cloud Shell, defina o projeto:

      gcloud config set core/project PROJECT_ID

      Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

    2. No Cloud Shell, clone o repositório Git:

      git clone https://github.com/GoogleCloudPlatform/software-delivery-blueprint.git
cd software-delivery-blueprint/launch-scripts
git checkout single-project-blueprint

    3. Crie um token de acesso pessoal no GitHub com os seguintes âmbitos:

      • repo
      • delete_repo
      • admin:org
      • admin:repo_hook

    4. Existe um ficheiro vazio denominado vars.sh na pasta software-delivery-bluprint/launch-scripts. Adicione o seguinte conteúdo ao ficheiro: 

      cat << EOF >vars.sh
export INFRA_SETUP_REPO="gke-infrastructure-repo"
export APP_SETUP_REPO="application-factory-repo"
export GITHUB_USER=GITHUB_USER
export TOKEN=TOKEN
export GITHUB_ORG=GITHUB_ORG
export REGION="us-central1"
export SEC_REGION="us-west1"
export TRIGGER_TYPE="webhook"
EOF

      Substitua GITHUB_USER pelo nome de utilizador do GitHub.

      Substitua TOKEN pelo token de acesso pessoal do GitHub.

      Substitua GITHUB_ORG pelo nome da organização do GitHub.

    5. Execute o bootstrap.shscript. Se o Cloud Shell lhe pedir autorização, clique em Autorizar:

      ./bootstrap.sh

      O script inicia a plataforma de entrega de software.

    Explore os repositórios de código

    Nesta secção, explora os repositórios de código.

    Inicie sessão no GitHub

    1. Num navegador de Internet, aceda a github.com e inicie sessão na sua conta.
    2. Clique no ícone de imagem na parte superior da interface.
    3. Clique em As suas organizações.
    4. Escolha a organização que indicou como entrada no ficheiro vars.sh.
    5. Clique no separador Repositórios.

    Explore os repositórios de arranque, operador, configuração e infraestrutura

    Os repositórios de arranque, operador, configuração e infraestrutura são onde os operadores e os administradores da plataforma definem as práticas recomendadas comuns para criar e operar a plataforma. Estes repositórios são criados na sua organização do GitHub quando a arquitetura de referência é inicializada.

    Cada repositório na lista inclui uma breve descrição.

    Repositórios iniciais

    Os repositórios iniciais ajudam na adoção de práticas recomendadas de CI/CD, infraestrutura e desenvolvimento na plataforma. Para mais informações, consulte o artigo CI/CD moderno com o GKE: uma framework de fornecimento de software

    Repositórios de iniciação de aplicações

    Nos repositórios de arranque de aplicações, os seus operadores podem codificar e documentar as práticas recomendadas, como CI/CD, recolha de métricas, registo, passos de contentores e segurança para aplicações. A arquitetura de referência inclui exemplos de repositórios iniciais para aplicações Go, Python e Java.

    Os repositórios de arranque de aplicações app-template-python, app-template-java e app-template-golang contêm código padrão que pode usar para criar novas aplicações. Além de criar novas aplicações, pode criar novos modelos com base nos requisitos das aplicações. Os repositórios de arranque de aplicações fornecidos pela arquitetura de referência contêm:

    • kustomize base e patches na pasta k8s.

    • Código-fonte da aplicação.

    • Um Dockerfile que descreve como criar e executar a aplicação.

    • Um ficheiro cloudbuild.yaml que descreve as práticas recomendadas para os passos de CI.

    • Um ficheiro skaffold.yaml que descreve os passos de implementação.

    No documento seguinte desta série, CI/CD moderno com o GKE: aplique o fluxo de trabalho do programador, vai usar o repositório app-template-python para criar uma nova aplicação.

    Repositórios de iniciação de infraestrutura

    Nos repositórios de arranque da infraestrutura, os seus operadores e administradores de infraestrutura podem codificar e documentar as práticas recomendadas, como pipelines de CI/CD, IaC, recolha de métricas, registo e segurança para a infraestrutura. A arquitetura de referência inclui exemplos de repositórios iniciais de infraestrutura que usam o Terraform. O repositório inicial de infraestrutura infra-template contém código padrão para o Terraform que pode usar para criar os recursos de infraestrutura de que uma aplicação precisa, como um contentor do Cloud Storage, uma base de dados do Spanner ou outros.

    Repositórios de modelos partilhados

    Nos repositórios de modelos partilhados, os administradores e os operadores de infraestrutura fornecem modelos padrão para realizar tarefas. Existe um repositório denominado terraform-modules fornecido com a arquitetura de referência. O repositório inclui código do Terraform baseado em modelos para criar vários recursos de infraestrutura.

    Repositórios de operadores

    Na arquitetura de referência, os repositórios do operador são iguais aos repositórios de arranque da aplicação. Os operadores gerem os ficheiros necessários para a CI e a CD nos repositórios de arranque da aplicação. A arquitetura de referência inclui os repositórios app-template-python, app-template-java e app-template-golang.

    • Estes são modelos de iniciação e contêm os manifestos base do Kubernetes para as aplicações em execução no Kubernetes na plataforma. Os operadores podem atualizar os manifestos nos modelos iniciais conforme necessário. As atualizações são recolhidas quando é criada uma candidatura.
    • Os ficheiros cloudbuild.yaml e skaffold.yaml nestes repositórios armazenam as práticas recomendadas para executar a CI e a CD, respetivamente, na plataforma. Semelhante às configurações da aplicação, os operadores podem atualizar e adicionar passos às práticas recomendadas. Os pipelines de candidatura individuais são criados com os passos mais recentes.

    Nesta implementação de referência, os operadores usam kustomize para gerir as configurações base na pasta k8s dos repositórios iniciais. Em seguida, os programadores podem expandir os manifestos com alterações específicas da aplicação, como nomes de recursos e ficheiros de configuração. A ferramenta kustomize suporta a configuração como dados. Com esta metodologia, as kustomize entradas e saídas são recursos do Kubernetes. Pode usar as saídas de uma modificação dos manifestos para outra modificação.

    O diagrama seguinte ilustra uma configuração base para uma aplicação Spring Boot:

    A configuração da aplicação é feita em vários repositórios geridos por equipas separadas.

    A configuração como modelo de dados no kustomize tem uma grande vantagem: quando os operadores atualizam a configuração base, as atualizações são automaticamente consumidas pela pipeline de implementação do programador na próxima execução, sem alterações por parte do programador.

    Para mais informações sobre como usar o kustomize para gerir manifestos do Kubernetes, consulte a kustomize documentação.

    Repositórios de configuração e políticas

    A arquitetura de referência inclui uma implementação de um repositório de configuração e políticas que usa o Config Sync e o Policy Controller. O repositório acm-gke-infrastructure-repo contém a configuração e as políticas que implementa nos clusters do ambiente da aplicação. A configuração definida e armazenada pelos administradores da plataforma nestes repositórios é importante para garantir que a plataforma tem um aspeto consistente para as equipas de operações e desenvolvimento.

    As secções seguintes abordam a forma como a arquitetura de referência implementa os repositórios de configuração e políticas mais detalhadamente.

    Configuração

    Nesta implementação de referência, usa o Config Sync para gerir centralmente a configuração dos clusters na plataforma e aplicar políticas. A gestão centralizada permite propagar alterações de configuração em todo o sistema.

    Com a Config Sync, a sua organização pode registar os respetivos clusters para sincronizar a configuração a partir de um repositório Git, um processo conhecido como GitOps. Quando adiciona novos clusters, estes são sincronizados automaticamente com a configuração mais recente e reconciliam continuamente o estado do cluster com a configuração, caso alguém introduza alterações fora da banda.

    Para mais informações sobre o Config Sync, consulte a respetiva documentação.

    Política

    Nesta implementação de referência, usa o Policy Controller, que se baseia no Open Policy Agent, para intercetar e validar cada pedido aos clusters do Kubernetes na plataforma. Pode criar políticas através da linguagem de políticas Rego, que lhe permite controlar totalmente não só os tipos de recursos enviados para o cluster, mas também a respetiva configuração.

    A arquitetura no diagrama seguinte mostra um fluxo de pedidos para usar o Policy Controller para criar um recurso:

    Uma regra de política é primeiro definida e, em seguida, aplicada através de várias ferramentas, como o kubectl e os clientes de API.

    Cria e define regras no repositório do Config Sync, e estas alterações são aplicadas ao cluster. Depois disso, os novos pedidos de recursos dos clientes da CLI ou da API são validados em função das restrições pelo Policy Controller.

    Para mais informações sobre a gestão de políticas, consulte a Vista geral do Policy Controller.

    Repositórios de infraestrutura

    A referência inclui uma implementação de um repositório de infraestrutura através do Terraform. O repositório gke-infrastructure-repo contém infraestrutura como código para criar clusters do GKE para ambientes de desenvolvimento, preparação e produção, e configurar o Config Sync neles através do repositório acm-gke-infrastructure-repo. gke-infrastructure-repo contém três ramificações, uma para cada ambiente de desenvolvimento, teste e produção. Também contém pastas de desenvolvimento, teste e produção em cada ramificação.

    Explore o pipeline e a infraestrutura

    A arquitetura de referência cria um pipeline no Google Cloud projeto. Este pipeline é responsável pela criação da infraestrutura partilhada.

    Fornecimento

    Nesta secção, explora o pipeline de infraestrutura como código e executa-o para criar a infraestrutura partilhada, incluindo clusters do GKE. O pipeline é um acionador do Cloud Build denominado create-infra no projeto Google Cloud que está associado ao repositório de infraestrutura gke-infrastructure-repo. Segue a metodologia GitOps para criar infraestrutura, conforme explicado no vídeo Ambientes da GCP repetíveis em grande escala com pipelines de infraestrutura como código do Cloud Build.

    gke-infrastructure-repo tem ramos de desenvolvimento, preparação e produção. No repositório, também existem pastas de desenvolvimento, preparação e produção que correspondem a estes ramos. Existem regras de proteção de ramificações no repositório que garantem que o código só pode ser enviado para a ramificação de desenvolvimento. Para enviar o código para os ramos de preparação e produção, tem de criar um pedido de obtenção.

    Normalmente, alguém com acesso ao repositório revê as alterações e, em seguida, une o pedido de envio para garantir que apenas as alterações pretendidas são promovidas para o ramo superior. Para permitir que os indivíduos experimentem o esquema, as regras de proteção de ramificações foram flexibilizadas na arquitetura de referência para que o administrador do repositório possa ignorar a revisão e unir o pedido de envio.

    Quando é feito um envio para gke-infrastructure-repo, é invocado o acionador create-infra. Esse acionador identifica a ramificação onde o envio ocorreu e acede à pasta correspondente no repositório nessa ramificação. Assim que encontra a pasta correspondente, executa o Terraform através dos ficheiros que a pasta contém. Por exemplo, se o código for enviado para o ramo de desenvolvimento, o acionador executa o Terraform na pasta de desenvolvimento do ramo de desenvolvimento para criar um cluster GKE de desenvolvimento. Da mesma forma, quando é feito um push para o ramo staging, o acionador executa o Terraform na pasta de preparação do ramo de preparação para criar um cluster GKE de preparação.

    Execute o pipeline para criar clusters do GKE:

    1. Na Google Cloud consola, aceda à página Cloud Build.

      Aceda à página do Cloud Build

      • Existem cinco acionadores de webhook do Cloud Build. Procure o acionador com o nome create-infra. Este acionador cria a infraestrutura partilhada, incluindo clusters do GKE.

    2. Clique no nome do acionador. É aberta a definição do acionador.

    3. Clique em ABRIR EDITOR para ver os passos que o acionador executa.

      Os outros acionadores são usados quando integra uma aplicação em CI/CD moderno com o GKE: aplique o fluxo de trabalho do programador

      Acionadores do Cloud Build.

    4. Na Google Cloud consola, aceda à página Cloud Build.

      Aceda à página do histórico do Cloud Build

      Reveja o pipeline presente na página do histórico. Quando implementou a plataforma de entrega de software através do bootstrap.sh, o script enviou o código para o ramo de desenvolvimento do repositório gke-infrastructure-repo que iniciou este pipeline e criou o cluster GKE de desenvolvimento.

    5. Para criar um cluster GKE de preparação, envie um pedido de obtenção do ramo de desenvolvimento para o ramo de preparação:

      1. Aceda ao GitHub e navegue para o repositório gke-infrastructure-repo.

      2. Clique em Pedidos de obtenção e, de seguida, em Novo pedido de obtenção.

      3. No menu Base, escolha staging e, no menu Comparar, escolha dev.

      4. Clique em Criar pedido de obtenção.

    6. Se for administrador do repositório, junte o pedido de envio. Caso contrário, peça ao administrador para unir o pedido de obtenção.

    7. Na Google Cloud consola, aceda à página Histórico do Cloud Build.

      Aceda à página do histórico do Cloud Build

      É iniciada uma segunda pipeline do Cloud Build no projeto. Este pipeline cria o cluster do GKE de preparação.

    8. Para criar clusters do GKE de produção, envie um pull request do ramo de preparação para o ramo de produção:

      1. Aceda ao GitHub e navegue para o repositório gke-infrastructure-repo.

      2. Clique em Pedidos de obtenção e, de seguida, em Novo pedido de obtenção.

      3. No menu Base, escolha prod e, no menu Comparar, escolha staging.

      4. Clique em Criar pedido de obtenção.

    9. Se for administrador do repositório, junte o pedido de envio. Caso contrário, peça ao administrador para unir o pedido de obtenção.

    10. Na Google Cloud consola, aceda à página Histórico do Cloud Build.

      Aceda à página do histórico do Cloud Build

      É iniciada uma terceira pipeline do Cloud Build no projeto. Este pipeline cria o cluster GKE de produção.

    Infraestrutura

    Nesta secção, explora a infraestrutura criada pelos pipelines.

    • Na Google Cloud consola, aceda à página Clusters do Kubernetes.

      Aceda à página de clusters do Kubernetes

      Esta página apresenta os clusters que são usados para desenvolvimento (gke-dev-us-central1), preparação (gke-staging-us-central1) e produção ( gke-prod-us-central1 e gke-prod-us-west1):

      Os detalhes dos clusters incluem a localização, o tamanho do cluster e o número total de núcleos.

    Cluster de desenvolvimento

    O cluster de desenvolvimento (gke-dev-us-central1) dá aos seus programadores acesso a um espaço de nomes que podem usar para iterar nas respetivas aplicações. Recomendamos que as equipas usem ferramentas como o Skaffold, que oferecem um fluxo de trabalho iterativo através da monitorização ativa do código em desenvolvimento e da sua reaplicação aos ambientes de desenvolvimento à medida que são feitas alterações. Este ciclo de iteração é semelhante ao hot reloading. No entanto, em vez de ser específica da linguagem de programação, o ciclo funciona com qualquer aplicação que possa criar com uma imagem do Docker. Pode executar o ciclo num cluster do Kubernetes.

    Em alternativa, os seus programadores podem seguir o ciclo de CI/CD para um ambiente de desenvolvimento. Esse ciclo torna as alterações ao código prontas para promoção a ambientes superiores.

    No documento seguinte desta série, CI/CD moderno com o GKE: aplique o fluxo de trabalho do programador, usa o Skaffold e o CI/CD para criar o ciclo de desenvolvimento.

    Cluster de teste

    Este cluster executa o ambiente de preparação das suas aplicações. Nesta arquitetura de referência, cria um cluster do GKE para a preparação. Normalmente, um ambiente de teste é uma réplica exata do ambiente de produção.

    Cluster de produção

    Na arquitetura de referência, tem dois clusters do GKE para os seus ambientes de produção. Para sistemas de georredundância ou de alta disponibilidade (HA), recomendamos que adicione vários clusters a cada ambiente. Para todos os clusters onde as aplicações são implementadas, é ideal usar clusters regionais. Esta abordagem isola as suas aplicações de falhas ao nível da zona e de quaisquer interrupções causadas por atualizações de clusters ou de node pools.

    Para sincronizar a configuração dos recursos do cluster, como espaços de nomes, quotas e RBAC, recomendamos que use o Config Sync. Para mais informações sobre como gerir esses recursos, consulte o artigo Repositórios de configuração e políticas.

    Aplique a arquitetura de referência

    Agora que explorou a arquitetura de referência, pode explorar um fluxo de trabalho do programador baseado nesta implementação. No próximo documento desta série, CI/CD moderno com o GKE: aplique o fluxo de trabalho do programador, cria uma nova aplicação, adiciona uma funcionalidade e, em seguida, implementa a aplicação nos ambientes de preparação e produção.

    Limpar

    Se quiser experimentar o próximo documento desta série, CI/CD moderno com o GKE: aplicar o fluxo de trabalho do programador, não elimine o projeto nem os recursos associados a esta arquitetura de referência. Caso contrário, para evitar incorrer em custos na sua conta pelos recursos que usou na arquitetura de referência, pode eliminar o projeto ou remover manualmente os recursos. Google Cloud

    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.

    Remova manualmente os recursos

    • No Cloud Shell, remova a infraestrutura:

        gcloud container clusters delete gke-dev-us-central1
  gcloud container clusters delete gke-staging-us-central1
  gcloud container clusters delete gke-prod-us-central1
  gcloud container clusters delete gke-prod-us-west1
  gcloud beta builds triggers delete create-infra
  gcloud beta builds triggers delete add-team-files
  gcloud beta builds triggers delete create-app
  gcloud beta builds triggers delete tf-plan
  gcloud beta builds triggers delete tf-apply

    O que se segue?