IaC: boas práticas
Esta aula aborda as boas práticas fundamentais para Infraestrutura como Código (IaC), incluindo versionamento, revisão de mudanças, gestão de ambientes e a regra de ouro de nunca editar manualmente. O conteúdo é prático, com exemplos em bash e orientações para equipes que desejam adotar IaC de forma profissional.
Nesta aula, vamos explorar as boas práticas essenciais para trabalhar com Infraestrutura como Código (IaC). IaC é a prática de gerenciar e provisionar infraestrutura por meio de arquivos de definição, em vez de processos manuais. Isso traz consistência, rastreabilidade e automação para o gerenciamento de servidores, redes e outros componentes.
Dominar essas boas práticas é crucial para evitar problemas comuns como configurações divergentes, mudanças não rastreáveis e retrabalho. Vamos cobrir quatro pilares: versionamento, revisão de mudanças, ambientes e a proibição de edições manuais. Cada um deles contribui para um fluxo de trabalho mais seguro e eficiente.
Versionamento
Versionar o código de infraestrutura é o primeiro passo para ter controle sobre as mudanças. Assim como o código de aplicação, os arquivos de IaC devem ser armazenados em um sistema de controle de versão (como Git). Isso permite rastrear o histórico, reverter alterações problemáticas e colaborar com outros membros da equipe.
Uma boa prática é manter os arquivos de IaC em um repositório dedicado ou em um diretório separado no repositório do projeto, com uma estrutura clara. Por exemplo:
infra/
modules/
networking/
compute/
environments/
dev/
staging/
prod/
global/
iam/
logging/Além disso, é importante usar branches para isolar mudanças e tags para marcar versões estáveis. Versionar também inclui documentar as mudanças com mensagens de commit claras e descritivas.
Ferramentas como Terraform, CloudFormation e Ansible possuem integração natural com Git. Por exemplo, ao usar Terraform, você pode versionar os arquivos .tf e usar terraform plan para revisar as mudanças antes de aplicá-las.
Revisão de mudanças
Nenhuma mudança em infraestrutura deve ser aplicada sem passar por uma revisão. Isso é semelhante ao code review para código de aplicação, mas com um cuidado extra, pois mudanças de infraestrutura podem ter impacto direto em produção.
Adote um fluxo de pull requests (PRs) ou merge requests (MRs) para que outros membros da equipe revisem as alterações. Utilize ferramentas de CI/CD para executar verificações automáticas, como validação de sintaxe, linting e até mesmo terraform plan para mostrar o impacto das mudanças.
Exemplo de um pipeline de revisão para Terraform:
# .gitlab-ci.yml
stages:
- validate
- plan
- apply
validate:
stage: validate
script:
- terraform fmt -check
- terraform validate
plan:
stage: plan
script:
- terraform plan -out=tfplan
artifacts:
paths:
- tfplan
apply:
stage: apply
script:
- terraform apply tfplan
only:
- mainA revisão deve ser obrigatória, mesmo para mudanças simples. Isso cria uma cultura de responsabilidade compartilhada e reduz a probabilidade de erros.
Ambientes
É fundamental ter ambientes separados (desenvolvimento, staging, produção) para testar mudanças antes de levá-las a produção. Cada ambiente deve ser tão parecido quanto possível com o ambiente de produção, mas com custos e riscos reduzidos.
Com IaC, você pode parametrizar os ambientes usando variáveis ou arquivos de configuração. Por exemplo, no Terraform, você pode usar workspaces ou diretórios separados por ambiente. No Ansible, pode usar inventários diferentes.
Exemplo de estrutura com Terraform workspaces:
terraform workspace new dev
export TF_VAR_environment=dev
terraform plan
terraform applyUma prática recomendada é usar o mesmo código para todos os ambientes, apenas com valores de configuração diferentes. Isso garante que o que foi testado em staging seja exatamente o que será aplicado em produção, evitando surpresas.
Além disso, considere a criação de ambientes efêmeros para testes de pull requests, usando ferramentas como Atlantis ou Terragrunt.
Não editar manualmente
A regra de ouro da IaC é: nunca edite a infraestrutura manualmente. Qualquer mudança deve ser feita no código e aplicada por meio das ferramentas de IaC. Edições manuais levam a 'drift' (divergência) entre o estado real e o desejado, tornando o código não confiável.
Se você encontrar uma configuração que foi alterada manualmente, o correto é reverter para o estado definido no código ou atualizar o código para refletir a mudança desejada, e então aplicá-la via IaC.
Para detectar drift, use comandos como terraform plan ou aws config para comparar o estado atual com o desejado. Ferramentas como Terraform possuem o conceito de estado (state) que rastreia os recursos gerenciados.
terraform plan
# Saída mostra as diferenças entre o estado atual e o desejadoAlém disso, desencoraje o acesso direto aos consoles de gerenciamento para alterações de infraestrutura. Implemente políticas de IAM que restrinjam permissões de edição, permitindo que apenas as ferramentas de IaC façam alterações.
Boas práticas adicionais
Além dos quatro pilares, considere:
- Use módulos para reutilizar código de infraestrutura.
- Documente o código com comentários e um README.
- Implemente testes de infraestrutura (por exemplo, usando Terratest ou InSpec).
- Automatize a aplicação de mudanças com pipelines de CI/CD.
- Mantenha os segredos fora do código, usando ferramentas como Vault ou AWS Secrets Manager.
Referências
- AWS CloudFormation Documentation
- Terraform Documentation
- Ansible Documentation
- Docker Documentation
- Kubernetes Documentation
- GitHub Actions Documentation
- GitLab CI/CD Documentation
Exercícios
Explique por que é importante versionar os arquivos de IaC e dê um exemplo de estrutura de diretórios para um projeto Terraform.
✓ Resposta: Versionar é importante para rastrear mudanças, colaborar, reverter alterações e ter um histórico. Exemplo de estrutura:infra/ modules/ networking/ compute/ environments/ dev/ staging/ prod/ global/Descreva como você implementaria a revisão de mudanças em um fluxo de trabalho com Terraform e Git.
✓ Resposta: Usaria um fluxo de pull requests: cada mudança em um branch, com CI rodando `terraform fmt`, `terraform validate` e `terraform plan`. A revisão seria obrigatória antes do merge para a branch principal, e o apply seria feito automaticamente após o merge (ou manualmente após aprovação).Qual é a diferença entre usar workspaces do Terraform e usar diretórios separados para ambientes? Cite vantagens e desvantagens de cada.
✓ Resposta: Workspaces permitem usar o mesmo código com estados diferentes, mas podem ser confusos em projetos grandes. Diretórios separados isolam completamente os ambientes, mas duplicam código. Workspaces são melhores para ambientes efêmeros; diretórios são melhores para ambientes fixos e controle granular.O que é drift em IaC e como você pode detectá-lo?
✓ Resposta: Drift é a divergência entre o estado real da infraestrutura e o estado desejado definido no código. Pode ser detectado com `terraform plan`, que mostra as diferenças, ou com ferramentas como AWS Config.Por que nunca se deve editar a infraestrutura manualmente? Dê um exemplo de um problema que isso pode causar.
✓ Resposta: Edições manuais quebram a consistência e a rastreabilidade. Por exemplo, se alguém aumenta manualmente o tamanho de um disco em produção, o código não refletirá isso, e um `terraform apply` futuro pode reverter a mudança, causando interrupção.