Blog/Artigos · Cloud e Plataforma
Terraform e Terragrunt, o modelo declarativo e idempotente, o arquivo de state, os módulos, o drift e a infraestrutura imutável.
O provérbio manda escrever a instrução na tábua do coração, para que ela não dependa da memória e se cumpra sempre igual. O oposto de escrever é confiar na lembrança, e memória de infraestrutura é a pior das fontes: ninguém lembra por que aquele security group tem aquela regra, ou o que muda se o servidor for recriado. Infraestrutura como código é escrever a infraestrutura na tábua, em texto versionado, para que o que está escrito se materialize igual toda vez, em qualquer conta, por qualquer pessoa. Deixa de ser artesanato que mora na cabeça de alguém e vira artefato que se lê, se revisa e se reproduz.
Criar infraestrutura clicando no console é rápido na primeira vez e uma armadilha em todas as seguintes. Ninguém consegue recriar o ambiente igual, ninguém sabe o que mudou desde ontem, e a revisão por outra pessoa é impossível porque não há o que revisar. É o que se chama ClickOps, e o custo aparece no pior momento: quando o ambiente cai e precisa ser reconstruído, ou quando a auditoria pergunta quem mudou aquela regra e quando. A resposta mora na memória de alguém, e memória não se versiona nem se audita.
Infraestrutura como código inverte isso. A infra vira texto declarativo, guardado no Git como qualquer outro código: com histórico, com pull request, com revisão, com a possibilidade de voltar atrás. O Terraform, da HashiCorp, virou o padrão de mercado por ser agnóstico de nuvem e ter uma linguagem própria, a HCL, legível o bastante para o pull request fazer sentido. O ganho não é só reprodutibilidade; é que a mudança de infraestrutura passa a ter o mesmo rito de qualquer mudança de código, e some o operador solitário mudando produção no escuro.
| Aspecto | ClickOps (console) | Infra como código |
|---|---|---|
| Reprodutível | não, cada ambiente vira único | sim, o mesmo código gera o mesmo ambiente |
| Revisável | não há o que revisar antes | pull request com plan antes de aplicar |
| Auditável | quem mudou o quê some no tempo | histórico Git responde quem, quando e por quê |
| Reversível | desfazer é arqueologia manual | voltar ao commit anterior e reaplicar |
| Escala | não escala além de poucos recursos | módulos reusáveis em dezenas de contas |
A ideia central do Terraform é declarativa: você descreve o estado final desejado, três instâncias, este banco, aquela rede, e a ferramenta descobre como chegar lá a partir de onde está. Você não escreve o passo a passo; escreve o destino. E é idempotente: aplicar o mesmo código dez vezes leva ao mesmo resultado que aplicar uma, porque a ferramenta só muda o que está diferente do desejado. Isso é o que torna a operação segura de repetir, e o que separa IaC de um script que quebra se rodar duas vezes.
O rito que dá segurança a isso é o par plan e apply. O plan mostra, antes de tocar em nada, exatamente o que vai ser criado, mudado e destruído. É o momento de revisão, e é onde se pega a linha assustadora: vai destruir o banco de produção. Nenhum apply em ambiente sério acontece sem um plan revisado antes, e é por isso que o plan entra no pull request como artefato: a pessoa aprova sabendo o efeito, não a intenção. Aprovar apply sem ler o plan é assinar em branco, e a nuvem cobra caro a assinatura em branco.
Repetir o apply é seguro: só muda o que saiu do desejado. É a idempotência que separa IaC de um script que quebra na segunda execução.
O Terraform mantém um arquivo de state, o mapa entre o código e o que existe de fato na nuvem. Ele é indispensável e é o ponto mais perigoso: se corromper, some a correspondência; se vazar, expõe segredo; se dois apply rodarem juntos sobre o mesmo state, ele racha. Por isso, em qualquer ambiente sério, o state fica remoto e com trava, tipicamente num bucket com lock, para que só um apply mexa por vez. Tratar o state com leveza é o erro que transforma uma mudança trivial num incidente de reconstrução.
As peças reusáveis são os módulos: um módulo de rede, um de banco, um de serviço, escritos uma vez e instanciados em dezenas de ambientes com parâmetros diferentes. É aí que o Terragrunt entra, uma camada fina sobre o Terraform que resolve a repetição, o famoso DRY, e organiza dezenas de contas e ambientes sem copiar e colar configuração. Módulo bem feito é o que faz a plataforma escalar: o time de fluxo consome o módulo de banco pronto, com as boas práticas embutidas, em vez de aprender a provisionar banco do zero. É a estrada aplainada, agora em código.
O inimigo silencioso do IaC é o drift: a diferença entre o que o código diz e o que a nuvem tem, criada por alguém que mexeu no console às pressas durante um incidente. O código ficou desatualizado sem ninguém saber, e o próximo apply ou reverte a correção de emergência ou quebra o que foi remendado. A defesa é detectar o drift continuamente, rodando o plan em modo de verificação e alertando quando a realidade divergiu do escrito, para que a divergência seja resolvida no código, não perpetuada no escuro.
A postura que fecha o assunto é a infraestrutura imutável, resumida na metáfora de tratar servidor como gado, não como bicho de estimação. Bicho de estimação tem nome, é remendado quando adoece e ninguém quer perder; gado é numerado e, quando adoece, é substituído por um novo idêntico. Infraestrutura imutável nunca conserta um servidor no lugar: recria a partir do código, garantindo que o que sobe é sempre o que está escrito. Isso mata o drift na raiz e transforma recuperação de desastre em reaplicar o código, não em ressuscitar um bicho de estimação que ninguém mais sabe como funciona.
IaC amadurece em degraus. No começo é um Terraform rodado da máquina de alguém, com o state num arquivo local que vive por um fio. No meio é state remoto, módulos e o plan no pull request. No topo é o pipeline aplicando com política de segurança embutida, drift detectado sozinho e infraestrutura imutável por padrão. O mercado também se mexeu: quando o Terraform mudou de licença, nasceu o OpenTofu, um fork aberto sob a Linux Foundation, e boa parte da comunidade migrou, um lembrete de que depender de uma ferramenta é também depender da licença dela.
O IaC não vive sozinho; ele é a base sobre a qual GitOps, Policy as Code e a plataforma inteira se apoiam. O código de infraestrutura é o que o GitOps reconcilia, é onde a política do Policy as Code é verificada, é o que o golden path da plataforma entrega pronto. Escrever a infraestrutura na tábua não é um fim; é a fundação escrita que torna possível tudo o que vem por cima. Sem o que está escrito, não há o que reconciliar, o que verificar nem o que pavimentar.
Infraestrutura como código escreve a infra na tábua para que o que está escrito se cumpra igual toda vez, em qualquer conta, por qualquer pessoa. O modelo declarativo e idempotente, com o rito de plan e apply, dá segurança à mudança; o state remoto com trava e os módulos com Terragrunt dão escala; a detecção de drift e a infraestrutura imutável, gado e não bicho de estimação, matam a divergência na raiz. A IA gera o módulo, traduz o plan e reconcilia o drift. Mas aprovar um apply que destrói um recurso com estado continua sendo decisão de quem leu o plan e responde pelo ambiente.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Cloud e Plataformaשׁוּב
GitOps faz do Git a única fonte de verdade do que roda, e um controlador puxa a realidade de volta ao que está escrito, sem parar. Deploy vira commit, rollback vira reverter, e o drift se corrige sozinho. O repositório declara, o laço reconcilia.
Cloud e Plataformaחֹק
Política em PDF ninguém lê e todo mundo contorna. Policy as Code escreve a regra em código que barra a violação antes de ela existir, no commit, no plan e na admissão do cluster. O decreto deixa de ser texto e vira gate automático.
