Desenvolver e entregar aplicativos com o Cloud Code, o Cloud Build, o Google Cloud Deploy e o GKE

Refresh_date: 18-11-2022

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

Este tutorial é destinado a desenvolvedores de software e operadores. Nele, você vai desempenhar os dois papéis. 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 Google 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.

Veja os principais recursos deste sistema integrado:

  • Desenvolva e implante com mais rapidez.

    O loop de desenvolvimento é eficiente porque é possível validar alterações no espaço de trabalho do desenvolvedor. A implantação é rápida porque o sistema de CI/CD automatizado e o aumento de paridade entre os ambientes permitem detectar mais problemas ao implantar alterações na produção.

  • Aproveite o aumento de paridade entre desenvolvimento, preparo e produção.

    Os componentes desse sistema usam um conjunto comum de ferramentas do Google Cloud.

  • Reutilize configurações em vários ambientes.

    Essa reutilização é feita com o Skaffold, que permite um formato de configuração comum para os diferentes ambientes. Ele também permite que desenvolvedores e operadores atualizem e usem a mesma configuração.

  • Aplique a governança no início do fluxo de trabalho.

    Este sistema aplica testes de validação para governança tanto na produção como no sistema de CI e no ambiente de desenvolvimento. A aplicação da governança no ambiente de desenvolvimento permite encontrar e corrigir os problemas antes.

  • Deixe que as ferramentas opinativas gerenciem a entrega de software.

    A entrega contínua é totalmente gerenciada, separando os estágios do pipeline de CD dos detalhes de renderização e implantação.

Visão geral da arquitetura

Veja no diagrama a seguir os recursos usados neste tutorial:

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

Os três componentes principais desse pipeline são:

  1. O Cloud Code como um espaço de trabalho de desenvolvimento.

    Como parte desse espaço de trabalho, você verá alterações no cluster de desenvolvimento, que é executado no minikube. Execute o Cloud Code e o cluster do minikube no Cloud Shell. O Cloud Shell é um ambiente de desenvolvimento on-line acessível pelo navegador. Ele tem recursos de computação, memória, um ambiente de desenvolvimento integrado (IDE) e também o Cloud Code instalado.

  2. O Cloud Build para criar e testar o aplicativo, isto é, a parte de "CI" do pipeline.

    Essa parte do pipeline inclui as seguintes ações:

    • O Cloud Build monitora as alterações no repositório de origem, usando um gatilho do Cloud Build.
    • Quando uma alteração é confirmada na ramificação principal, o gatilho do Cloud Build faz o seguinte:
      • Recria o contêiner do aplicativo.
      • Coloca os artefatos do build em um bucket do Cloud Storage.
      • Coloca o contêiner do aplicativo no Artifact Registry.
      • Executa testes no contêiner.
      • Chama o Google Cloud Deploy para implantar o contêiner no ambiente de preparo. Neste tutorial, o ambiente de preparo é um cluster do Google Kubernetes Engine.
    • Se o build e os testes forem bem-sucedidos, você vai poder usar o Google Cloud Deploy para promover o contêiner do preparo para a produção.
  3. O Google Cloud Deploy para gerenciar a implantação, isto é, a parte de "CD" do pipeline.

    Nessa parte do pipeline, o Google Cloud Deploy faz o seguinte:

    • Registra um pipeline de entrega e os destinos. Os destinos representam os clusters de preparo e de produção.
    • Cria um bucket do Cloud Storage, armazenando a origem da renderização do Skaffold e os manifestos renderizados nesse bucket.
    • Gera uma nova versão para cada alteração no código-fonte. Neste tutorial, há uma alteração e, portanto, uma nova versão.
    • Implanta o aplicativo no ambiente de produção. Nesta implantação na produção, um operador (ou outra pessoa designada) aprova manualmente a implantação. Neste tutorial, o ambiente de produção é um cluster do Google Kubernetes Engine.

O Skaffold, uma ferramenta de linha de comando que facilita o desenvolvimento contínuo para aplicativos nativos do Kubernetes, acompanha esses componentes e permite que a configuração seja compartilhada entre desenvolvimento, preparo e produção.

O Google Cloud armazena o código-fonte do aplicativo no GitHub e, como parte deste tutorial, você vai clonar esse repositório no Cloud Source Repositories para conectá-lo ao pipeline de CI/CD.

Neste tutorial, usamos produtos do Google Cloud na maioria dos componentes do sistema, com o Skaffold permitindo a integração do sistema. Como o Skaffold é de código aberto, é possível usar esses princípios para criar um sistema semelhante combinando componentes internos, de terceiros e do Google Cloud. A modularidade desta solução significa que pode ser adotada de maneira incremental como parte do pipeline de desenvolvimento e implantação.

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 Google 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. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

  2. Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

  3. Ative as APIs Artifact Registry, Cloud Build, Google Cloud Deploy, Cloud Source Repositories, Google Kubernetes Engine, Resource Manager, and Service Networking.

    Ative as APIs

  4. No Console do Google Cloud, ative o Cloud Shell.

    Ativar o Cloud Shell

    Na parte inferior do Console do Google Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente shell com a CLI do Google Cloud já instalada e com valores já definidos para o projeto atual. A inicialização da sessão pode levar alguns segundos.

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

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

  2. Conceda às contas de serviço as permissões necessárias:

    1. Verifique se a conta de serviço padrão do Compute Engine tem permissões suficientes para executar jobs no Google Cloud Deploy e extrair contêineres do Artifact Registry. O Cloud Build e o Google 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"
      
    2. Conceda o privilégio de conta de serviço do Cloud Build para invocar implantações com o Google 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"
      

      Consulte o papel clouddeploy.operator para saber mais sobre esse papel do IAM.

    3. Conceda o privilégio de conta de serviço do Cloud Build e do Google 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"
      

      Consulte o papel container.admin para saber mais sobre esse papel do IAM.

    4. Conceda à conta de serviço do Cloud Build as permissões necessárias para invocar operações do Google 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 Google 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.

      Consulte o papel iam.serviceAccountUser para saber mais sobre esse papel do IAM.

Você 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.

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

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

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 e abra o repositório no Cloud Shell.

  2. Clique em Confirm.

    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 a ser usado neste tutorial:

    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 Google 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 Google 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 Google 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:

    gsutil mb 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 do pipeline de CI/CD são definidas neste arquivo:

    • 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 Google 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 Google 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 Google 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 Google Cloud Deploy implanta a versão no ambiente de preparo.

    O pipeline de entrega e os destinos são gerenciados pelo Google 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 o Cloud Build e observe que não há builds para o 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 tutorial. Saiba mais em 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 pelo endereço de e-mail conectado à sua conta do GitHub;
    • NAME pelo 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 Google Cloud Deploy rollout ROLLOUT_NAME in target staging

  4. Abra a página de pipelines de entrega do Google 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 Google 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 Google Cloud Deploy e selecione o pipeline cicd-sample.

  2. Promova a implantação do preparo para a produção. Para fazer 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 Google 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 os contém ou mantenha o projeto e exclua os recursos individuais.

Opção 1: excluir o projeto

  1. No Console do Google Cloud, acesse a página Gerenciar recursos.

    Acessar "Gerenciar recursos"

  2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
  3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

Opção 2: excluir os recursos individuais

  1. Exclua o pipeline do Google 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:

    gsutil rm -r gs://$(gcloud config get-value project)-gceme-artifacts/
    
    gsutil 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