Terraform: O que é, Como Funciona e Tutorial para Equipes de TI

Provisionar infraestrutura manualmente em ambientes cloud é uma das principais fontes de configuration drift em operações de TI. Um engenheiro cria uma instância de desenvolvimento com certas configurações. Outro replica em produção com parâmetros diferentes. O resultado é um ambiente inconsistente que ninguém consegue reproduzir com segurança.

O Terraform surgiu para resolver exatamente esse problema. Criado pela HashiCorp em 2014 e adotado por mais de 500.000 organizações, ele permite que toda a infraestrutura seja descrita em arquivos de configuração versionáveis e reproduzíveis. O mesmo repositório que cria o ambiente de desenvolvimento cria a produção — com diferenças apenas nos parâmetros.

Este tutorial cobre o que é o Terraform como ferramenta de IaC, como sua arquitetura funciona na prática, o ciclo de vida completo de um provisionamento e as boas práticas para equipes que operam ambientes produtivos.

O que é Terraform

Terraform é uma ferramenta de Infraestrutura como Código (IaC) de código aberto desenvolvida pela HashiCorp. Ela usa uma linguagem declarativa chamada HCL (HashiCorp Configuration Language) para descrever o estado desejado da infraestrutura. O Terraform calcula automaticamente como chegar a esse estado e executa as mudanças na ordem correta.

A principal diferença do Terraform em relação a scripts imperativos é a idempotência: executar o mesmo arquivo de configuração múltiplas vezes sempre produz o mesmo resultado. Não importa quantas vezes o comando seja rodado — se a infraestrutura já está no estado descrito, nada muda.

Como o Terraform se encaixa no ecossistema IaC

No ecossistema de DevOps, o Terraform ocupa a camada de provisionamento: criar e gerenciar a existência de recursos (VMs, redes, bancos de dados, buckets). Ele não configura o software dentro desses recursos — essa responsabilidade é do Ansible ou de outras ferramentas de configuração.

A combinação mais comum em ambientes cloud-native maduros é Terraform para provisionar e Ansible para configurar. Cada ferramenta opera em sua camada de especialização sem sobreposição desnecessária. O Terraform suporta mais de 1.000 providers, cobrindo AWS, Azure, GCP, Kubernetes, GitHub e Datadog, entre outros.

Como Funciona o Terraform na Prática

A arquitetura do Terraform é baseada em três componentes principais: o Core (o binário CLI), os Providers (plugins de integração com APIs) e o State (arquivo de estado da infraestrutura). A interação entre esses três componentes define o ciclo completo de vida de qualquer recurso provisionado.

Providers e Resources — os blocos de construção do HCL

Um Provider é um plugin que ensina o Terraform a interagir com uma API específica. O provider AWS, por exemplo, sabe como criar instâncias EC2, buckets S3 e grupos de segurança via chamadas à API da Amazon. Cada provider expõe um conjunto de Resources e Data Sources.

Um Resource é qualquer objeto de infraestrutura que o Terraform gerencia. Um arquivo main.tf básico para criar uma instância EC2 na AWS segue esta estrutura:

provider "aws" {
region = "us-east-1"
}

resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t3.micro"
}

O bloco provider configura a conexão com a AWS. O bloco resource declara o estado desejado: uma instância EC2 com aquele AMI e tipo. O Terraform descobre como criar, atualizar ou destruir esse recurso via chamadas à API do provider.

O Ciclo de Vida: init, plan, apply e destroy

Todo fluxo de trabalho com Terraform segue quatro comandos fundamentais. Compreender o que cada um faz é essencial para operar infraestrutura com segurança.

terraform init inicializa o diretório de trabalho: baixa os plugins dos providers configurados e inicializa o backend de estado. Deve ser executado sempre que um novo provider é adicionado ou o backend é alterado.

terraform plan é o coração da segurança operacional do Terraform. Ele compara o estado atual da infraestrutura (registrado no state file) com o estado declarado nos arquivos .tf e mostra exatamente o que será criado, modificado ou destruído. Nenhuma mudança é aplicada. O output exibe linhas com + (criar), ~ (modificar) e - (destruir). Revisar o plano antes de aplicar é obrigatório em ambientes produtivos.

terraform apply executa o plano: faz chamadas às APIs dos providers para materializar a infraestrutura descrita. Por padrão, solicita confirmação antes de prosseguir. Em pipelines automatizados, o flag -auto-approve suprime a confirmação interativa.

terraform destroy remove todos os recursos gerenciados pelo Terraform no diretório atual. Em ambientes produtivos, o destroy deve ser protegido por controles de acesso rigorosos. Recursos críticos podem ser protegidos com o argumento prevent_destroy = true no bloco lifecycle.

State File — o Coração do Terraform

O State File (terraform.tfstate) é o arquivo JSON que mapeia os recursos declarados nos arquivos HCL para os recursos reais existentes na infraestrutura. É através dele que o Terraform sabe o que já foi provisionado e quais mudanças são necessárias a cada plan.

Por padrão, o state é armazenado localmente. Isso funciona para projetos individuais, mas é incompatível com trabalho em equipe: dois engenheiros aplicando mudanças simultaneamente corrompem o state. A solução é o remote backend com state locking.

O backend remoto mais comum em ambientes AWS é S3 + DynamoDB. O bucket S3 armazena o state de forma versionada. A tabela DynamoDB implementa o locking: quando um apply está em execução, nenhum outro pode ser iniciado até que o lock seja liberado. Isso evita corridas entre membros da equipe.

Para ambientes multicloud ou que preferem uma solução gerenciada, o HCP Terraform (antigo Terraform Cloud) oferece state remoto com locking nativo, histórico de planos e controle de acesso por workspace.

Módulos — Reutilizando Configurações em Times

Um módulo no Terraform é um conjunto de arquivos .tf agrupados em um diretório que encapsula uma configuração reutilizável. Em vez de cada squad reescrever a configuração de rede, segurança e compute do zero, um módulo corporativo padroniza esses padrões e é chamado com parâmetros específicos.

Um módulo é chamado com o bloco module:

module "vpc" {
source = "./modules/vpc"
environment = "production"
cidr_block = "10.0.0.0/16"
}

Módulos podem ser armazenados localmente, em repositórios Git privados ou no Terraform Registry, que centraliza módulos públicos verificados pela comunidade. Módulos bem escritos recebem variáveis de entrada (variables.tf), expõem outputs (outputs.tf) e são versionados independentemente do módulo raiz.

Em ambientes de SRE com dezenas de squads, módulos são o mecanismo que garante que todos os novos ambientes sigam os padrões de segurança e rede aprovados pela equipe de plataforma — sem que cada time precise reinventar a infraestrutura.

Boas Práticas para Ambientes Produtivos

Adotar o Terraform em produção exige mais do que aprender a sintaxe HCL. As práticas abaixo separam times que usam o Terraform como ferramenta de times que o usam como fundação operacional.

Separe ambientes por diretórios ou workspaces. Nunca compartilhe o mesmo state entre desenvolvimento e produção. A separação evita que um apply errado em dev impacte produção.

Armazene o state remotamente com locking. Usar state local em equipe é um risco operacional. Um state corrompido pode exigir horas de reconciliação manual com os recursos reais.

Versione os providers. Sem versão fixada no bloco required_providers, um terraform init pode baixar uma versão com breaking changes. Use constraints como >= 5.0, < 6.0 para controle.

Execute o Terraform via pipeline de CI/CD, não localmente. O pipeline centraliza o apply, garante que o plan seja revisado antes da execução e mantém auditabilidade de quem aplicou o quê e quando. Ferramentas como GitHub Actions, GitLab CI e pipelines de integração contínua são integrações naturais.

Use terraform fmt e terraform validate no pipeline. O fmt padroniza a formatação. O validate verifica erros de sintaxe e referências inválidas antes do plan. Ambos devem ser gates obrigatórios no CI antes de qualquer merge.

Monitore o configuration drift. O monitoramento cloud identifica quando a infraestrutura real diverge do state do Terraform — seja por mudanças manuais no console ou por falhas de apply. O comando terraform plan periódico em pipelines de drift detection detecta essas divergências antes que causem incidentes.

Conclusão

O Terraform transforma infraestrutura de uma atividade manual e propensa a erros em um processo versionável, revisável e automatizável. O ciclo init → plan → apply garante visibilidade sobre cada mudança antes da execução. O state remoto com locking viabiliza o trabalho colaborativo. Os módulos propagam padrões corporativos sem duplicação de código.

Para equipes de TI que operam ambientes cloud em escala, o Terraform não é apenas uma ferramenta de conveniência — é a base sobre a qual pipelines de DevOps confiáveis são construídos. Combinar o provisionamento declarativo com observabilidade ativa e monitoramento contínuo do drift reduz o MTTR e aumenta a confiabilidade dos ambientes.

Se sua equipe está estruturando ou amadurecendo sua estratégia de Infraestrutura como Código, fale com nossos especialistas.