Princípios de IaC

Infraestrutura como código é descrever servidores, redes, bancos e permissões em arquivos versionados, e deixar uma ferramenta reconciliar a realidade com essa descrição. O ganho não é digitar menos: é ter revisão, histórico e reprodutibilidade para mudanças que antes aconteciam num console, sem registro de quem fez o quê e por quê.

O teste honesto de maturidade: se a sua conta de nuvem fosse perdida amanhã, você conseguiria recriar o ambiente a partir do repositório? Se a resposta depende de alguém lembrar de uma configuração feita no clique, você ainda tem documentação, não IaC.

Declarativo e imperativo

Imperativo descreve os passos: crie a VM, instale o pacote, abra a porta. Roda duas vezes e você tem duas VMs, ou um erro.

Declarativo descreve o resultado: existe uma VM com este tamanho, esta rede e esta imagem. A ferramenta calcula a diferença entre o que existe e o que foi declarado, e faz só o que falta.

# Declarativo: o resultado desejado. Rodar de novo não muda nada.
resource "aws_s3_bucket" "relatorios" {
  bucket = "empresa-relatorios-prod"
}

Terraform, CloudFormation e manifests do Kubernetes são declarativos. Ansible fica no meio: descreve tarefas, mas com módulos que verificam o estado antes de agir. Script em Bash é imperativo — o que não o torna errado, apenas inadequado para manter estado ao longo do tempo.

Idempotência

Uma operação idempotente pode ser executada quantas vezes for necessário e o resultado final é o mesmo. É o que permite rodar o apply com segurança depois de uma falha de rede, no meio de um incidente, sem medo de duplicar recursos.

Idempotência não é automática. Um local-exec que roda curl -X POST a cada apply, ou uma task Ansible com shell: sem creates:, quebra a propriedade — e o dia em que o pipeline repetir, você descobre.

Drift: por que acontece

Drift é a diferença entre o que está no código e o que existe de verdade. Aparece por alteração manual no console durante um incidente, por outro sistema que gerencia o mesmo recurso, ou por mudança feita pelo próprio provedor.

terraform plan -detailed-exitcode   # sai com 2 quando há diferença — use no CI
terraform plan -refresh-only        # mostra o que mudou fora do código, sem propor mudança

O que fazer com o drift, em ordem de preferência: incorporar ao código a mudança que era legítima, ou reverter aplicando o código de novo. O que não funciona é ignorar: o próximo apply vai desfazer a correção de madrugada que ninguém registrou.

Rode a detecção continuamente — um job diário que abre alerta quando o plano não está vazio. Detectar drift no dia seguinte é barato; descobrir três meses depois, no meio de uma mudança grande, não é.

Infraestrutura imutável

Em vez de atualizar o servidor existente, você cria um novo com a configuração nova e descarta o antigo. É o modelo por trás de container, imagem de máquina e node group substituível.

O ganho é acabar com o servidor-estimação: aquele que ninguém reinicia porque foi ajustado à mão ao longo de anos e ninguém sabe reproduzir. Com infraestrutura imutável, a única forma de mudar é pelo código, e reverter é subir a versão anterior.

Nem tudo é imutável — banco de dados tem estado por definição. A regra prática: computação é descartável, dado é preservado, e a fronteira entre os dois precisa estar clara no seu desenho.

IaC não é backup

Confusão comum e cara. O código recria a estrutura: o bucket, o banco, a rede, as permissões. Ele não recria o conteúdo: os objetos, as tabelas, as linhas.

resource "aws_db_instance" "principal" {
  # ...
  deletion_protection = true
  skip_final_snapshot = false      # o padrão true já destruiu muito dado
  lifecycle { prevent_destroy = true }
}

terraform destroy executado no diretório errado apaga a estrutura com tudo dentro. Some proteção no código, permissão restrita para destruir em produção, e backup testado — que é assunto separado, com restauração exercitada.

Regras que economizam meses

• Versione tudo, inclusive lockfile de provider; revise mudança de infraestrutura por pull request, como código.
• Nunca edite no console o que é gerenciado por código. Se a emergência exigir, abra o PR de correção no mesmo dia.
• Não coloque segredo no código nem no state; o state guarda valores em claro.
• Ambientes iguais em estrutura, diferentes só em parâmetros — senão homologação para de significar alguma coisa.
• Aplique sempre pelo mesmo caminho (o pipeline), não da máquina de quem tem sorte.

Próximo passo: coloque esses princípios em prática com Terraform e OpenTofu.