A documentação oficial do Terraform descreve todos os aspectos da configuração em detalhes. Leia-o com atenção para entender o restante desta seção.

Recursos

Um recurso é aws_vpc, aws_db_instance, etc. Um recurso pertence a um provedor, aceita argumentos, produz atributos e tem ciclos de vida. Um recurso pode ser criado, recuperado, atualizado e excluído.

Módulo de Recursos

O módulo de recursos é uma coleção de recursos conectados, que juntos, executam a ação comum (por exemplo, o módulo AWS VPC Terraform cria VPC, sub-redes, gateway NAT, etc.). Depende da configuração do provedor, que pode ser definida nele, ou em estruturas de nível superior (por exemplo, no módulo de infraestrutura).

Módulo de infraestrutura

Um módulo de infraestrutura é uma coleção de módulos de recursos, que podem ser logicamente não conectados, mas na situação/projeto/configuração atual servem ao mesmo propósito. Ele define a configuração para provedores, passada para os módulos de recursos downstream e para os recursos. Normalmente é limitado a trabalhar em uma entidade por separar lógico (por exemplo, região da AWS, projeto do Google).

Por exemplo, o módulo terraform-aws-atlantis utiliza módulo de recursos tais como o terraform-aws-vpc e terraform-aws-security-group para gerenciar infraestrutura necessária para executar o Atlantis no AWS Fargate.

Outro exemplo é o módulo terraform-aws-cloudquery, onde vários módulos do terraform-aws-modules estão sendo utilizados juntos para gerenciar a infraestrutura, assim como utilizar recursos do Docker para criar, enviar e implantar imagens Docker. Tudo em um conjunto.

Composição

Composição é uma coleção de módulos de infraestrutura, que podem abranger várias áreas separadas logicamente (por exemplo, regiões da AWS, várias contas da AWS). A composição é usada para descrever a infraestrutura completa necessária para toda a organização ou projeto.

Uma composição consiste em módulos de infraestrutura, que consistem em módulos de recursos, que implementam recursos individuais.

Fonte de Dados

A fonte de dados executa uma operação somente leitura e é dependente da configuração do provedor, é também usada em um módulo de recursos e em um módulo de infraestrutura.

A fonte de dados terraform_remote_state atua como uma “cola” para módulos e composições de nível superior.

Já uma fonte de dados externa, permite que um programa externo atue como fonte de dados, expondo informações arbitrários para uso em outro lugar na configuração do Terraform. Aqui está um exemplo do módulo terraform-aws-lambda, onde o nome do arquivo é calculado chamando um script Python externo.

A fonte de dados http realiza uma solicitação HTTP GET para o URL fornecido e exporta informações sobre a resposta, o que geralmente é útil para obter informações de terminais onde um provedor Terraform nativo não existe.

Estado Remoto

Módulos de infraestrutura e composições devem manter seu estado Terraform em um local remoto, onde possam ser recuperados por outros de maneira controlável (por exemplo, especificar ACL, versionamento, logging).

Provedor, Aprovisionador, etc

Provedores, provisionadores e alguns outros termos estão muito bem descritos na documentação oficial e não vale a pena repetir aqui. Na minha opinião, eles têm pouco a ver com escrever bons módulos Terraform.

Por que é tão difícil?

Enquanto os recursos individuais são como átomos na infraestrutura, os módulos de recursos são moléculas. Um módulo é a menor unidade com versão e compartilhável. Possui uma lista exata de argumentos, implementa lógica básica para que tal unidade realize a função necessária. Por exemplo, o módulo terraform-aws-security-group cria recursos aws_security_group e aws_security_group_rule com base no input. Este módulo de recursos por si só pode ser usado em conjunto com outros módulos para criar o módulo de infraestrutura.

O acesso aos dados entre moléculas (módulos de recursos e módulos de infraestrutura) é realizado utilizando saídas e fontes de dados dos módulos.

O acesso entre composições geralmente é realizado usando fontes de dados de estado remoto. Existem várias maneiras de compartilhar dados entre as configurações.

Ao colocar os conceitos descritos acima em pseudo-relações, pode-se ficar assim:

composition-1 {
  infrastructure-module-1 {
    data-source-1 => d1

    resource-module-1 {
      data-source-2 => d2
      resource-1 (d1, d2)
      resource-2 (d2)
    }

    resource-module-2 {
      data-source-3 => d3
      resource-3 (d1, d3)
      resource-4 (d3)
    }
  }

}

Este exemplo contém código como um exemplo de estruturação de configurações do Terraform para uma infraestrutura de pequeno porte, onde nenhuma dependência externa é utilizada.

O Terraform é poderoso (se não o mais poderoso que existe atualmente) e uma das ferramentas mais utilizadas que permitem o gerenciamento de infraestrutura como código (IaC). Ele permite que os desenvolvedores realizem uma grande variedade de coisas e não os restringe de fazê-las de forma com que sejam difíceis de integrar ou suportar à longo prazo.

Algumas informações descritas neste livro podem não parecer as melhores práticas. Sei disso, e, para ajudar os leitores a separar as melhores práticas estabelecidas e do que apenas mais uma maneira opinativa, às vezes, dou dicas para fornecer algum contexto e ícones para especificar o nível de maturidade em cada subseção relacionada às melhores práticas.

Alguns anos depois, ele foi atualizado com mais práticas atuais recomendadas disponíveis com o Terraform 1.0. Eventualmente, este livro deve conter a maioria das melhores práticas e recomendações incontestáveis para usuários do Terraform.

Patrocinadores

Traduções

Entre em contato se você quer ajudar a traduzir este livro para outros idiomas.

Contribuições

Continuarei atualizando este livro conforme a comunidade amadurece e novas ideias são implementadas e verificadas. Por favor, deixe seu comentário ou crítica construtiva para que o livro esteja sempre em boa qualidade.

Autores

Licença

Este trabalho está licenciado sob a Licença Apache 2. Veja LICENSE para maiores detalhes.

Os autores e colaboradores deste conteúdo não podem garantir a validade das informações aqui encontradas. Certifique-se de que entende que as informações aqui contidas estão sendo fornecidas livremente, e que, nenhum acordo ou contrato é criado entre você e quaisquer pessoas associadas a este conteúdo ou projeto. Os autores e colaboradores não assumem e, por meio deste, se isentam de qualquer responsabilidade perante qualquer parte, por qualquer perda, dano ou interrupção causada por erros, ou omissões nas informações contidas, associadas ou vinculadas a este conteúdo, sejam tais erros ou omissões resultantes de negligência, acidente ou qualquer outra causa.

Direito autoral © 2018-2023 Anton Babenko.

As perguntas relacionadas à estrutura de código do Terraform sào de longe as mais frequentes na comunidade. Todos pensaram na melhor estrutura de código para o projeto em algum momento também.

Como devo estruturar minhas configurações do Terraform?

Esta é uma das questões em que existem muitas soluções e é muito difícil dar conselhos dinâmicos, então vamos começar entendendo com o que estamos lidando.

• Qual é a complexidade do seu projeto?

  • Número de recursos relacionados.

  • Número de provedores Terraform (veja a nota abaixo sobre “provedores lógicos”).

• Com que frequência sua infraestrutura muda?

  • A partir de uma vez por mês/semana/dia.

  • Continuamente (toda vez que houver um novo commit).

• Iniciadores de mudança de código? Você permite que o servidor CI atualize o repositório quando um novo artefato é criado?

  • Somente desenvolvedores podem realizar o push para o repositório de infraestrutura.

  • Todos podem propor uma mudança em qualquer coisa abrindo um PR (incluindo tarefas automatizadas em execução no servidor CI).

• Qual plataforma de implementação ou serviço de implementação você utiliza?

  • AWS CodeDeploy, Kubernetes, ou OpenShift exigem uma abordagem um pouco diferente.

• Como os ambientes são agrupados?

  • Por ambiente, região, projeto...

Introdução à estruturação de configurações do Terraform

Colocar todo o código em um único main.tf é uma boa ideia quando você está começando ou escrevendo um código de exemplo. Em todos os outros casos, será melhor ter vários arquivos divididos logicamente assim:

• main.tf - chame módulos, locais e fontes de dados para criar todos os recursos.

• variables.tf - contém declarações de variáveis utilizadas em main.tf.

• outputs.tf - contém saídas dos recursos criados em main.tf.

• versions.tf - contém requisitos de versão para Terraform e provedores.

terraform.tfvars não deve ser utilizado em nenhum lugar exceto na composição.

Como pensar sobre a estrutura de configurações do Terraform?