Este artigo resume várias abordagens ao trabalhar com o Terraform, tanto individualmente quanto em equipe. Tentei reunir os mais comuns, mas você também pode desenvolver o seu próprio.

O requisito comum para todos eles é um sistema de controle de versão (como o Git). É assim que você garante que nada seja perdido e que todas as suas alterações de código tenham controle de versão adequado.

Índice:

‌‌

Conceitos Básicos

Vamos definir as ações básicas primeiro.

Todos os fluxos de trabalho descritos baseiam-se em três etapas principais: escrever, planejar e aplicar. No entanto, seus detalhes e ações variam entre os fluxos de trabalho.

image 79

Escrever – aqui é onde você faz alterações no código.

Plano – aqui é onde você analisa as alterações e decide se as aceita.

Aplique – é aqui que você aceita as alterações e as aplica na infraestrutura real.

É uma ideia simples com uma variedade de implementações possíveis.

Fluxo de trabalho individual central

Este é o fluxo de trabalho mais simples se você trabalhar sozinho em um projeto TF relativamente pequeno. Esse fluxo de trabalho é adequado tanto para back-ends locais quanto remotos.

image 78

Escrever

Você clona o repositório de código remoto ou extrai as alterações mais recentes, edita o código de configuração e executa o terraform validate e terraform fmt comandos para garantir que seu código funcione bem.

Plano

É aqui que você executa o terraform plan comando para certificar-se de que suas alterações fazem o que você precisa. Este é um bom momento para confirmar suas alterações de código (ou você pode fazer isso na próxima etapa).

Aplique

É quando você corre terraform apply e introduzir as mudanças em objetos de infraestrutura reais. Além disso, é quando você envia as alterações confirmadas para o repositório remoto.

Fluxo de trabalho da equipe principal

Este fluxo de trabalho é bom para quando você trabalha com código de configuração em uma equipe e deseja usar ramificações de recursos para gerenciar as alterações com precisão.

image 80

Escrever

Comece verificando um novo branch, faça suas alterações e execute o terraform validate e terraform fmt comandos para garantir que seu código funcione bem.

Corrida terraform plan nesta etapa ajudará a garantir que você obtenha o que espera.

Plano

É aqui que acontecem as revisões de código e plano.

Adicione a saída do terraform plan ao Pull Request com suas alterações. Seria uma boa ideia adicionar apenas as partes alteradas da saída comum, que é a parte que começa com “O Terraform realizará as seguintes ações” corda.

Aplique

Uma vez que o PR é revisado e mesclado com o branch upstream, é seguro finalmente puxar o branch upstream localmente e aplicar a configuração com terraform apply.

Fluxo de trabalho da equipe com automação

Em suma, este fluxo de trabalho permite que você introduza um tipo de teste de fumaça para seu código de infraestrutura (usando plan) e também para automatizar o feedback no processo de IC.

A parte automatizada deste fluxo de trabalho consiste em um plano especulativo de confirmação e / ou solicitação de pull (PR), junto com a adição da saída de plan ao comentário do PR. Um plano especulativo significa apenas mostrar as mudanças, e não aplicá-las posteriormente.

‌‌

image 81

Escrever

Esta etapa é igual à do fluxo de trabalho anterior.

Plano

É aqui que sua ferramenta de CI faz seu trabalho.

Vamos revisar isso passo a passo:

  1. Você cria um PR com as alterações de código que deseja implementar.
  2. O pipeline de CI é acionado por um evento de seu repositório de código (como webhook push) e executa um plano especulativo em seu código.
  3. A lista de mudanças (a chamada “diferença de plano”) é adicionada ao PR para revisão pelo IC.
  4. Depois de mesclado, o pipeline de CI é executado novamente e você obtém o plano final que está pronto para ser aplicado à infraestrutura.

Aplique

Agora que você tem um branch (ou seja, principal) com o novo código a ser aplicado, você precisa puxá-lo localmente e executar terraform apply.

Você também pode adicionar o aplicativo automatizado aqui – etapa 5 na imagem abaixo. Isso pode ser muito útil para ambientes descartáveis, como teste, teste, desenvolvimento e assim por diante.

A ferramenta de CI exata a ser usada aqui depende de você: Jenkins, GitHub Actions e Travis CI funcionam bem.

Uma coisa importante a observar é que o pipeline de CI deve ser configurado de forma bidirecional com seu repositório para obter o código dele e relatar de volta com comentários ao PR.

Como opção, você pode considerar o uso do Terraform Cloud, que tem muitas funcionalidades, incluindo a integração de repo mencionada acima, mesmo com a assinatura gratuita.

Se você nunca trabalhou com o Terraform Cloud antes e deseja um conselho para começar, fornecerei os links no final deste artigo.

Fluxo de trabalho de importação

‌‌Este fluxo de trabalho se refere a uma situação em que alguns objetos já foram criados (ou seja, ativos e em execução) e você precisa gerenciá-los com o Terraform.

Suponha que já tenhamos um bucket S3 na AWS chamado “someassetsbucket” e queiramos incluí-lo em nosso código de configuração.‌‌

image 82

Preparar

Você deve criar um bloco de recursos para ser usado posteriormente para o objeto real que você vai importar.

Você não precisa preencher os argumentos no início, então pode ser apenas um bloco de recursos em branco, por exemplo:

resource "aws_s3_bucket" "assets" {‌‌}

Importar

Agora você precisa importar as informações sobre o objeto real em seu arquivo de estado existente do Terraform.

Isso pode ser feito com o terraform import comando, por exemplo:

terraform import aws_s3_bucket.assets "someassetsbucket"
‌ Certifique-se de verificar também a lista de opções possíveis import aceita com terraform import -h

Escrever

Agora você precisa escrever o código Terraform correspondente para este intervalo.

Para evitar modificar seu objeto real no terraform apply ação, você deve especificar todos os argumentos necessários com os valores exatos da fase de importação.

Você pode ver os detalhes executando o terraform state show comando, por exemplo:

terraform state show aws_s3_bucket.assets

A saída deste comando será muito semelhante ao código de configuração. Mas ele contém argumentos e atributos do recurso, portanto, você precisa limpá-lo antes de aplicá-lo.

Você pode usar uma das seguintes táticas:

  • copie / cole e execute terraform validate e terraform plan várias vezes para garantir que não haja erros como “argumento não é esperado aqui“ou”este campo não pode ser definido“
  • ou você pode escolher e escrever apenas os argumentos necessários

Em qualquer caso, certifique-se de consultar a documentação do recurso durante este processo.

Plano

O objetivo é ter um terraform plan saída mostrando “~ atualização no local“muda apenas.

No entanto, nem sempre está claro se o objeto real será modificado ou apenas o arquivo de estado será atualizado. É por isso que você deve entender como funciona um objeto real e saber seu ciclo de vida para ter certeza de que é seguro aplicar o plano.

Aplique

Isso é normal terraform apply açao.

Uma vez aplicado, sua configuração e arquivo de estado corresponderão à configuração real do objeto.

Empacotando

Esta é uma visão geral do Terraform Cloud para quem nunca trabalhou com ele antes: ‌‌Visão geral dos recursos do Terraform Cloud

E aqui está um bom tutorial para começar: Primeiros passos – Terraform Cloud

Além disso, aqui está uma visão geral dos fluxos de trabalho em escala do HashiCorp CTO que pode ser útil para usuários mais experientes do Terraform: Práticas recomendadas de fluxo de trabalho do Terraform em escala

Obrigado por ler. Espero que você experimente um desses fluxos de trabalho ou desenvolva o seu próprio! ‌‌

‌‌