IaC: infraestrutura como código para ambientes reproduzíveis

O que é IaC e por que é essencial

Infraestrutura tratada com a mesma disciplina que código

Infrastructure as Code (IaC) é a prática de provisionar e gerenciar infraestrutura cloud usando arquivos de configuração versionados no Git em vez de interfaces manuais ou scripts ad-hoc. O mesmo rigor aplicado ao código da aplicação — revisão por pares, testes, branching, rollback — é aplicado à infraestrutura. Isso resolve o problema fundamental de ambientes que divergem silenciosamente ao longo do tempo: configurações manuais não são auditadas, não são reproduzíveis e criam o fenômeno do snowflake server — servidores únicos impossíveis de recriar com exatidão. Com IaC, recriar um ambiente de produção é questão de executar um comando.

Declarativo vs imperativo — como cada abordagem funciona

Descrever o que se quer vs descrever como fazer

Abordagens declarativas (Terraform, CloudFormation, Pulumi) descrevem o estado desejado da infraestrutura e deixam a ferramenta calcular como chegar lá. Você declara "quero uma instância EC2 t3.medium com esse security group" e o Terraform descobre se precisa criar, atualizar ou ignorar. Abordagens imperativas (Ansible para provisionamento, scripts Shell) descrevem os passos para chegar ao estado desejado. Declarativo é mais previsível para infra estável — a ferramenta gerencia a reconciliação. Imperativo é mais flexível para tarefas procedurais como configuração de software dentro de servidores. A maioria dos stacks modernos combina os dois: Terraform para provisionar infra, Ansible ou cloud-init para configurar o sistema operacional.

Idempotência em IaC — aplicar N vezes produz o mesmo resultado

A propriedade que torna IaC confiável

Idempotência significa que aplicar o mesmo código de infraestrutura múltiplas vezes não produz efeitos colaterais além da primeira aplicação. Se a infraestrutura já está no estado desejado, uma nova aplicação não faz nada. Isso é fundamental para integração com CI/CD: pipelines podem rodar terraform apply em cada merge para a branch principal sem medo de criar recursos duplicados ou gerar custos extras. Ferramentas declarativas como Terraform e Pulumi são idempotentes por design — elas comparam o estado atual com o desejado e aplicam apenas o delta. Scripts imperativos precisam ser escritos com cuidado para garantir idempotência, verificando antes de executar cada operação.

State file — rastreando o estado da infraestrutura

O registro do que foi criado e como foi configurado

O Terraform e outras ferramentas declarativas mantêm um state file que mapeia cada recurso declarado no código ao recurso real na cloud. Esse arquivo é a fonte de verdade da ferramenta: sem ele, é impossível saber o que foi criado anteriormente e o que precisa ser modificado ou destruído. O state file contém IDs de recursos, atributos configurados e metadados de dependências. Ele deve ser armazenado remotamente (S3, Azure Blob, Terraform Cloud) com locking para evitar aplicações concorrentes que corrompam o estado. Nunca commitar o state file no Git — ele pode conter valores sensíveis como senhas de banco e tokens de API.

Drift detection — quando a infra diverge do código

Detectando mudanças manuais não registradas

Drift ocorre quando a infraestrutura real diverge do que está declarado no código — alguém modificou uma security group rule manualmente no console AWS, um processo automático alterou configurações, ou um recurso foi deletado acidentalmente. Ferramentas de IaC detectam drift comparando o state file com o estado real da cloud (terraform plan mostra as diferenças). Sistemas maduros executam terraform plan periodicamente em CI e alertam o time quando drift é detectado, antes que a divergência cause incidentes. Drift é um sinal de que alguém está "vazando" fora do processo IaC — identificar e corrigir o comportamento é tão importante quanto corrigir o drift em si.

Módulos e reutilização de código de infraestrutura

DRY aplicado à infraestrutura

Módulos permitem encapsular configurações de infraestrutura reutilizáveis — um módulo de VPC, um módulo de cluster RDS, um módulo de ECS service — e instanciá-los com parâmetros diferentes para cada ambiente ou time. Isso elimina a duplicação de centenas de linhas de Terraform entre dev, staging e produção. O Terraform Registry tem módulos oficiais e da comunidade para praticamente todo serviço AWS, GCP e Azure. Módulos internos são versionados como packages (semver), permitindo que diferentes projetos usem versões diferentes e atualizem em seu próprio ritmo. A fronteira entre módulo e código inline é uma questão de complexidade: extraia para módulo quando a mesma configuração aparece em mais de dois lugares.

Segredos em IaC — Vault, AWS Secrets Manager

Nunca hardcodar credenciais no código de infraestrutura

IaC lida inevitavelmente com valores sensíveis — senhas de banco, tokens de API, certificados. A regra absoluta é que esses valores nunca aparecem em texto plano no código ou no state file. Abordagens recomendadas incluem: referenciar secrets de AWS Secrets Manager ou HashiCorp Vault diretamente no código Terraform via data sources, para que o valor seja lido dinamicamente na hora da aplicação; usar variáveis de ambiente para passar valores sensíveis ao Terraform sem gravá-los no disco; e configurar encryption do state file no backend remoto. O state file em S3 deve ter SSE (Server-Side Encryption) habilitado e acesso restrito via bucket policy, pois pode conter valores de outputs de recursos provisionados.

IaC em CI/CD — plan e apply automatizados

Infraestrutura com o mesmo rigor de deploy de aplicação

Integrar IaC em CI/CD segue o padrão: em pull requests, o pipeline executa terraform plan e posta o output como comentário no PR para revisão humana. Após aprovação e merge, o pipeline executa terraform apply automaticamente. Essa abordagem — popularizada pelo Atlantis e pelo GitHub Actions com terraform — garante que toda mudança de infraestrutura seja revisada antes de aplicada, com registro de quem aprovou e qual era o plan esperado. Ambientes de produção devem ter apply protegido por environment gates de aprovação manual, assim como deploys de aplicação. O plan deve ser exibido de forma legível, destacando recursos a criar, modificar e destruir.

Testar infraestrutura como código

Validando que a infra funciona antes de produção

Testar IaC vai além de validar sintaxe com terraform validate. Ferramentas como Terratest (Go) permitem criar infraestrutura real em um ambiente de teste, executar assertions (a instância está acessível? o bucket permite upload? o banco aceita conexoes?) e destruir tudo ao final. Checkov e tfsec fazem análise estática de segurança no código Terraform, identificando configurações perigosas como buckets S3 públicos, security groups com 0.0.0.0/0 e recursos sem encryption. OPA (Open Policy Agent) com Conftest valida políticas customizadas — por exemplo, garantir que toda instância EC2 tem tags de custo e ambiente. Esses testes devem rodar em CI antes de qualquer apply em produção.

Conclusão

IaC como fundação para infraestrutura confiável e auditável

Continue em: Fundamentos obrigatórios antes de produção.