Gerador de Terraform resource

Terraform e OpenTofu a fundo: HCL, providers, state e o fluxo de IaC

Terraform é a ferramenta de Infrastructure as Code (IaC) da HashiCorp, lançada em 2014. Você descreve infraestrutura de nuvem de forma declarativa em HCL (HashiCorp Configuration Language) e o Terraform conversa com dezenas de APIs de provider (AWS, Google Cloud, Azure, Kubernetes, GitHub, Cloudflare, Datadog...) para criar, atualizar e destruir recursos até bater com o estado desejado. Em agosto de 2023 a HashiCorp moveu o código para a licença BUSL (Business Source License); a comunidade respondeu criando um fork open-source drop-in, o OpenTofu, hoje governado pela Linux Foundation. Os dois falam o mesmo HCL até a versão 1.5 do Terraform.

Os blocos principais do HCL são provider (plugin que chama a API da nuvem), resource (algo a criar), data (lookup read-only), variable (entrada), output (saída), locals (constantes nomeadas) e module (composição reutilizável). Um projeto típico tem um módulo raiz amarrando providers e locais, mais módulos filhos para padrões repetidos.

Sintaxe do resource

terraform {
  required_version = "~> 1.5"
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
  backend "s3" {
    bucket = "tf-state-acme"
    key    = "prod/network.tfstate"
    region = "us-east-1"
    dynamodb_table = "tf-locks"
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.amzn2.id
  instance_type = var.size
  tags = {
    Name        = "web-${var.env}"
    Environment = var.env
  }
}

As duas strings depois de resource são o type (definido pelo provider: aws_instance, google_compute_instance, kubernetes_deployment) e o name local usado para referenciar em outro lugar (aws_instance.web.public_ip).

State, backends e locking

O Terraform mantém um terraform.tfstate (JSON) que mapeia cada endereço HCL ao ID real que foi criado. Sem o state, ele recriaria tudo a cada execução. Em time, o state mora num backend remoto — S3 + DynamoDB (tabela de lock), Google Cloud Storage, Azure Blob ou Terraform Cloud — para que execuções concorrentes não se corrompam. Sempre habilite state locking; dois applies simultâneos no mesmo state produzem drift que precisa ser consertado na mão.

O fluxo init / plan / apply

• terraform init — baixa providers e configura o backend. Rode após clonar ou mudar versões obrigatórias.
• terraform plan — imprime o diff entre código e estado real. Leia com calma antes de aplicar.
• terraform apply — executa o plano (com confirmação ou -auto-approve em CI).
• terraform destroy — derruba tudo. Mesma semântica de diff, em sentido inverso.
• terraform fmt, terraform validate — formatação e lint básico.

Workspaces, módulos e CI

Use workspaces para manter state separado por ambiente no mesmo código (terraform workspace new staging). Em orgs maiores, prefira diretórios separados com backends separados por ambiente — fica explícito o raio de explosão e as credenciais. Modules permitem publicar um pedaço de infra (VPC, EKS, RDS) como unidade reutilizável, opcionalmente no Terraform Registry. Atlantis dirige fluxos baseados em PR: cada PR comenta um plan, o merge dispara o apply.

Boas práticas

• Fixe versão de provider com ~> 5.0 (permite patches, bloqueia majors).
• Tagueie todo recurso que suporta tags — auditorias de billing dependem disso.
• Mantenha prod e staging em backends separados; nunca compartilhe state entre ambientes.
• Rode tflint, tfsec, checkov no CI para checagens estáticas de segurança.
• Trate .tfvars como código: comite os que não são secret, use TF_VAR_ env vars ou Vault para segredos.
• Nunca edite state na mão a menos que use terraform state — edição manual do JSON vai te morder.
• Use blocos moved {} (Terraform 1.1+) ao refatorar, não state mv.

FAQ

Posso rollback de um terraform apply? Nativamente não. O "rollback" é git revert da mudança e aplicar de novo — o que só funciona se o estado anterior estiver limpo. Algumas operações (apagar um banco, recriar um IP) são irreversíveis. Sempre plan antes de apply.

Como detectar drift? Rode terraform plan numa árvore limpa: qualquer coisa que queira mudar é drift. Agende isso em CI noturno e alerte em diferença. O Terraform Cloud tem drift detection embutido.

Vale migrar para OpenTofu? Se você está em Terraform 1.5 ou anterior, OpenTofu é substituto drop-in (mesmo binário, mesmo HCL). Depois da 1.5 os projetos divergem — o OpenTofu adicionou state encryption e provider mocking antes do Terraform.

Terraform vs Pulumi vs CDK? Terraform/OpenTofu usam HCL (DSL declarativa) — maior ecossistema de providers. Pulumi usa linguagens reais (TS, Python, Go) — melhor para devs confortáveis com código. O AWS CDK é só AWS (existe CDK for Terraform, mas é nicho). Escolha pelo skill do time e pelo ecossistema do qual mais depende.

Como estruturar um repo grande? O padrão "live" (popularizado pelo Terragrunt da Gruntwork): um diretório fino por ambiente que chama módulos compartilhados com inputs diferentes. Evita copy-paste mantendo state separado. Sem Terragrunt dá para replicar à mão com workspaces ou backends explícitos.