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

Este tutorial explica como gerir a infraestrutura como código com o Terraform e o Cloud Build através da popular metodologia GitOps. O termo GitOps foi cunhado pela primeira vez pela Weaveworks, e o seu conceito principal é usar um repositório Git para armazenar o estado do ambiente que quer. O Terraform é uma ferramenta de código aberto da HashiCorp que lhe permite criar, alterar e melhorar de forma previsível a sua infraestrutura na nuvem através de código. Neste tutorial, vai usar o Cloud Build, um serviço de integração contínua, para aplicar automaticamente manifestos do Terraform ao seu ambiente. Google Cloud

Este tutorial destina-se a programadores e operadores que procuram uma estratégia elegante para fazer alterações previsíveis à infraestrutura. O artigo pressupõe que conhece o Google Cloude o Linux.

Os relatórios State of DevOps identificaram capacidades que impulsionam o desempenho da entrega de software. Este tutorial vai ajudar com as seguintes capacidades:

• Controlo de versões
• Integração contínua
• Fornecimento contínuo
• Testes contínuos

Arquitetura

Este tutorial aplica práticas de GitOps para gerir execuções do Terraform. Tenha em atenção que usa ramificações do Secure Source Manager dev e prod para representar ambientes reais. Estes ambientes são definidos pelas redes da nuvem virtual privada (VPC) dev e prod, respetivamente, numGoogle Cloud projeto.

O processo começa quando envia código do Terraform para o ramo dev ou prod. Neste cenário, o Cloud Build aciona e, em seguida, aplica os manifestos do Terraform para alcançar o estado pretendido no ambiente respetivo. Por outro lado, quando envia código do Terraform para qualquer outro ramo, por exemplo, para um ramo de funcionalidade, o Cloud Build é executado para executar terraform plan, mas não é aplicado nada a nenhum ambiente.

Idealmente, os programadores ou os operadores têm de fazer propostas de infraestrutura para ramificações de desenvolvimento ou de funcionalidades e, em seguida, enviá-las através de pedidos de obtenção. Desta forma, pode discutir e rever as potenciais alterações com os colaboradores e adicionar commits de seguimento antes de as alterações serem unidas no ramo base.

Se não forem levantadas preocupações, tem de unir primeiro as alterações ao ramo dev Esta união aciona uma implementação de infraestrutura no ambiente dev, o que lhe permite testar este ambiente. Depois de testar e ter a certeza do que foi implementado, tem de unir a ramificação dev à ramificação prod para acionar a instalação da infraestrutura no ambiente de produção.

Objetivos

• Configure a instância e o repositório do Secure Source Manager.
• Configure o Terraform para armazenar o estado num contentor do Cloud Storage.
• Conceda autorizações à sua conta de serviço do Cloud Build.
• Associe o Cloud Build ao seu repositório do Secure Source Manager.
• Altere a configuração do ambiente numa ramificação de funcionalidades.
• Promova alterações para o ambiente de desenvolvimento.
• Promova alterações para o ambiente de produção.

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

• Cloud Build
• Cloud Storage
• Compute Engine

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

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.

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.

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.

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.

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, obtenha o ID do projeto que acabou de selecionar:

   gcloud config get-value project

   Se este comando não devolver o ID do projeto, configure o Cloud Shell para usar o seu projeto. Substitua PROJECT_ID pelo ID do seu 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

   Este passo pode demorar alguns minutos a ser concluído.
4. Se nunca usou o Git no Cloud Shell, configure-o com o seu nome e endereço de email:

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

   O Git usa estas informações para identificar o utilizador como o autor das confirmações que cria na Cloud Shell.

Configure o seu repositório do Secure Source Manager

Neste tutorial, vai usar um único repositório do Secure Source Manager para definir a sua infraestrutura na nuvem. Orquestra esta infraestrutura com diferentes ramificações correspondentes a diferentes ambientes:

• O ramo dev contém as alterações mais recentes que são aplicadas ao ambiente de desenvolvimento.
• O ramo prod contém as alterações mais recentes que são aplicadas ao ambiente de produção.
• Os ramos de funcionalidades semelhantes a feature_x são usados para fazer alterações antes de enviar para os ramos dev ou prod.

Com esta infraestrutura, pode sempre consultar o repositório para saber que configuração é esperada em cada ambiente e propor novas alterações, primeiro, ao juntá-las ao ambiente dev. Em seguida, promove as alterações ao unir a ramificação dev à ramificação prod subsequente.

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

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

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

   O auxiliar de autenticação usa a CLI gcloud para obter as suas Google Cloud credenciais quando usa comandos Git com o Secure Source Manager.

3. Para autenticar novamente 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 para o shell local ou o ambiente de trabalho:

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

5. Adicione o 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. Pode encontrar o URL na parte superior da página do repositório na interface 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 repositório com o seguinte comando:

   git push -u google --all
   

8. Repita os dois passos anteriores para a ramificação prod.

O código neste repositório está estruturado da seguinte forma:

• A pasta environments/ contém subpastas que representam ambientes, como dev e prod, que oferecem uma separação lógica entre cargas de trabalho em diferentes fases de maturidade, desenvolvimento e produção, respetivamente. Embora seja uma boa prática ter estes ambientes o mais semelhantes possível, cada subpasta tem a sua própria configuração do Terraform para garantir que podem ter definições únicas, conforme necessário.

• A pasta modules/ contém módulos Terraform incorporados. Estes módulos representam agrupamentos lógicos de recursos relacionados e são usados para partilhar código em diferentes ambientes.

• O ficheiro cloudbuild.yaml é um ficheiro de configuração de compilação que contém instruções para o Cloud Build, como a forma de realizar tarefas com base num conjunto de passos. Este ficheiro especifica uma execução condicional consoante o ramo do qual o Cloud Build está a obter o código, por exemplo:

  • Para os ramos dev e prod, são executados os seguintes passos:

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

  • Para qualquer outro ramo, são executados os seguintes passos:

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

Para garantir que as alterações propostas são adequadas para todos os ambientes, os comandos terraform init e terraform plan são executados para todas as environments subpastas. Antes de unir o pedido de envio, pode rever os planos para se certificar de que o acesso não está a ser concedido a uma entidade não autorizada, por exemplo.

Modifique o ficheiro de configuração da compilação

Para fazer com que o ficheiro de configuração de compilação de exemplo funcione com o Secure Source Manager, tem de fazer as seguintes edições:

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

Edite o ficheiro de configuração da compilação no ramo dev:

1. Alterar para o ramo dev:

   git checkout dev
   

2. Abra o ficheiro 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 ficheiro foi modificado.

   git status
   

4. Confirme e envie as alterações:

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

5. Abra um pedido de obtenção para promover rapidamente as suas alterações para a ramificação prod.

   1. Na interface Web do Secure Source Manager, navegue para o seu repositório.
   2. Clique no separador Pedidos de obtenção.
   3. Clique em Novo pedido de envio.
   4. No campo Unir em:, selecione a ramificação prod.
   5. No campo Extrair de:, selecione a ramificação dev.
   6. Reveja as alterações e, de seguida, clique em Novo pedido de obtenção.
   7. Clique em Criar pedido de obtenção.
   8. Clique em Unir pedido de envio.

   9. Clique novamente em Unir pedido de envio.

      As alterações são unidas na ramificação prod.

Configurar o Terraform para armazenar o estado num contentor do Cloud Storage

Por predefinição, o Terraform armazena o estado localmente num ficheiro denominado terraform.tfstate. Esta configuração predefinida pode dificultar a utilização do Terraform para as equipas, especialmente quando muitos utilizadores executam o Terraform ao mesmo tempo e cada máquina tem a sua própria compreensão da infraestrutura atual.

Para ajudar a evitar estes problemas, esta secção configura um estado remoto que aponta para um contentor do Cloud Storage. O estado remoto é uma funcionalidade dos servidores de back-end e, neste tutorial, é configurado nos ficheiros 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"
  }
}

Nos passos seguintes, cria um contentor do Cloud Storage e altera alguns ficheiros para apontarem para o novo contentor e o seu Google Cloud projeto.

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

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

2. Ative a versão de objetos para manter o histórico das suas implementações:

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

   A ativação da criação de versões de objetos aumenta os custos de armazenamento, que pode mitigar configurando a Gestão do ciclo de vida de objetos para eliminar versões de estado anteriores.

3. Crie uma nova ramificação cloud-storage-bucket para fazer as alterações:

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

4. Substitua o marcador de posição PROJECT_ID pelo ID do projeto nos ficheiros 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, pode ter de adicionar duas aspas ("") após sed -i, da seguinte forma:

   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 ficheiros foram atualizados:

   git status
   

   O resultado tem o seguinte aspeto:

   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 as alterações:

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

   O novo ramo cloud-storage-bucket é enviado para o seu repositório.

7. Mescle as alterações do cloud-storage-bucket nos ramos dev e prod abrindo e enviando pedidos de mesclagem para cada ramo.

Conceda autorizaçõ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 gerir recursos, tem de lhe conceder o acesso adequado ao seu projeto. Google Cloud Para simplificar, o acesso de editor do projeto é concedido neste tutorial. Para ambientes de produção, siga as práticas recomendadas de segurança de TI da sua empresa, normalmente fornecendo acesso com privilégios mínimos.

Nota: a conta de serviço predefinida do Cloud Build usada para executar compilações vai ser alterada. Como prática recomendada, sugerimos que especifique a sua própria conta de serviço para executar as compilações. Para mais informações, consulte o artigo Alteração da conta de serviço do Cloud Build.

1. Para encontrar o email da conta de serviço do Cloud Build, na página do Cloud Build, navegue para Definições.

   Aceda às definições do Cloud Build

2. Copie o valor do email 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 o seguinte:

   • PROJECT_ID com o ID do seu projeto.
   • CLOUDBUILD_SA com o email da conta de serviço do Cloud Build.

Ligue-se ao Cloud Build

Para acionar o Cloud Build numa inserção em qualquer ramificação, configure um webhook do Secure Source Manager. O ficheiro de configuração da compilação verifica o nome do ramo para determinar se é necessário fazer alterações aos ambientes dev ou prod.

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

2. Abra a página Acionadores na Google Cloud consola.

   Abra a página Acionadores

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

4. Clique em Abrir.

5. Clique em Criar acionador.

6. Introduza as seguintes definições do acionador:

   • Nome: trigger-on-push

   • Região: selecione a região para o seu acionador. Se o ficheiro de configuração de compilação associado ao acionador especificar um pool privado, a região que selecionar para o acionador tem de corresponder à região do pool privado.

     Nota: se usar um conjunto privado, tem de atribuir IPs externos para permitir que o seu conjunto privado aceda à Internet pública. Para mais detalhes, consulte o artigo Criar um novo conjunto privado.

     Se selecionar global como região, o Cloud Build usa a região especificada no ficheiro de configuração da compilação para executar a compilação. Pode ser a região do conjunto privado, se especificar um conjunto privado no ficheiro de configuração de compilação, ou o conjunto predefinido global se não especificar um conjunto privado.

   • Descrição (opcional): introduza uma descrição para o acionador.

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

     Se o Secret Manager não estiver instalado, é-lhe pedido que ative o Secret Manager.

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

     • Use um novo segredo se quiser gerar um novo segredo através do Cloud Build. Clique em Criar segredo para criar o seu segredo.
     • Use um segredo existente ou crie o seu próprio se quiser usar um segredo existente. Introduza o segredo e a versão nas caixas de seleção do menu pendente.

     Se usar um segredo existente, pode ter de conceder manualmente a função Secret Manager Secret Accessor ao agente de serviço do Cloud Build [e-mail].

     Para saber mais, consulte o artigo Conceder uma função ao agente de serviço do Cloud Build.

7. Clique em Mostrar pré-visualização do URL e registe o URL. Precisa deste URL para configurar o webhook no Secure Source Manager.

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

8. Clique no botão Abrir editor para editar o ficheiro de configuração de compilação.

9. Copie o conteúdo do ficheiro cloudbuild.yaml para o editor.

   Conforme abordado anteriormente, este pipeline tem comportamentos diferentes consoante a ramificação que está a ser obtida. A compilação verifica se a variável ${branch} corresponde a alguma pasta de ambiente. Se for o caso, o Cloud Build executa terraform plan para esse ambiente. Caso contrário, o Cloud Build executa terraform plan para todos os ambientes para garantir que a alteração proposta é adequada para todos eles. Se algum destes planos não for executado, a compilação falha.

   - 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 adicione as seguintes duas variáveis de substituição:

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

11. Clique em Criar.

Configure um webhook no Secure Source Manager

Crie um webhook para acionar compilações em envios para os ramos dev ou prod.

1. Na interface Web do Secure Source Manager, navegue para o repositório para o qual quer criar um webhook.
2. Clique em Definições.
3. Clique em Webhooks e, de seguida, em Adicionar webhook.

4. No campo ID do comando, introduza um ID para o webhook.

   Nota: os IDs dos hooks têm de seguir a convenção de nomenclatura de recursos. Têm de incluir apenas letras minúsculas, números ou traços, têm de começar por uma letra e não podem ser alterados após a criação do webhook.

5. No campo URL de destino, introduza o URL do webhook que copiou quando configurou um acionador de webhook no Cloud Build.

   Para encontrar o URL do webhook:

   1. Abra a página Acionadores na Google Cloud consola.

      Abra a página Acionadores

   2. Clique no acionador.

   3. Na secção URL do webhook, clique em Mostrar pré-visualização do URL e copie o URL.

6. O URL do webhook contém os valores da chave e do segredo introduzidos quando criou o acionador do Cloud Build. Para evitar a fuga destes valores, remova-os do final do URL de destino e copie-os para o campo String de consulta sensível.

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

   Por exemplo, dado 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, mova a parte restante key=... para o campo String de consulta sensível.

7. Clique em Adicionar webhook.

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

   Nota: quando adiciona ou edita um webhook, o comprimento do Sensitive Query String pode ser inconsistente com o introduzido, o que é esperado, uma vez que as strings de marcadores de posição são usadas para garantir a segurança.

Altere a configuração do ambiente num novo ramo de funcionalidades

1. Certifique-se de que está na ramificação dev:

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

2. Extraia as alterações mais recentes:

   git pull
   

3. Crie uma ramificação bug-fix para alterar 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 ortográfico "http-server2" no campo target_tags.

   O valor tem de ser "http-server".

6. Confirme e envie as alterações:

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

7. Abra a página Histórico do Cloud Build na Google Cloud consola:

   Abra a página Histórico

8. Clique em Criar para ver mais informações, incluindo o resultado do terraform plan.

Tenha em atenção que a tarefa do Cloud Build executou o pipeline definido no ficheiro cloudbuild.yaml. Conforme abordado anteriormente, este pipeline tem comportamentos diferentes consoante a ramificação que está a ser obtida. A compilação verifica se a variável ${branch} corresponde a alguma pasta de ambiente. Se for o caso, o Cloud Build executa terraform plan para esse ambiente. Caso contrário, o Cloud Build executa terraform plan para todos os ambientes para garantir que a alteração proposta é adequada para todos eles. Se algum destes planos não for executado, a compilação falha.

- 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 secção, enviou uma alteração de código para um novo ramo, pelo que não foram aplicadas implementações de infraestrutura ao seu Google Cloud projeto.

- 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

Promover alterações para o ambiente de programação

Está na altura de aplicar o estado pretendido ao seu ambiente dev.

1. Na interface Web do Secure Source Manager, navegue para o seu repositório.
2. Clique em Novo pedido de obtenção
3. No campo Unir em:, selecione a ramificação dev.
4. No campo Extrair de:, selecione a ramificação bug-fix.
5. Clique em Novo pedido de envio.
6. Clique em Criar pedido de obtenção.
7. Clique em Unir pedido de envio e, de seguida, clique novamente em Unir pedido de envio.

8. Verifique se foi acionado um novo Cloud Build:

   Aceda à página do Cloud Build

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

   Quando a compilação terminar, vê algo semelhante ao seguinte:

   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 num navegador de Internet.

    http://EXTERNAL_IP_VALUE
    

    Este aprovisionamento pode demorar alguns segundos a arrancar a VM e a propagar a regra de firewall. Eventualmente, vê Environment: dev no navegador de Internet.

11. Navegue para o Cloud Storage:

    Aceda à página do Cloud Storage

12. Selecione o seu projeto.

13. Clique no seu contentor de armazenamento de estado do Terraform. O nome do contentor tem o seguinte aspeto:

    PROJECT_ID-tfstate
    

14. Clique em env e, de seguida, em dev para ver o ficheiro de estado do Terraform.

Promover alterações para o ambiente de produção

Agora que tem o ambiente de desenvolvimento totalmente testado, pode promover o código de infraestrutura para produção.

1. Na interface Web do Secure Source Manager, navegue para o seu repositório.
2. Clique no separador Pedidos de obtenção.
3. Clique em Novo pedido de envio.
4. Para Unir em:, selecione a ramificação prod do seu repositório.
5. Para Extrair de:, selecione a ramificação dev do repositório.
6. Clique em Novo pedido de envio.
7. Para o título, introduza um título como "Promover alterações de rede" e, em seguida, clique em Criar pedido de obtenção.

8. Reveja as alterações propostas e, de seguida, clique em Unir pedido de obtenção.

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

9. Clique novamente em Unir pedido de envio para confirmar.

10. Na Google Cloud consola, abra a página Histórico de compilações para ver as alterações aplicadas ao ambiente de produção:

    Aceda à página do Cloud Build

11. Aguarde a conclusão da compilação e, em seguida, verifique os registos.

    No final dos registos, vê algo semelhante ao seguinte:

    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 num navegador de Internet.

    http://EXTERNAL_IP_VALUE
    

    Este aprovisionamento pode demorar alguns segundos a arrancar a VM e a propagar a regra de firewall. Eventualmente, vê Environment: prod no navegador de Internet.

13. Navegue para o Cloud Storage:

    Aceda à página do Cloud Storage

14. Selecione o seu projeto.

15. Clique no seu contentor de armazenamento de estado do Terraform. O nome do contentor tem o seguinte aspeto:

    PROJECT_ID-tfstate
    

16. Clique em env e, de seguida, em prod para ver o ficheiro de estado do Terraform.

Configurou com êxito um pipeline de infraestrutura como código sem servidores no Cloud Build. No futuro, pode experimentar o seguinte:

• Adicione implementações para exemplos de utilização separados.
• Crie ambientes adicionais para refletir as suas necessidades.
• Use um projeto por ambiente em vez de uma VPC por ambiente.

Limpar

Depois de concluir o tutorial, limpe os recursos que criou no Google Cloud para que não lhe sejam faturados no futuro.

Eliminar o projeto

Atenção: a eliminação de um projeto tem os seguintes efeitos:

• Tudo no projeto é eliminado. Se usou um projeto existente para as tarefas neste documento, quando o elimina, também elimina qualquer outro trabalho que tenha feito no projeto.
• Os IDs dos projetos personalizados são perdidos. Quando criou este projeto, pode ter criado um ID do projeto personalizado que quer usar no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, elimine os recursos selecionados no projeto em vez de eliminar o projeto inteiro.

Se planeia explorar várias arquiteturas, tutoriais ou inícios rápidos, a reutilização de projetos pode ajudar a evitar exceder os limites de quota de projetos.

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.

O que se segue?

• Considere usar os modelos do Cloud Foundation Toolkit para criar rapidamente uma base repetível pronta para a empresa no Google Cloud.
• Veja o vídeo Repeatable Google Cloud Environments at Scale With Cloud Build Infra-As-Code Pipelines do Next' 19 sobre o fluxo de trabalho do GitOps descrito neste tutorial.
• Consulte o tutorial Fornecimento contínuo ao estilo GitOps com o Cloud Build.
• Veja mais funcionalidades avançadas do Cloud Build: configurar a ordem dos passos de compilação, criar, testar e implementar artefactos e criar passos de compilação personalizados.
• Consulte o blogue sobre como garantir a escala e a conformidade da sua implementação do Terraform com o Cloud Build.
• Leia os nossos recursos sobre DevOps.
• Saiba mais sobre as capacidades de DevOps relacionadas com este tutorial:
  • Controlo de versões
  • Integração contínua
  • Fornecimento contínuo
  • Testes contínuos
• Faça a verificação rápida de DevOps para saber a sua posição em comparação com o resto da indústria.