Terraform: provisionando infraestrutura de forma declarativa

O que é Terraform e como funciona

A ferramenta de IaC mais adotada do mercado

Terraform é uma ferramenta open-source da HashiCorp que permite provisionar infraestrutura em qualquer cloud provider usando código declarativo. Ele funciona em três fases: terraform init baixa os providers e módulos necessários; terraform plan compara o estado atual com o desejado e gera um plano de execução; terraform apply executa o plano criando, modificando ou destruindo recursos. Cada recurso criado é rastreado no state file, que é a memória do Terraform. Desde 2023, o Terraform passou a usar a licença BUSL (Business Source License), motivando o surgimento do fork OpenTofu — ambos mantêm a mesma sintaxe e são amplamente intercambiáveis para uso open-source.

HCL — a linguagem de configuração do Terraform

HashiCorp Configuration Language para infraestrutura legível

HCL (HashiCorp Configuration Language) é a linguagem declarativa do Terraform — projetada para ser legível por humanos e parseável por máquinas. Blocos resource definem os recursos a criar; data blocks leem recursos existentes sem criá-los; variable blocks declaram inputs parametrizáveis; output blocks expõem valores para outros módulos ou para o usuário. Expressões HCL suportam interpolação de strings, condicionais (condition ? true_val : false_val), loops com for_each e count, e funções builtin para manipulação de listas, maps e strings. A linguagem é tipada e o Terraform valida tipos antes de aplicar o plano, detectando erros de configuração sem precisar provisionar recursos.

Providers — AWS, GCP, Azure e além

O ecossistema que conecta Terraform a qualquer serviço

Providers são plugins que ensinam o Terraform a interagir com APIs externas. O Terraform Registry tem mais de 3.000 providers oficiais e da comunidade — AWS, GCP, Azure, Kubernetes, GitHub, Datadog, Cloudflare, MongoDB Atlas e muitos outros. Cada provider expõe um conjunto de resources e data sources. O provider AWS tem mais de 1.000 resources cobrindo praticamente todo serviço da AWS. Providers são versionados e devem ser fixados em versão mínima no bloco required_providers para garantir reprodutibilidade — um provider sem versão fixada pode atualizar e quebrar o código silenciosamente. Providers customizados podem ser criados em Go usando o Plugin SDK da HashiCorp.

State file — o registro do que foi criado

Gerenciando o coração do Terraform com segurança

O state file é um arquivo JSON que o Terraform usa para rastrear a correspondência entre recursos declarados no código e recursos reais na cloud. Sem state, o Terraform não saberia que a instância EC2 i-0abc123 é o recurso aws_instance.web declarado no código. State remoto é obrigatório em times: armazenar em S3 com DynamoDB para locking (AWS), em Azure Blob com storage locking, ou no Terraform Cloud. State locking previne que dois applies concorrentes corrompam o estado — qualquer apply adquire um lock antes de iniciar. Operações de manipulação manual (terraform state mv, terraform state rm) devem ser usadas com extremo cuidado e documentadas, pois modificam o state diretamente.

terraform plan e apply — ciclo de vida

O fluxo de trabalho central do Terraform

O ciclo de trabalho do Terraform segue uma sequência bem definida. terraform init prepara o diretório de trabalho baixando providers e módulos — necessário apenas na primeira vez ou quando as dependências mudam. terraform plan executa uma dry run que mostra exatamente quais recursos serão criados (+), modificados (~) ou destruídos (-) sem aplicar nada. terraform apply executa o plan e aguarda confirmação (ou -auto-approve para CI). terraform destroy destrói todos os recursos gerenciados — operação de alto risco que deve ser executada apenas em ambientes efêmeros ou com revisão cuidadosa. O output do plan deve ser salvo como artefato e revisado antes de qualquer apply em produção.

Módulos — reutilizando código de infraestrutura

Abstraindo e compartilhando padrões de infraestrutura

Módulos são diretórios de arquivos HCL que encapsulam um padrão de infraestrutura reutilizável. Um módulo de VPC configura subnets públicas e privadas, route tables e NAT gateways seguindo as melhores práticas da organização. Um módulo de aplicação ECS configura task definition, service, IAM roles e target groups com os padrões de segurança aprovados. Módulos recebem variáveis como input e expõem outputs. O Terraform Registry hospeda módulos oficiais mantidos pelos próprios providers (aws, google, azurerm) — altamente testados e confiáveis. Internamente, mantenha módulos em repositórios separados ou em um monorepo de infraestrutura, versionados com tags semânticas.

Workspaces — ambientes separados com o mesmo código

Isolando state entre dev, staging e produção

Workspaces permitem que o mesmo código Terraform gerencie múltiplos ambientes com states separados. terraform workspace new staging cria um workspace com state isolado; terraform workspace select staging muda para esse workspace; qualquer plan e apply afeta apenas os recursos desse workspace. Dentro do HCL, terraform.workspace retorna o nome do workspace atual, permitindo configurações condicionais por ambiente. No entanto, workspaces têm limitações: todos compartilham o mesmo backend e a mesma configuração de provider, o que pode ser um problema de segurança quando dev e produção precisam de contas AWS separadas. Para esse nível de isolamento, múltiplos diretórios com backends separados é a abordagem mais robusta.

Remote state — armazenando state de forma segura

Compartilhando outputs entre módulos e times

Remote state resolve dois problemas: armazenar o state file de forma segura e compartilhável, e permitir que módulos diferentes referenciem outputs uns dos outros. O data source terraform_remote_state lê outputs de outro state — por exemplo, o módulo de aplicação referencia o VPC ID criado pelo módulo de rede sem duplicar a configuração. Backends suportados incluem S3, GCS, Azure Blob, Terraform Cloud e outros. O backend S3 com DynamoDB para locking e SSE-S3 para encryption é a configuração mais comum em ambientes AWS. Terraform Cloud adiciona funcionalidades como histórico de plans, políticas de sentinel e controle de acesso baseado em times sobre o state.

Terraform Cloud e automação

Colaboração e governança em escala

Terraform Cloud (e o Terraform Enterprise para instalação on-premise) adiciona uma camada de colaboração e governança sobre o Terraform open-source. Workspaces no Terraform Cloud são conectados a repositórios Git e executam plan automaticamente em cada PR, postando o resultado como comentário. Apply em produção requer aprovação de um ou mais membros autorizados. Policies com Sentinel ou OPA definem regras que os plans devem satisfazer antes de serem aprovados — por exemplo, proibir instâncias com mais de 16 vCPUs ou buckets S3 sem encryption. O registry privado hospeda módulos e providers internos versionados. Para times grandes com múltiplos squads, Terraform Cloud elimina a necessidade de cada time gerenciar sua própria infraestrutura de state e CI.

Conclusão

Terraform como padrão de provisioning cloud declarativo

Continue em: Fundamentos obrigatórios antes de produção.