Infraestrutura como código: Terraform e o fim do servidor artesanal

Existe um servidor em toda empresa que ninguém tem coragem de tocar. Alguém o configurou há três anos, clicando em painéis, rodando comandos soltos e ajustando coisas na mão até funcionar. Não há registro do que foi feito. Se ele cair, recriá-lo é uma arqueologia de tentativa e erro. Esse é o servidor artesanal, e ele é uma bomba-relógio: frágil, irreproduzível e conhecido por uma única pessoa que um dia vai sair de férias no pior momento.

A infraestrutura como código (IaC) existe para acabar com isso. Em vez de configurar servidores clicando e digitando, você descreve a infraestrutura em arquivos de texto versionados, e uma ferramenta os transforma em recursos reais. O Terraform é o padrão de mercado dessa prática. Este guia explica como IaC funciona, o papel do state, o fluxo de trabalho seguro e as boas práticas que separam infraestrutura confiável de scripts que ninguém entende.

O que muda com infraestrutura como código

Com IaC, servidores, redes, bancos, filas e permissões deixam de ser resultado de cliques manuais e passam a ser definidos em código. Esse código vira a fonte única de verdade sobre como o ambiente é. As consequências são profundas:

• Reprodutibilidade. Recriar o ambiente inteiro em outra região ou conta é rodar o mesmo código, não repetir um ritual de memória.
• Versionamento. A infraestrutura vive no Git, com histórico, revisão por pull request e a possibilidade de voltar a um estado anterior.
• Consistência entre ambientes. Desenvolvimento, homologação e produção nascem do mesmo código, eliminando o clássico "funcionava em staging".
• Documentação viva. O código é a documentação, sempre atual, porque é ele que cria a realidade.

O servidor artesanal morre porque não há mais nada de artesanal: tudo é declarado, revisado e recriável.

Declarativo, não imperativo

A diferença conceitual mais importante do Terraform é ser declarativo. Você não escreve os passos para criar a infraestrutura ("crie esta máquina, depois configure a rede, depois abra a porta"). Você declara o estado final desejado ("quero três máquinas, esta rede e estas regras"), e o Terraform descobre sozinho o que precisa fazer para a realidade bater com a declaração.

resource "aws_instance" "api" {
  count         = 3
  ami           = "ami-0abc123"
  instance_type = "t3.medium"
  tags = {
    Name = "api-server"
    Env  = "producao"
  }
}

Se esses três servidores não existem, o Terraform os cria. Se já existem e você muda count para cinco, ele cria só os dois que faltam. Se você reduz para dois, ele remove um. Você cuida do o quê; o Terraform cuida do como.

O coração do Terraform: o state

Para saber a diferença entre o que você declarou e o que existe de fato, o Terraform mantém um state, um arquivo que registra tudo que ele gerencia e o mapeia para os recursos reais na nuvem. O state é o que permite ao Terraform planejar mudanças com precisão: ele compara três coisas, o código (desejado), o state (o que ele acha que existe) e a realidade (o que existe de fato).

O state é poderoso e delicado ao mesmo tempo. Algumas regras não negociáveis:

• Nunca versione o state no Git em texto puro. Ele contém dados sensíveis, como senhas e chaves geradas.
• Guarde o state em backend remoto (por exemplo, um bucket de objetos com criptografia), não no notebook de alguém.
• Use travamento (locking) para impedir que duas pessoas apliquem mudanças ao mesmo tempo e corrompam o state.

Perder ou corromper o state é um dos piores cenários em IaC, porque o Terraform perde a noção do que gerencia. Trate o state com o mesmo cuidado que trataria um banco de produção.

O fluxo seguro: plan antes de apply

O que torna o Terraform confiável no dia a dia é a separação entre planejar e aplicar:

• terraform plan mostra exatamente o que vai mudar antes de qualquer coisa acontecer: o que será criado, alterado ou destruído. É a prévia, sem efeito colateral.
• terraform apply executa o plano, tornando a realidade igual ao código.

Esse "veja antes de fazer" é a rede de segurança da IaC. Você revisa o plano como revisaria um diff de código, e uma linha temida como destroy de um banco de produção salta aos olhos antes de virar tragédia. Em times maduros, o plan roda automaticamente em cada pull request, para que a mudança de infraestrutura seja revisada por gente antes de ir ao ar.

Comando	O que faz	Efeito
plan	Mostra as mudanças previstas	Nenhum (só leitura)
apply	Aplica as mudanças	Cria, altera ou destrói recursos
destroy	Remove tudo que é gerenciado	Destrutivo, use com cuidado

Módulos: parar de repetir

Conforme a infraestrutura cresce, copiar e colar blocos de configuração vira o mesmo problema de copiar e colar código: duplicação que ninguém consegue manter. Os módulos do Terraform resolvem isso encapsulando um conjunto de recursos reutilizável e parametrizável. Um módulo de "serviço web" pode empacotar a máquina, o balanceador, as regras de rede e os alertas, e ser instanciado várias vezes com parâmetros diferentes.

Módulos trazem para a infraestrutura os mesmos benefícios que funções trazem para o código: reúso, padronização e um único lugar para corrigir. Em vez de dez ambientes ligeiramente diferentes, você tem um módulo aplicado dez vezes, com as variações explícitas nos parâmetros.

Drift: quando a realidade foge do código

Mesmo com IaC, alguém um dia vai "só ajustar uma coisinha" direto no painel da nuvem, em uma emergência. Nesse instante, a realidade passa a divergir do código, o chamado drift (desvio). O perigo é que o próximo apply pode desfazer esse ajuste manual sem aviso, ou o ambiente vira de novo um lugar cujo estado real ninguém conhece.

A defesa é cultural e técnica ao mesmo tempo:

• Mudança de infraestrutura só pelo código. O painel da nuvem é para observar, não para alterar.
• Detecte drift regularmente rodando plan de forma agendada, para flagrar divergências cedo.
• Restrinja o acesso manual de escrita à nuvem, para que o caminho fácil seja também o caminho certo.

Boas práticas que sustentam a IaC

• Infraestrutura no mesmo fluxo do código: pull request, revisão e pipeline, exatamente como a aplicação.
• Ambientes por configuração, não por cópia: o mesmo código gera dev, staging e produção, mudando apenas variáveis.
• State remoto, criptografado e com locking, nunca local nem em texto no Git.
• Segredos fora do código: integre com um gerenciador de segredos, não deixe chaves nos arquivos.
• Comece pequeno e modularize conforme cresce: não tente descrever todo o data center no primeiro dia.

Infraestrutura como código não é sobre uma ferramenta específica, é sobre tratar a infraestrutura com o mesmo rigor de engenharia que se dá ao software: versionada, revisada, testada e reproduzível. O Terraform é o meio mais popular de chegar lá, mas o ganho real é o fim do medo, quando qualquer ambiente pode ser recriado com um comando, e ninguém mais depende do servidor que só uma pessoa entende.

---

Sua infraestrutura ainda é feita à mão e ninguém quer tocar nela? Na ConstructorTI, levamos sua infraestrutura para código versionado e reproduzível com Terraform, com state seguro, módulos e pipeline de revisão, para acabar de vez com o servidor artesanal. Se recriar um ambiente hoje seria um pesadelo, fale com a nossa engenharia e receba um diagnóstico da sua infraestrutura.