Uma pergunta incómoda
Imagine que amanhã alguém apaga por erro um ambiente inteiro: redes, servidores, bases de dados, regras de acesso. Os dados estão a salvo nas suas cópias, mas a infraestrutura que os rodeia já não existe. Quanto tempo leva a voltar a tê-la exatamente como estava?
Em muitas organizações a resposta honesta é «não sabemos», seguida de «dias, e não ficaria igual». Ninguém se lembra de todas as regras de rede, dos tamanhos escolhidos, dos ajustes feitos à mão ao longo dos anos.
A infraestrutura como código
A alternativa é descrever toda a infraestrutura em ficheiros de texto: que redes existem, que servidores, com que tamanho, que regras os protegem. Esses ficheiros guardam-se num repositório, revêem-se como o código de uma aplicação e uma ferramenta encarrega-se de que a realidade coincida com o descrito.
Com isso, reconstruir deixa de ser um feito e passa a ser um comando. E, pelo caminho, ganha-se todo o resto:
- Histórico: cada mudança tem autor, data e motivo.
- Revisão: uma mudança na rede revê-se antes de ser aplicada, tal como uma mudança no código.
- Repetição: desenvolvimento, aceitação e produção saem do mesmo código, com parâmetros diferentes.
- Documentação que não mente: o código é a descrição do que existe.
O que percorre esta série
Do problema dos cliques a declarar o estado desejado; do código da infraestrutura (o seu estado, os seus módulos, o plano antes de aplicar e o seu custo) a manter cada servidor como deve ser e detetar quando se desvia; de como mudar sem medo (reverter, regras como código, incorporar o herdado) a automatizar a operação diária. E, no fim, o que convém não automatizar.
Comecemos pela origem do problema: os cliques.
Como o aplicamos: Automação e IaC.