Quando comecei a usar o Terraform, presumi que a parte difícil seria aprender a sintaxe HCL e entender os provedores. Descobriu-se que o verdadeiro desafio era algo totalmente diferente: gerenciar a mesma infraestrutura em desenvolvimento, preparação e produção sem criar desvios ou interromper acidentalmente a produção.

Depois de gerenciar a infraestrutura de sistemas que atendem a milhões de usuários em diversas locações do Oracle Cloud, aprendi que a estrutura do ambiente é mais importante do que os módulos inteligentes do Terraform. As maiores falhas que vi não foram causadas por códigos incorretos, mas por limites pouco claros entre ambientes.

Por que a infraestrutura de copiar e colar falha

No início, cometi um erro comum. Coloquei o Terraform trabalhando em dev, copiei todo o diretório para teste, ajustei algumas variáveis ​​e copiei novamente para prod. Parecia pragmático e rápido.

Funcionou até a primeira mudança real. Uma regra de firewall precisava ser atualizada. Consertei o dev, depois o staging e esqueci o prod. Duas semanas depois, o prod tinha regras de segurança diferentes e ninguém sabia explicar por quê.

O dano real apareceu durante um incidente. Um recurso funcionou na preparação, mas falhou na produção. Passamos horas depurando o código do aplicativo antes de perceber que os ambientes não eram mais equivalentes. A deriva da infraestrutura havia surgido silenciosamente.

A infraestrutura de copiar e colar sempre parece inofensiva no início. Torna-se uma dívida técnica no momento em que seus sistemas começam a mudar.

Arquivos de estado separados são obrigatórios

Uma lição que aprendi rapidamente é que cada ambiente precisa de seu próprio arquivo de estado. Compartilhar o estado entre ambientes é um acidente esperando para acontecer.

Já vi equipes usarem espaços de trabalho do Terraform com um único back-end para economizar tempo ou armazenamento. Funciona até que alguém execute terraform apply pensando que está em desenvolvimento, quando na verdade está visando a produção. Esse erro é irreversível.

Com arquivos de estado separados, cada ambiente é isolado. Um erro no dev permanece no dev. O raio de explosão é limitado pelo projeto.

Cada ambiente tem seu próprio back-end remoto e controles de acesso. O estado de produção requer permissões elevadas. Esses pontos de atrito são intencionais e valiosos.

Módulos específicos do ambiente superam a lógica condicional

A maior mudança mental para mim foi aceitar que os ambientes deveriam ser consistentes, mas não idênticos.

A produção precisa de alta disponibilidade, backups e capacidade. O desenvolvimento não. Tentar forçar um único módulo a lidar com tudo isso com condicionais rapidamente transforma os módulos em uma bagunça ilegível.

O que funcionou foi separar as preocupações:

• Os módulos base definem recursos e lógica compartilhada.
• Os wrappers de ambiente definem escala, durabilidade e tolerância a riscos.

Quando o comportamento principal muda, atualizo o módulo base uma vez. Quando as necessidades do ambiente são diferentes, eu mudo o wrapper. Isso mantém os módulos legíveis e os ambientes explícitos.

Arquivos variáveis ​​tornam as implantações explícitas

Para diferenças de configuração que não justificam módulos separados, os arquivos variáveis ​​por ambiente funcionam bem.

Cada ambiente tem seu próprio arquivo .tfvars e as implantações sempre o especificam explicitamente. Isso elimina a ambiguidade. Você não pode aplicar acidentalmente configurações de desenvolvimento ao produto sem ser muito deliberado.

Essa explicitação é mais importante do que a conveniência quando sistemas reais estão em jogo.

O gerenciamento de segredos não é opcional

O mais próximo que chegamos de um sério incidente de segurança foi descobrir credenciais de produção comprometidas em um arquivo variável do Terraform. Isso desencadeou a rotação imediata de credenciais em todos os ambientes.

Depois disso, aplicamos uma regra estrita: os segredos nunca ficam nos arquivos do Terraform.

No Oracle Cloud, contamos com IAM para controle de acesso, OCI Vault para segredos e fontes de dados Terraform para buscar segredos em tempo de execução. O Terraform faz referência a segredos, mas nunca os possui. O controle de origem permanece limpo e a rotação se torna gerenciável.

Por que evitamos espaços de trabalho Terraform

Os espaços de trabalho Terraform parecem atraentes no papel. Mesmo código, vários ambientes, troca fácil.

Na prática, eles são muito fáceis de usar indevidamente. O espaço de trabalho ativo fica invisível, a menos que você o verifique ativamente. Tivemos vários quase acidentes em que os recursos de produção foram modificados quase involuntariamente.

Depois disso, paramos totalmente de usar espaços de trabalho. Diretórios separados com back-ends explícitos tornam óbvio onde você está e o que está prestes a mudar. Essa clareza vale muito mais do que conveniência.

A estrutura que realmente se sustenta

A configuração que nos manteve sãos é simples:

• Módulos compartilhados para infraestrutura reutilizável
• Diretórios de ambiente separados
• Back-ends de estado isolado
• Arquivos variáveis ​​explícitos por ambiente

Quando você implanta em produção, o caminho, o back-end e as variáveis ​​reforçam que você está operando em produção. Não há ambigüidade.

Por que existe o preparo

Cada mudança segue o mesmo caminho:

1. Aplicar em desenvolvimento
2. Aplicar na preparação e executar testes de integração
3. Aplicar no produto durante uma janela controlada

Nunca pulamos a encenação. Ele existe para detectar falhas relacionadas à escala que o desenvolvedor não consegue expor.

Certa vez, uma alteração no firewall funcionou perfeitamente no dev. Na preparação, com tráfego realista, bloqueou as verificações de integridade e desativou o serviço. Essa falha nunca chegou à produção porque a preparação a detectou primeiro.

A verdadeira lição

Gerenciar a infraestrutura entre ambientes não significa encontrar a abstração Terraform perfeita. Trata-se de projetar grades de proteção que evitem erros e tornem óbvias ações arriscadas.

Arquivos de estado separados, arquivos de variáveis ​​explícitas, ambientes isolados e gerenciamento adequado de segredos não são ideias interessantes. Eles são defensivos. E eles evitaram muito mais incidentes do que qualquer truque inteligente do Terraform jamais poderia.

Se você gerencia vários ambientes e ainda não teve uma situação difícil, você terá. Construa grades de proteção agora. Você ficará grato mais tarde.

Sobre o autor: Engenheiro de software principal com 14 anos de experiência na construção e operação de infraestrutura em nuvem em escala. Atualmente na Oracle Cloud Infrastructure. Anteriormente na Amazon, Salesforce, IBM e Tableau.