Configurar o CI/CD para armazenar a configuração como código do Terraform

Neste tutorial, explicamos como gerenciar a infraestrutura como código com o Terraform e o Cloud Build usando a conhecida metodologia GitOps. O termo GitOps foi cunhado pela primeira vez pela Weaveworks (em inglês), e o conceito principal dele é usar um repositório Git para armazenar o estado do ambiente que você quer. O Terraform é uma ferramenta de código aberto da HashiCorp (em inglês) que permite criar, alterar e melhorar de maneira previsível sua infraestrutura em nuvem por meio de código. Neste tutorial, você usa o Cloud Build, um Google Cloud serviço de integração contínua, para aplicar automaticamente os manifestos do Terraform ao seu ambiente.

Este tutorial é destinado para desenvolvedores e operadores que procuram uma estratégia elegante para fazer alterações previsíveis na infraestrutura. O artigo considera que você já conhece Google Cloude o Linux.

Os relatórios State of DevOps identificaram recursos que impulsionam o desempenho da entrega de software. Este tutorial ajudará você com os seguintes recursos:

• Controle de versões
• Integração contínua
• Entrega contínua
• Teste contínuo

Arquitetura

Este tutorial aplica as práticas do GitOps para gerenciar execuções do Terraform. Ele usa ramificações do Secure Source Manager dev e prod para representar ambientes reais. Esses ambientes são definidos por redes de nuvem privada virtual (VPC) dev e prod, respectivamente, em um projetoGoogle Cloud .

O processo começa quando você envia o código do Terraform para a ramificação dev ou prod. Nesse cenário, o Cloud Build aciona e aplica manifestos do Terraform para atingir o estado desejado no respectivo ambiente. Por outro lado, quando você aplica o código do Terraform a qualquer outra ramificação, por exemplo, a uma ramificação de recurso, o Cloud Build é executado para terraform plan, mas nada é aplicado a ambiente algum.

O ideal é que desenvolvedores ou operadores façam propostas de infraestrutura para ramificações de desenvolvimento ou de recursos e as enviem por solicitações de envio. Dessa forma, é possível discutir e analisar as possíveis alterações com os colaboradores e adicionar confirmações de acompanhamento antes que as alterações sejam mescladas no branch básico.

Se não houver preocupações, mescle as alterações no branch dev. Essa mescla aciona uma implantação de infraestrutura para o ambiente dev, o que permite testá-lo. Depois de testar e ter certeza do que foi implantado, mescle o branch dev no branch prod para acionar a instalação da infraestrutura no ambiente de produção.

Objetivos

• Configure sua instância e seu repositório do Secure Source Manager.
• Configurar o Terraform para armazenar o estado em um bucket do Cloud Storage.
• Conceder permissões à conta de serviço do Cloud Build.
• Conecte o Cloud Build ao seu repositório do Secure Source Manager.
• Alterar a configuração do ambiente em uma ramificação de recurso.
• Promover mudanças no ambiente de desenvolvimento.
• Promover mudanças no ambiente de produção.

Custos

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

• Cloud Build
• Cloud Storage
• Compute Engine

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 um teste gratuito.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Para mais informações, consulte Limpeza.

Antes de começar

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

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

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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

2. No Cloud Shell, consiga o código do projeto que você acabou de selecionar:

   gcloud config get-value project

   Se este comando não retornar o ID do projeto, configure o Cloud Shell para usar seu projeto. Substitua PROJECT_ID pelo ID do projeto.

   gcloud config set project PROJECT_ID

3. Ative as APIs necessárias:

   gcloud services enable cloudbuild.googleapis.com compute.googleapis.com securesourcemanager.googleapis.com

   Esta etapa pode levar alguns minutos.
4. Se você nunca usou o Git no Cloud Shell, configure-o com seu nome e endereço de e-mail:

   git config --global user.email "YOUR_EMAIL_ADDRESS"
   git config --global user.name "YOUR_NAME"
   

   O Git usa essas informações para identificar você como o autor das confirmações que você cria no Cloud Shell.

Configurar seu repositório do Secure Source Manager

Neste tutorial, você usa um único repositório do Secure Source Manager para definir a infraestrutura em nuvem. Você orquestra essa infraestrutura ao ter branches diferentes correspondentes a ambientes diferentes:

• A ramificação dev contém as alterações mais recentes aplicadas ao ambiente de desenvolvimento.
• A ramificação prod contém as últimas alterações que são aplicadas ao ambiente de produção.
• Ramificações de recursos semelhantes a feature_x são usadas para fazer mudanças antes de enviar para as ramificações dev ou prod.

Com essa infraestrutura, sempre é possível fazer referência ao repositório para saber qual configuração é esperada em cada ambiente e propor novas alterações, primeiro fundindo-as ao ambiente dev. Em seguida, você promove as alterações mesclando a ramificação dev na ramificação prod subsequente.

1. Crie um repositório vazio do Secure Source Manager: não inicialize o repositório.

2. Adicione o auxiliar de autenticação do Secure Source Manager ao seu git config global executando o seguinte comando:

   git config --global credential.'https://*.*.sourcemanager.dev'.helper gcloud.sh
   

   O auxiliar de autenticação usa a CLI gcloud para buscar suas credenciaisGoogle Cloud ao usar comandos do Git com o Secure Source Manager.

3. Para fazer a reautenticação após a configuração inicial das credenciais, execute o seguinte comando da CLI gcloud:

   gcloud auth login
   

4. Clone o repositório solutions-terraform-cloudbuild-gitops (em inglês) no shell local ou no ambiente de trabalho:

   git clone https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git
   

5. Adicione seu repositório do Secure Source Manager como um upstream.

   git remote add google HTTPS_REPO_URL
   

   Em que HTTPS_REP_URL é o URL HTTPS do seu repositório do Secure Source Manager. O URL fica na parte de cima da página do repositório na interface da Web do Secure Source Manager.

6. Crie e mude para a ramificação dev.

   git checkout dev
   

7. Envie o repositório clonado para o seu com o seguinte comando:

   git push -u google --all
   

8. Repita as duas etapas anteriores para a ramificação prod.

O código nesse repositório está estruturado da seguinte maneira:

• A pasta environments/ contém subpastas que representam ambientes, como dev e prod, que fornecem separação lógica entre cargas de trabalho em diferentes estágios de maturidade, desenvolvimento e produção, respectivamente. É uma boa prática que esses ambientes sejam os mais semelhantes possíveis, mas cada subpasta tem a própria configuração do Terraform para garantir que possam ter configurações únicas, conforme necessário.

• A pasta modules/ contém módulos in-line do Terraform. Esses módulos representam agrupamentos lógicos de recursos relacionados e são usados para compartilhar código em diferentes ambientes.

• O cloudbuild.yaml é um arquivo de configuração de versão que contém instruções para o Cloud Build, como executar tarefas com base em um conjunto de etapas. Esse arquivo especifica uma execução condicional, dependendo do branch em que o Cloud Build está buscando o código. Por exemplo:

  • Para ramificações dev e prod, as seguintes etapas são executadas:

    1. terraform init
    2. terraform plan
    3. terraform apply

  • Para qualquer outra ramificação, as etapas a seguir são executadas:

    1. terraform init para todas as subpastas environments
    2. terraform plan para todas as subpastas environments

Para garantir que as alterações propostas sejam adequadas para todos os ambientes, terraform init e terraform plan são executados em todas as subpastas environments. Antes de mesclar a solicitação de envio, é possível analisar os planos para garantir que o acesso não seja concedido a uma entidade não autorizada, por exemplo.

Modificar o arquivo de configuração do build

Para que o arquivo de configuração de build de amostra funcione com o Secure Source Manager, faça as seguintes edições:

• Adicione uma etapa para clonar seu repositório.
• Adicione uma etapa para receber o nome da ramificação e atribuí-lo a uma variável.

Edite o arquivo de configuração de build na ramificação dev:

1. Mude para a ramificação dev:

   git checkout dev
   

2. Abra o arquivo cloudbuild.yaml e substitua o conteúdo pelo seguinte:

   # Copyright 2019 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     https://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   
   steps:
   - id: 'clone repository'
     name: 'gcr.io/cloud-builders/git'
     args:
     - clone
     - '${_REPO_URL}'
     - .
   - id: 'branch name'
     name: gcr.io/cloud-builders/git
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         git checkout ${branch}
         echo "***********************"
         git branch --show-current
         echo "***********************"
   
   - id: 'tf init'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
      branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform init
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFORM INIT ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform init || exit 1
             cd ../../
           done
         fi
   
   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform plan
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFOM PLAN ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform plan || exit 1
             cd ../../
           done
         fi
   
   - id: 'tf apply'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform apply -auto-approve
         else
           echo "***************************** SKIPPING APPLYING *******************************"
           echo "Branch '${branch}' does not represent an official environment."
           echo "*******************************************************************************"
         fi

3. Verifique se o arquivo foi modificado.

   git status
   

4. Confirme e envie suas alterações por push:

   git add --all
   git commit -m "Modify build config file."
   git push google dev
   

5. Abra uma solicitação de envio para promover rapidamente suas mudanças na ramificação prod.

   1. Na interface da Web do Secure Source Manager, navegue até o repositório.
   2. Clique na guia Pull requests.
   3. Clique em New pull request.
   4. No campo mesclar em:, selecione a ramificação prod.
   5. No campo extrair de, selecione a ramificação dev.
   6. Revise as mudanças e clique em Nova solicitação de envio.
   7. Clique em Criar solicitação de envio.
   8. Clique em Mesclar solicitação de envio.

   9. Clique em Mesclar solicitação de envio novamente.

      As mudanças são mescladas na ramificação prod.

Como configurar o Terraform para armazenar o estado em um bucket do Cloud Storage

Por padrão, o Terraform armazena o estado localmente em um arquivo chamado terraform.tfstate. Essa configuração padrão pode dificultar o uso do Terraform para as equipes, especialmente quando muitos usuários o executam ao mesmo tempo e cada máquina tem o próprio entendimento da infraestrutura atual.

Para ajudar a evitar esses problemas, esta seção configura um estado remoto que aponta para um bucket do Cloud Storage. O estado remoto é um recurso de back-ends e, neste tutorial, é configurado nos arquivos backend.tf, por exemplo:

# Copyright 2019 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.


terraform {
  backend "gcs" {
    bucket = "PROJECT_ID-tfstate"
    prefix = "env/dev"
  }
}

Nas etapas a seguir, você cria um bucket do Cloud Storage e muda alguns arquivos para apontar para o novo bucket e o projeto Google Cloud .

1. No Cloud Shell, crie o bucket do Cloud Storage:

   PROJECT_ID=$(gcloud config get-value project)
   gcloud storage buckets create gs://${PROJECT_ID}-tfstate
   

2. Ative o Controle de versões do objeto para manter o histórico das implantações:

   gcloud storage buckets update gs://${PROJECT_ID}-tfstate --versioning
   

   Ativar o controle de versões de objetos aumenta os custos de armazenamento, que podem ser reduzidos com a configuração do Gerenciamento do ciclo de vida de objetos para excluir versões de estado mais antigas.

3. Crie uma ramificação cloud-storage-bucket para fazer as mudanças:

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout -b cloud-storage-bucket
   

4. Substitua o marcador PROJECT_ID pelo código do projeto nos arquivos terraform.tfvars e backend.tf:

   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

   No OS X ou macOS, talvez seja necessário adicionar duas aspas ("") após sed -i, da seguinte maneira:

   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

5. Verifique se todos os arquivos foram atualizados:

   git status
   

   O resultado será semelhante ao seguinte:

   On branch cloud-storage-bucket
   Changes not staged for commit:
   (use "git add ..." to update what will be committed)
   (use "git restore ..." to discard changes in working directory)
          modified:   environments/dev/backend.tf
          modified:   environments/dev/terraform.tfvars
          modified:   environments/prod/backend.tf
          modified:   environments/prod/terraform.tfvars
   no changes added to commit (use "git add" and/or "git commit -a")
   

6. Confirme e envie suas alterações por push:

   git add --all
   git commit -m "Update project IDs and buckets"
   git push google -u cloud-storage-bucket
   

   A nova ramificação cloud-storage-bucket é enviada por push para o repositório.

7. Mescle as mudanças de cloud-storage-bucket nas ramificações dev e prod abrindo e enviando solicitações de mesclagem para cada ramificação.

Conceder permissões à sua conta de serviço do Cloud Build

Para permitir que a conta de serviço do Cloud Build execute scripts do Terraform com o objetivo de gerenciar recursos do Google Cloud , você precisa conceder acesso adequado ao projeto. Para simplificar, o acesso ao editor do projeto é concedido neste tutorial. Para ambientes de produção, siga as práticas recomendadas de segurança de TI da sua empresa, geralmente fornecendo acesso com menos privilégios.

Observação: a conta de serviço padrão do Cloud Build usada para executar builds está sendo alterada. Como prática recomendada, sugerimos que você especifique sua própria conta de serviço para executar os builds. Para mais informações, consulte Mudança na conta de serviço do Cloud Build.

1. Para encontrar o e-mail da conta de serviço do Cloud Build, na página do Cloud Build, navegue até Configurações.

   Acessar as configurações do Cloud Build

2. Copie o valor do E-mail da conta de serviço.

3. Conceda o acesso necessário à sua conta de serviço do Cloud Build:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member serviceAccount:CLOUDBUILD_SA --role roles/editor
   

   Substitua:

   • PROJECT_ID pelo código do projeto;
   • CLOUDBUILD_SA com o e-mail da conta de serviço do Cloud Build.

Conectar ao Cloud Build

Para acionar o Cloud Build em um push para qualquer ramificação, configure um webhook do Secure Source Manager. O arquivo de configuração de build vai verificar o nome da ramificação para determinar se é necessário fazer mudanças nos ambientes dev ou prod.

1. Ative e configure o Cloud Build no seu projeto.

2. Abra a página Gatilhos no console do Google Cloud .

   Abrir a página Acionadores

3. Selecione o projeto no menu suspenso do seletor de projetos na parte superior da página.

4. Clique em Abrir.

5. Clique em Criar gatilho.

6. Preencha as configurações de gatilho a seguir:

   • Nome: trigger-on-push

   • Região: selecione a região do seu gatilho. Se o arquivo de configuração do build associado ao gatilho especificar um pool particular, a região selecionada para o gatilho precisa corresponder à região do pool particular.

     Observação: se você estiver usando um pool particular, atribua IPs externos para permitir que ele acesse a Internet pública. Para mais detalhes, consulte Como criar um pool particular.

     Se você selecionar global como sua região, o Cloud Build usará a região especificada no arquivo de configuração do build para executar o build. Essa pode ser a região do pool particular, se você especificar um pool particular no arquivo de configuração do build, ou o pool padrão global, se não especificar um pool particular.

   • Descrição (opcional): insira uma descrição para o gatilho.

   • Evento: selecione Evento de webhook como o evento do repositório para invocar o gatilho.

     Se o Secret Manager não estiver instalado, você vai receber uma solicitação para ativar o Secret Manager.

   • URL do webhook: selecione uma das seguintes opções:

     • Usar um novo secret se você quiser gerar um novo secret usando o Cloud Build. Clique em Criar secret para criar o secret.
     • Use um secret existente ou crie um próprio se quiser usar um secret atual. Insira o secret e a versão nas caixas de seleção do menu suspenso.

     Se você usar um secret existente, talvez seja necessário conceder manualmente o papel de Acessador de secrets do Secret Manager ao agente de serviço do Cloud Build [e-mail].

     Para saber mais, consulte Como conceder um papel ao agente de serviço do Cloud Build.

7. Clique em Mostrar visualização do URL e registre o URL. Você precisa desse URL para configurar o webhook no Secure Source Manager.

   • Configuração: em Tipo, selecione Arquivo de configuração do Cloud Build (YAML ou JSON) e em Local, selecione Inline.

8. Clique no botão Abrir editor para editar o arquivo de configuração de build.

9. Copie o conteúdo do arquivo cloudbuild.yaml no editor.

   Como discutido anteriormente, esse pipeline tem comportamentos diferentes, dependendo do branch que está sendo buscado. A construção verifica se a variável ${branch} corresponde a alguma pasta do ambiente. Nesse caso, o Cloud Build executa terraform plan para esse ambiente. Caso contrário, o Cloud Build executa terraform plan em todos os ambientes para garantir que a mudança proposta seja adequada para todos eles. Se a execução de algum desses planos falhar, a compilação falhará.

   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform plan
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFOM PLAN ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform plan || exit 1
             cd ../../
           done
         fi

   O comando terraform apply é executado para ramificações do ambiente, mas é completamente ignorado em qualquer outro caso.

10. Clique em + Adicionar variável e inclua as duas variáveis de substituição a seguir:

    • Variável: _REPO_URL, Valor:$(body.repository.clone_url)
    • Variável: _REF, Valor:$(body.ref)

11. Clique em Criar.

Configurar um webhook no Secure Source Manager

Crie um webhook para acionar builds em pushes para as ramificações dev ou prod.

1. Na interface da Web do Secure Source Manager, navegue até o repositório em que você quer criar um webhook.
2. Clique em Configurações.
3. Clique em Webhooks e em Adicionar webhook.

4. No campo ID do hook, insira um ID para o webhook.

   Observação: os IDs de hook precisam seguir a convenção de nomenclatura de recursos. Eles precisam incluir apenas letras minúsculas, números ou traços, começar com uma letra e não podem ser alterados depois da criação do webhook.

5. No campo URL de destino, insira o URL do webhook que você copiou ao configurar um gatilho de webhook no Cloud Build.

   Para encontrar o URL do webhook:

   1. Abra a página Gatilhos no console do Google Cloud .

      Abrir a página Acionadores

   2. Clique no acionador.

   3. Na seção URL do webhook, clique em Mostrar visualização do URL e copie o URL.

6. O URL do webhook contém os valores de chave e secret inseridos quando você criou o gatilho do Cloud Build. Para evitar o vazamento desses valores, remova-os do final do URL de destino e copie para o campo String de consulta sensível.

   Para localizar sua chave e seu secret no URL do webhook, procure o texto que começa com key=

   Por exemplo, considerando o seguinte URL: https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager

   Copie e remova a parte que começa com o ponto de interrogação ?key=... do campo URL de destino. Em seguida, remova o ponto de interrogação inicial e mova a parte restante key=... para o campo String de consulta sensível.

7. Clique em Add webhook.

8. O webhook é exibido na página Webhooks.

   Observação: ao adicionar ou editar um webhook, o comprimento do Sensitive Query String pode ser inconsistente com o inserido, o que é esperado, já que strings de substituição são usadas para garantir a segurança.

Alterar a configuração do ambiente em um novo branch de recurso

1. Verifique se você está na ramificação dev:

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout dev
   

2. Extraia as mudanças mais recentes:

   git pull
   

3. Crie uma ramificação bug-fix para mudar a configuração do ambiente.

   git checkout -b bug-fix
   

4. Abra modules/firewall/main.tf para editar.

5. Na linha 30, corrija o erro de digitação "http-server2" no campo target_tags.

   O valor precisa ser "http-server".

6. Confirme e envie suas alterações por push:

   git add --all
   git commit -m "Fix typo."
   git push google -u bug-fix
   

7. Abra a página Histórico do Cloud Build no console Google Cloud :

   Abrir a página "Histórico"

8. Clique em Build para ver mais informações, incluindo a saída do terraform plan.

Observe que o job Cloud Build executou o pipeline definido no arquivo cloudbuild.yaml. Como discutido anteriormente, esse pipeline tem comportamentos diferentes, dependendo do branch que está sendo buscado. A construção verifica se a variável ${branch} corresponde a alguma pasta do ambiente. Nesse caso, o Cloud Build executa terraform plan para esse ambiente. Caso contrário, o Cloud Build executa terraform plan em todos os ambientes para garantir que a alteração proposta seja apropriada para todos eles. Se a execução de algum desses planos falhar, a compilação falhará.

- id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      branch=$(basename "$_REF")
      if [ -d "environments/${branch}/" ]; then
        cd environments/${branch}
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFOM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

Da mesma forma, o comando terraform apply é executado para ramificações do ambiente, mas é completamente ignorado em qualquer outro caso. Nesta seção, você enviou uma mudança de código para um novo branch. Portanto, nenhuma implantação de infraestrutura foi aplicada ao seu projeto Google Cloud .

- id: 'tf apply' name: 'hashicorp/terraform:1.0.0' entrypoint: 'sh' args: - '-c' - | branch=$(basename "$_REF") if [ -d "environments/${branch}/" ]; then cd environments/${branch} terraform apply -auto-approve else echo "***************************** SKIPPING APPLYING *******************************" echo "Branch '${branch}' does not represent an official environment." echo "*******************************************************************************" fi

Como promover alterações no ambiente de desenvolvimento

É hora de aplicar o estado que você quer ao seu ambiente dev.

1. Na interface da Web do Secure Source Manager, navegue até o repositório.
2. Clique em Nova solicitação de envio.
3. No campo mesclar em:, selecione sua ramificação dev.
4. No campo Extrair de, selecione sua ramificação bug-fix.
5. Clique em New pull request.
6. Clique em Criar solicitação de envio.
7. Clique em Mesclar solicitação de envio e depois em Mesclar solicitação de envio novamente.

8. Verifique se um novo Cloud Build foi acionado:

   Acessar a página do Cloud Build

9. Abra a compilação e verifique os registros.

   Quando a compilação terminar, você verá algo assim:

   Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
   Step #3 - "tf apply": firewall_rule = dev-allow-http
   Step #3 - "tf apply": instance_name = dev-apache2-instance
   Step #3 - "tf apply": network = dev
   Step #3 - "tf apply": subnet = dev-subnet-01
   

10. Copie EXTERNAL_IP_VALUE e abra o endereço em um navegador da web.

    http://EXTERNAL_IP_VALUE
    

    Esse provisionamento pode levar alguns segundos para inicializar a VM e propagar a regra do firewall. Por fim, você vai ver Ambiente: dev no navegador da Web.

11. Acesse o Cloud Storage:

    Acessar a página do Cloud Storage

12. Selecione o projeto.

13. Clique no bucket de armazenamento de estado do Terraform. O nome do bucket é semelhante a este:

    PROJECT_ID-tfstate
    

14. Clique em env e em dev para ver o arquivo de estado do Terraform.

Como promover alterações no ambiente de produção

Agora que seu ambiente de desenvolvimento foi totalmente testado, promova seu código de infraestrutura para produção.

1. Na interface da Web do Secure Source Manager, navegue até o repositório.
2. Clique na guia Pull requests.
3. Clique em New pull request.
4. Em Fazer merge em, selecione a ramificação prod do seu repositório.
5. Em Extrair de, selecione a ramificação dev do seu repositório.
6. Clique em New pull request.
7. Em título, insira um título como "Promoting networking changes" e clique em Criar solicitação de envio.

8. Revise as mudanças propostas e clique em Mesclar solicitação de envio.

   A data e o URL do repositório são adicionados no campo de comentário.

9. Clique em Merge pull request novamente para confirmar.

10. No Google Cloud console, abra a página Histórico de versões para ver as mudanças sendo aplicadas ao ambiente de produção:

    Acessar a página do Cloud Build

11. Aguarde o término da compilação e verifique os registros.

    No final dos registros, você verá algo assim:

    Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
    Step #3 - "tf apply": firewall_rule = prod-allow-http
    Step #3 - "tf apply": instance_name = prod-apache2-instance
    Step #3 - "tf apply": network = prod
    Step #3 - "tf apply": subnet = prod-subnet-01
    

12. Copie EXTERNAL_IP_VALUE e abra o endereço em um navegador da web.

    http://EXTERNAL_IP_VALUE
    

    Esse provisionamento pode levar alguns segundos para inicializar a VM e propagar a regra do firewall. Em algum momento você vai ver Ambiente: prod no navegador da Web.

13. Acesse o Cloud Storage:

    Acessar a página do Cloud Storage

14. Selecione o projeto.

15. Clique no bucket de armazenamento de estado do Terraform. O nome do bucket é semelhante a este:

    PROJECT_ID-tfstate
    

16. Clique em env e em prod para conferir o arquivo de estado do Terraform.

Você configurou com êxito um pipeline de infraestrutura como código sem servidor no Cloud Build. No futuro, tente realizar as ações a seguir:

• Adicione implantações para casos de uso separados.
• Crie ambientes adicionais para refletir suas necessidades.
• Use um projeto por ambiente em vez de uma VPC por ambiente.

Limpar

Após concluir o tutorial, limpe os recursos que você criou em Google Cloud para não receber cobranças por eles no futuro.

Excluir o projeto

Cuidado: excluir um projeto tem os seguintes efeitos:

• Tudo no projeto é excluído. Se você tiver usado um projeto atual para as tarefas neste documento, a exclusão dele vai resultar na exclusão de outros trabalhos feitos nele.
• Os IDs de projeto personalizados são perdidos. É possível que, ao criar o projeto, você tenha criado um ID de projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja explorar várias arquiteturas, tutoriais e guias de início rápido, a reutilização de projetos pode evitar que você exceda limites da cota.

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.

A seguir

• Considere usar os modelos do Cloud Foundation Toolkit para criar rapidamente uma base empresarial repetível noGoogle Cloud.
• Assista a Ambientes repetíveis do GCP em escala com pipelines de infraestrutura como código do Cloud Build (em inglês) da Next' 19 sobre o fluxo de trabalho do GitOps descrito neste tutorial. Google Cloud
• Confira o tutorial Entrega contínua no estilo GitOps com o Cloud Build.
• Confira os recursos mais avançados do Cloud Build: Como configurar a ordem das etapas de versão, Como criar, testar e implantar artefatos e Como criar etapas personalizadas de versão.
• Confira o blog em Como garantir a escala e a conformidade da sua implantação do Terraform com o Cloud Build.
• Leia nossos recursos sobre DevOps.
• Saiba mais sobre os recursos de DevOps relacionados a este tutorial:
  • Controle de versões
  • Integração contínua
  • Entrega contínua
  • Teste contínuo
• Faça a verificação rápida de DevOps para entender sua posição em relação ao restante do setor.