Infraestrutura como Código com Terraform

Infraestrutura como Código com Terraform

Robson Rabelo - 10 de julho de 2026 - 3 visualizações

Servidor que ninguém sabe como foi configurado é acidente agendado. Veja por que escrever infraestrutura como código, como funciona o fluxo do Terraform e os erros de quem está começando.

Toda empresa tem (ou teve) um servidor que ninguém sabe como foi configurado. Ele funciona, mas ninguém tem coragem de mexer. Quem o criou saiu da empresa. A documentação é uma página desatualizada e a memória de dois desenvolvedores.

Esse servidor tem nome na literatura: snowflake, o floco de neve único e irreproduzível. E ele é o sintoma clássico da infraestrutura feita no clique, o famoso ClickOps: console aberto, próximo, próximo, concluir, e nenhum registro de por que cada opção foi marcada.

Infraestrutura como Código (IaC) é o antídoto: descrever servidores, redes, bancos e permissões em arquivos de texto versionados, e deixar uma ferramenta transformar essa descrição em recursos reais na nuvem. O Terraform, da HashiCorp, é a ferramenta mais adotada dessa categoria, com a vantagem de falar com qualquer uma das grandes nuvens e centenas de outros provedores (developer.hashicorp.com/terraform).

Como funciona, em 30 segundos

Você declara o estado desejado, não os passos:

resource "aws_s3_bucket" "relatorios" {
  bucket = "relatorios-empresa"
  tags = {
    ambiente = "producao"
    time     = "financeiro"
  }
}

O fluxo tem três comandos que viram rotina:

  1. terraform plan: a ferramenta compara o código com o que existe na nuvem e mostra o que vai criar, alterar ou destruir. É o diff da sua infraestrutura.
  2. terraform apply: executa o plano, na ordem certa, resolvendo dependências.
  3. O estado: um arquivo que registra o que o Terraform gerencia, permitindo detectar drift (alguém mexeu no console por fora).

Fluxo do Terraform: código, plan, apply, nuvem

Por que escrever infra como quem escreve software

Porque os benefícios são exatamente os mesmos que o código trouxe para o resto da engenharia:

  • Revisão antes do estrago: mudança de infra vira pull request. Um colega revisa o plan antes de qualquer coisa tocar produção. Quantos incidentes seu time já teve por um clique errado no console?
  • Reprodutibilidade: precisa de um ambiente de staging idêntico à produção? terraform apply com outras variáveis. Precisa reconstruir tudo após um desastre? O código é o manual, sempre atualizado.
  • Auditoria e histórico grátis: o git log responde "quem abriu essa porta do firewall, quando e por quê?". Para LGPD e auditorias de segurança, isso vale ouro.
  • Documentação que não mente: o código descreve o ambiente real, porque é dele que o ambiente nasce. O floco de neve derrete.

Kief Morris, autor de Infrastructure as Code (O'Reilly), resume o princípio: trate servidores como gado, não como animais de estimação. Se um recurso está estranho, você o destrói e recria a partir do código, em minutos (infrastructure-as-code.com).

E há correlação com performance: as pesquisas DORA (base do livro Accelerate, de Forsgren, Humble e Kim) mostram consistentemente que automação de infraestrutura e deploy caminha junto com maior frequência de entrega e menor tempo de recuperação de falhas (dora.dev).

Os erros de quem está começando

  • State no laptop: o arquivo de estado precisa viver num backend remoto com lock (S3 + DynamoDB, por exemplo). No laptop de alguém, é acidente agendado.
  • Segredos no código: senha em arquivo versionado é vazamento com data marcada. Use um gerenciador de segredos e variáveis de ambiente.
  • Tudo num módulo gigante: um main.tf de 3 mil linhas é o monolito ruim da infraestrutura. Separe por domínio e ambiente, componha com módulos.
  • Metade console, metade código: o pior dos mundos. O que o Terraform não gerencia, ele não protege. Migre por partes, mas com fronteiras claras do que já é código.

Detalhe de contexto: desde a mudança de licença do Terraform em 2023, existe também o OpenTofu, fork open source mantido pela Linux Foundation, compatível e em crescimento. Para a maioria dos times, a decisão entre um e outro é secundária; o que importa é sair do clique.

Da primeira linha ao ambiente inteiro

Adotar IaC num ambiente que já existe não exige big bang: começa-se importando os recursos críticos, congela-se o ClickOps neles, e expande-se módulo a módulo. É um caminho que percorremos com frequência no nosso serviço de Cloud e Infraestrutura, do primeiro terraform init à esteira completa com revisão e ambientes reproduzíveis.

Quer saber por onde começar no seu ambiente? Descreva sua infraestrutura atual para a IA da Rabelo Digital, aqui no canto da tela, e ela sugere o primeiro módulo a codificar. Sem formulário, sem espera.


Leia também

Compartilhar:

Deixe um Comentário

Categorias

Posts Recentes