CI/CD moderno com GKE: como criar um sistema de CI/CD

Essa arquitetura de referência oferece um método e uma infraestrutura inicial para criar um sistema moderno de integração/entrega contínuas (CI/CD) usando ferramentas como Google Kubernetes Engine, Cloud Build, Skaffold, kustomize, Config Sync, Controlador de Políticas, Artifact Registry, and Cloud Deploy.

Este documento faz parte de uma série:

Este documento destina-se a arquitetos corporativos e desenvolvedores de aplicativos, bem como a equipes de TI, DevOps e engenharia de confiabilidade do site. Algumas experiências com processos e ferramentas de implantação automatizada são úteis para entender os conceitos deste documento.

Fluxo de trabalho de CI/CD

Para criar um sistema moderno de CI/CD, primeiro é preciso escolher ferramentas e serviços que executem as principais funções do sistema. O foco dessa arquitetura de referência é implementar as funções principais de um sistema de CI/CD mostrado no diagrama a seguir:

Várias equipes gerenciam ou compartilham a responsabilidade pelo sistema de CI/CD.

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

  • Para gerenciamento de código-fonte: GitHub
    • Armazena o código de aplicativo e configuração.
    • Permite revisar as alterações.
  • Para o gerenciamento de configuração do aplicativo: kustomize
    • Define a configuração pretendida de um aplicativo.
    • Permite que você reutilize e estenda primitivos ou blueprints de configuração.
  • Para integração contínua: Cloud Build
    • Testa e valida o código-fonte.
    • Cria artefatos consumidos pelo ambiente de implantação.
  • Para entrega contínua: Cloud Deploy
    • Define o processo de lançamento do código entre ambientes.
    • Fornece reversão para alterações com falha.
  • Para a configuração da infraestrutura: Config Sync
    • Aplica consistentemente a configuração do cluster e da política.
  • Para aplicação de política: Controlador de Políticas
    • Fornece um mecanismo que pode ser usado para definir o que pode ser executado em um determinado ambiente com base nas políticas da organização.
  • Para orquestração de contêineres: Google Kubernetes Engine
    • Executa os artefatos criados durante a CI.
    • Oferece metodologias de escalonamento, verificação de integridade e lançamento para cargas de trabalho.
  • Para artefatos de contêiner: Artifact Registry
    • Armazena os artefatos (imagens de contêiner) criados durante a CI.

Arquitetura

Nesta seção, descrevemos os componentes de CI/CD que você implementa usando esta arquitetura de referência: infraestrutura, repositórios de código e zonas de destino do aplicativo.

Para uma discussão geral sobre esses aspectos do sistema de CI/CD, consulte CI/CD moderno com Anthos: um framework de entrega de software.

Variantes da arquitetura de referência

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

  • Variante de vários projetos que é mais parecida com uma implantação de produção com limites de isolamento aprimorados
  • Uma variante de projeto único, que é útil para demonstrações

Arquitetura de referência de vários projetos

A versão multi-project da arquitetura de referência simula cenários de produção. Nesses cenários, diferentes perfis criam infraestrutura, pipelines de CI/CD e aplicativos com limites de isolamento adequados. Essas personas ou equipes só podem acessar os recursos necessários.

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

Para detalhes sobre como instalar e aplicar essa versão da arquitetura de referência, consulte o modelo 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 entrega de software em um único projeto do Google Cloud. Essa versão pode ajudar qualquer usuário que não tenha papéis elevados do IAM a instalar e testar a arquitetura de referência apenas com o papel de proprietário em um projeto. Neste documento, demonstramos a versão de projeto único da arquitetura de referência.

Infraestrutura de plataforma

A infraestrutura desta arquitetura de referência consiste em clusters do Kubernetes para oferecer suporte aos ambientes de aplicativos de desenvolvimento, preparo e produção. No diagrama a seguir, mostramos o layout lógico dos clusters:

O layout do cluster é compatível com diferentes cargas de trabalho da plataforma.

Repositórios de código

Usando essa arquitetura de referência, você configura repositórios para operadores, desenvolvedores, plataforma e engenheiros de segurança.

No diagrama a seguir, veja a implementação da arquitetura de referência dos diferentes repositórios de código e como as equipes de operações, desenvolvimento e segurança interagem com eles.

Os repositórios incluem práticas recomendadas, além da configuração de aplicativo e plataforma.

Nesse fluxo de trabalho, seus operadores podem gerenciar as práticas recomendadas para CI/CD e configuração de aplicativo no repositório do operador. Quando seus desenvolvedores podem integrar aplicativos no repositório de desenvolvimento, eles recebem automaticamente práticas recomendadas, lógica de negócios do aplicativo e qualquer configuração especializada necessária para que o aplicativo funcione corretamente. Enquanto isso, sua equipe de operações e segurança pode gerenciar a consistência e a segurança da plataforma nos repositórios de configuração e política.

Zonas de destino do aplicativo

Nesta arquitetura de referência, a zona de destino de um aplicativo é criada quando o aplicativo é provisionado. No próximo documento desta série, CI/CD moderno com GKE: aplicar o fluxo de trabalho do desenvolvedor, você provisiona um novo aplicativo que cria a própria zona de destino. O diagrama a seguir ilustra os componentes importantes das zonas de destino usadas nesta arquitetura de referência:

O cluster do GKE inclui três namespaces para aplicativos diferentes.

Cada namespace inclui uma conta de serviço usada para que a federação de identidade da carga de trabalho para GKE acesse serviços fora do contêiner do Kubernetes, como o Cloud Storage ou o Spanner. O namespace também inclui outros recursos, como políticas de rede, para isolar ou compartilhar limites com outros namespaces ou aplicativos.

O namespace é criado pela conta de serviço de execução de CD. Recomendamos que as equipes sigam o princípio de privilégio mínimo para ajudar a garantir que uma conta de serviço de execução de CD só possa acessar os namespaces necessários.

É possível definir o acesso à conta de serviço no Config Sync e implementá-lo usando papéis do controle de acesso baseado em papéis (RBAC) e vinculações de papéis do Kubernetes. Com esse modelo, as equipes podem implantar qualquer recurso diretamente nos namespaces que gerenciam, mas são impedidos de substituir ou excluir recursos de outros namespaces.

Objetivos

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

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

    Activate Cloud Shell

Implantar a arquitetura de referência

  1. Defina o projeto no Cloud Shell:

    gcloud config set core/project PROJECT_ID

    Substitua PROJECT_ID pelo ID do projeto do Google Cloud.

  2. No Cloud Shell, clone o repositório do 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 escopos:

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

  4. Há um arquivo vazio chamado vars.sh na pasta software-delivery-bluprint/launch-scripts. Adicione o seguinte conteúdo ao arquivo: 

    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 usuário do GitHub.

    Substitua TOKEN pelo token de acesso pessoal do GitHub.

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

  5. Execute o script bootstrap.sh: Se o Cloud Shell solicitar sua autorização, clique em Autorizar:

    ./bootstrap.sh

    O script inicializa a plataforma de entrega de software.

Conhecer os repositórios de código

Nesta seção, você conhecerá os repositórios de código.

Faça login no GitHub.

  1. Em um navegador da Web, acesse github.com e faça login na sua conta.
  2. Clique no ícone de imagem na parte superior da interface.
  3. Clique em Suas organizações.
  4. Escolha a organização que você forneceu como entrada no arquivo vars.sh.
  5. Clique na guia repositório.

Conhecer os repositórios de ativação, operadora, configuração e infraestrutura

Nos repositórios de ativação, operador, configuração e infraestrutura, os operadores e administradores da plataforma definem as práticas recomendadas comuns para criar e operar a plataforma. Esses 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 para iniciantes

Os repositórios iniciais ajudam na adoção de práticas recomendadas de CI/CD e desenvolvimento em toda a plataforma. Para mais informações, consulte CI/CD moderna com o GKE: um framework de entrega de software (em inglês)

Repositórios iniciais de aplicativos

Nos repositórios iniciais de aplicativos, os operadores podem codificar e documentar práticas recomendadas, como CI/CD, coleta de métricas, geração de registros, etapas de contêiner e segurança para aplicativos. A arquitetura de referência inclui exemplos de repositórios iniciais para aplicativos Go, Python e Java.

Os repositórios iniciais de código padrão app-template-python, app-template-java e app-template-golang contém código boilerplate que é possível usar para criar novos aplicativos. Além de criar aplicativos, é possível criar modelos com base nos requisitos deles. Os repositórios iniciais do aplicativo fornecidos pela arquitetura de referência contêm:

  • A base kustomize e os patches na pasta k8s.

  • Código-fonte do aplicativo

  • Um Dockerfile que descreve como criar e executar o aplicativo

  • Um arquivo cloudbuild.yaml que descreve as práticas recomendadas para as etapas de CI.

  • Um arquivo skaffold.yaml que descreve as etapas da implantação.

No próximo documento desta série, CI/CD moderna com GKE: aplicar o fluxo de trabalho do desenvolvedor, use o repositório app-template-python para criar um novo aplicativo.

Repositórios básicos de infraestrutura

Nos repositórios iniciais de infraestrutura, os operadores e administradores de infraestrutura podem codificar e documentar práticas recomendadas, como pipelines de CI/CD, IaC, coleta de métricas, geração de registros e segurança para infraestrutura. A arquitetura de referência inclui exemplos de repositórios de infraestrutura inicial que usam o Terraform. O repositório inicial de infraestrutura infra-template contém um código boilerplate do Terraform que pode ser usado para criar os recursos de infraestrutura exigidos por um aplicativo, como o bucket do Cloud Storage, o banco de dados do Spanner, entre outros.

Repositórios de modelos compartilhados

Nos repositórios de modelos compartilhados, os administradores e operadores de infraestrutura oferecem modelos padrão para realizar tarefas. Há um repositório chamado terraform-modules fornecido com a arquitetura de referência. O repositório inclui um modelo de código do Terraform para criar vários recursos de infraestrutura.

Repositórios de operador

Na arquitetura de referência, os repositórios de operadores são os mesmos que os repositórios iniciais do aplicativo. Os operadores gerenciam os arquivos necessários para CI e CD nos repositórios iniciais do aplicativo. A arquitetura de referência inclui os repositórios app-template-python, app-template-java e app-template-golang.

  • Eles são modelos iniciais e contêm os manifestos básicos do Kubernetes para os aplicativos em execução no Kubernetes na plataforma. Os operadores podem atualizar os manifestos nos modelos iniciais conforme necessário. As atualizações são recebidas quando um aplicativo é criado.
  • Os arquivos cloudbuild.yaml e skaffold.yaml nesses repositórios armazenam as práticas recomendadas para executar CI e CD, respectivamente, na plataforma. Assim como nas configurações do aplicativo, os operadores podem atualizar e adicionar etapas às práticas recomendadas. Pipelines de aplicativos individuais são criados usando as etapas mais recentes.

Nesta implementação de referência, os operadores usam kustomize para gerenciar as configurações básicas na pasta k8s dos repositórios iniciais. Os desenvolvedores podem estender os manifestos com mudanças específicas do aplicativo, como nomes de recursos e arquivos de configuração. A ferramenta kustomize é compatível com a configuração como dados. Com esta metodologia, entradas e saídas kustomize são recursos do Kubernetes. Você pode usar as saídas de uma modificação dos manifestos para outra modificação.

O diagrama a seguir ilustra uma configuração básica para um aplicativo Spring Boot:

A configuração do aplicativo é feita em vários repositórios gerenciados por equipes separadas.

A configuração como modelo de dados em kustomize tem um grande benefício: quando os operadores atualizam a configuração base, as atualizações são consumidas automaticamente pelo pipeline de implantação do desenvolvedor na próxima execução, sem nenhuma alteração no do desenvolvedor.

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

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

A arquitetura de referência inclui a implementação de um repositório de configurações e políticas que usa o Config Sync e o Controlador de Políticas. O repositório acm-gke-infrastructure-repo contém a configuração e as políticas implantadas em todos os clusters do ambiente de aplicativos. A configuração definida e armazenada por administradores de plataforma nesses repositórios é importante para garantir que a plataforma tenha uma aparência consistente para as equipes de operações e desenvolvimento.

Nas seções a seguir, explicamos detalhadamente como a arquitetura de referência implementa repositórios de configuração e política.

Configuração

Nesta implementação de referência, você usa o Config Sync para gerenciar centralmente a configuração de clusters na plataforma e aplicar políticas. O gerenciamento centralizado permite propagar alterações de configuração em todo o sistema.

Usando o Config Sync, sua organização pode registrar clusters para sincronizar a configuração deles com um repositório Git, um processo conhecido como GitOps. Quando novos clusters são adicionados, eles são sincronizados automaticamente com a configuração mais recente e reconciliam continuamente seu estado com base nessa configuração, caso sejam feitas alterações fora da banda.

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

Política

Nesta implementação de referência, use o Controlador de Políticas, que é baseado no Open Policy Agent, para interceptar e validar cada solicitação para os clusters do Kubernetes na plataforma. É possível criar políticas usando a linguagem da política de Rego, que permite controlar totalmente os tipos de recursos enviados ao cluster, mas também a configuração deles.

A arquitetura no diagrama a seguir mostra um fluxo de solicitação para usar o Policy Controller para criar um recurso:

Primeiro, uma regra de política é definida pela primeira vez e aplicada usando várias ferramentas, como kubectl e clientes de API.

Você cria e define regras no repositório do Config Sync, e essas alterações são aplicadas ao cluster. Depois disso, as novas solicitações de recursos da CLI ou dos clientes de API são validadas em relação às restrições pelo Controlador de políticas.

Para mais informações sobre como gerenciar políticas, consulte a visão geral do Policy Controller.

Repositórios de infraestrutura

O documento contém uma implementação do repositório de infraestrutura usando o Terraform. O repositório gke-infrastructure-repo contém uma infraestrutura como código para criar clusters do GKE nos ambientes de desenvolvimento, teste e produção, além de configurar o Config Sync neles usando o repositório acm-gke-infrastructure-repo. gke-infrastructure-repo contém três ramificações, uma para cada ambiente de desenvolvimento, preparo e produção. Ele também contém pastas de desenvolvimento, preparo e produção em cada ramificação.

Analisar o pipeline e a infraestrutura

A arquitetura de referência cria um pipeline no projeto do Google Cloud. Esse pipeline é responsável por criar a infraestrutura compartilhada.

Pipeline

Nesta seção, você vai analisar o pipeline de infraestrutura como código e executá-lo para criar a infraestrutura compartilhada, incluindo clusters do GKE. O pipeline é um gatilho do Cloud Build chamado create-infra no projeto do Google Cloud vinculado ao repositório de infraestrutura gke-infrastructure-repo. Você segue a metodologia GitOps para criar a infraestrutura, conforme explicado no vídeo sobre ambientes repetíveis do GCP em escala com pipelines de infraestrutura como código do Cloud Build.

gke-infrastructure-repo tem ramificações de desenvolvimento, preparo e produção. No repositório, há também as pastas "dev", "staging" e "production" que correspondem a essas ramificações. Há regras de proteção de ramificação no repositório que garantem que o código só possa ser enviado para a ramificação de desenvolvimento. Para enviar o código para as ramificações de preparo e produção, é preciso criar uma solicitação de envio.

Normalmente, alguém com acesso ao repositório analisa as alterações e mescla a solicitação de envio para garantir que somente as mudanças pretendidas sejam promovidas para a ramificação superior. Para permitir que os indivíduos testem o blueprint, as regras de proteção de ramificação foram flexibilizadas na arquitetura de referência para que o administrador do repositório possa ignorar a revisão e mesclar a solicitação de envio.

Quando um push é feito para gke-infrastructure-repo, ele invoca o gatilho create-infra. Esse gatilho identifica a ramificação em que o push ocorreu e vai para a pasta correspondente no repositório dessa ramificação. Depois de encontrar a pasta correspondente, ele executa o Terraform usando os arquivos contidos nela. Por exemplo, se o código for enviado para a ramificação de desenvolvimento, o gatilho vai executar o Terraform na pasta de desenvolvimento da ramificação de dev para criar um cluster de desenvolvedor do GKE. Da mesma forma, quando um push acontece para a ramificação staging, o gatilho executa o Terraform na pasta de preparo da ramificação de preparo para criar um cluster de preparo do GKE.

Execute o pipeline para criar clusters do GKE:

  1. No console do Google Cloud, acesse a página do Cloud Build.

    Acessar a página do Cloud Build

    • Há cinco gatilhos do webhook do Cloud Build. Procure o gatilho com o nome create-infra. Esse gatilho cria a infraestrutura compartilhada, incluindo clusters do GKE.

  2. Clique no nome do acionador. A definição do acionador é aberta.

  3. Clique em ABRIR O EDITOR para ver as etapas executadas pelo acionador.

    Os outros gatilhos são usados quando você integra um aplicativo em CI/CD moderna com o GKE: aplicar o fluxo de trabalho do desenvolvedor

    Gatilhos do Cloud Build

  4. No console do Google Cloud, acesse a página do Cloud Build.

    Acessar a página de gatilhos do Cloud Build

    Revise o pipeline presente na página do histórico. Quando você implantou a plataforma de entrega de software usando bootstrap.sh, o script enviou o código para a ramificação de desenvolvimento do repositório gke-infrastructure-repo que iniciou esse pipeline e criou o cluster dev do GKE.

  5. Para criar um cluster de preparo do GKE, envie uma solicitação de envio da ramificação de dev para a de preparo:

    1. Acesse o GitHub e navegue até o repositório gke-infrastructure-repo.

    2. Clique em Solicitações de envio e em Nova solicitação de envio.

    3. No menu Base, escolha staging e no menu Compare, selecione dev.

    4. Clique em Criar solicitação de envio.

  6. Se você for um administrador no repositório, mescle a solicitação de envio. Caso contrário, peça ao administrador para mesclar a solicitação de envio.

  7. No console do Google Cloud, acesse a página Histórico do Cloud Build.

    Acessar a página de gatilhos do Cloud Build

    Um segundo pipeline do Cloud Build começa no projeto. Esse pipeline cria o cluster de preparo do GKE.

  8. Para criar clusters do GKE de produção, envie um pull request do preparo para a ramificação de produção:

    1. Acesse o GitHub e navegue até o repositório gke-infrastructure-repo.

    2. Clique em Solicitações de envio e em Nova solicitação de envio.

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

    4. Clique em Criar solicitação de envio.

  9. Se você for um administrador no repositório, mescle a solicitação de envio. Caso contrário, peça ao administrador para mesclar a solicitação de envio.

  10. No console do Google Cloud, acesse a página Histórico do Cloud Build.

    Acessar a página de gatilhos do Cloud Build

    Um terceiro pipeline do Cloud Build começa no projeto. Esse pipeline cria o cluster de produção do GKE.

Infraestrutura

Nesta seção, você vai conhecer a infraestrutura criada pelos pipelines.

  • No Console do Google Cloud, acesse a página de clusters do Kubernetes.

    Acessar a página de clusters do Kubernetes

    Nesta página, listamos os clusters usados para desenvolvimento (gke-dev-us-central1), preparo (gke-staging-us-central1) e produção ( gke-prod-us-central1, gke-prod-us-west1):

    Os detalhes dos clusters incluem local, tamanho do cluster e núcleos totais.

Cluster de desenvolvimento

O cluster de desenvolvimento (gke-dev-us-central1) permite que os desenvolvedores acessem um namespace que pode ser usado para iterar nos aplicativos. Recomendamos que as equipes usem ferramentas como o Skaffold, que fornece um fluxo de trabalho iterativo. Para isso, ele monitora ativamente o código em desenvolvimento e o reaplica aos ambientes de desenvolvimento conforme as alterações são feitas. Esse loop de iteração é semelhante à recarga dinâmica. No entanto, em vez de ser específico a uma linguagem de programação, o loop funciona com qualquer aplicativo que você possa criar com uma imagem do Docker. É possível executar o loop dentro de um cluster do Kubernetes.

Como alternativa, os desenvolvedores podem seguir a repetição de CI/CD de um ambiente de desenvolvimento. Esse loop faz com que as alterações no código fiquem prontas para promoção em ambientes superiores.

No próximo documento desta série, CI/CD moderno com GKE: aplicar o fluxo de trabalho do desenvolvedor, use o Skaffold e a CI/CD para criar o loop de desenvolvimento.

Cluster de preparo

Este cluster executa o ambiente de preparação dos seus aplicativos. Nesta arquitetura de referência, você cria um cluster do GKE para preparo. Normalmente, um ambiente de preparo é uma réplica exata do ambiente de produção.

Cluster de produção

Na arquitetura de referência, você tem dois clusters do GKE para seus ambientes de produção. Para sistemas de redundância geográfica ou de alta disponibilidade (HA, na sigla em inglês), recomendamos adicionar vários clusters a cada ambiente. Para todos os clusters em que os aplicativos são implantados, o ideal é usar clusters regionais. Essa abordagem isola os aplicativos das falhas no nível da zona e de todas as interrupções causadas por upgrades de pool de nós ou de cluster.

Para sincronizar a configuração dos recursos do cluster, como namespaces, cotas e RBAC, recomendamos o uso do Config Sync. Para mais informações sobre como gerenciar esses recursos, consulte Repositórios de configuração e política.

Aplicar a arquitetura de referência

Agora que você conhece a arquitetura de referência, pode explorar um fluxo de trabalho de desenvolvedor baseado nessa implementação. No próximo documento desta série, CI/CD moderno com Anthos: como aplicar o fluxo de trabalho do desenvolvedor, você irá criar um novo aplicativo, adicionar um recurso e, depois, implantar o aplicativo nos ambientes de preparação e produção.

Limpar

Se você quiser testar o próximo documento desta série, CI/CD modernas com o GKE: como aplicar o fluxo de trabalho do desenvolvedor , não exclua o projeto ou os recursos associados a essa arquitetura de referência. Caso contrário, para evitar cobranças na sua conta do Google Cloud pelos recursos usados na arquitetura de referência, você poderá excluir o projeto ou removê-los manualmente.

Exclua 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.

Remover recursos manualmente

  • 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

A seguir