O elefante na consola
Ler sobre infraestrutura como código a partir do zero é fácil. A realidade é outra: um ambiente com centenas de recursos criados durante anos, à mão, por pessoas que já não estão. Reescrever tudo de uma vez é inviável; deixá-lo de fora significa que a parte mais crítica nunca terá os benefícios do código.
Incorporar, não reconstruir
A maioria das ferramentas permite importar recursos existentes: escreve-se o código que descreve um recurso que já existe e diz-se à ferramenta «este aqui é aquele ali». Sem destruir nem recriar nada.
O trabalho organiza-se por vagas:
- Inventário primeiro. Saber o que existe de verdade, como em antes de arranjar, saber o que há.
- Começar pelo de mais risco e menos mudança: rede, identidades e acessos. Erros aí são graves e estes recursos mudam pouco, pelo que o código se mantém estável.
- Seguir pelos dados: bases de dados e armazenamento, com muito cuidado para não provocar recriações.
- Terminar pela computação, que é o que mais muda e o mais fácil de substituir por versões novas criadas já a partir do código.
A regra de ouro da importação
Depois de importar um recurso, o plano tem de sair vazio. Se o plano propõe mudanças, o código não descreve fielmente o que existe e aplicá-lo modificaria algo que funciona. Ajusta-se o código até o plano não ter nada para fazer, e só então se dá por incorporado.
O que fica de fora
Não tudo merece entrar. Recursos que vão ser retirados em breve ou experiências sem utilização documentam-se como exceções e eliminam-se em vez de se importarem. O objetivo não é os 100 %, mas que o importante esteja em código e o resto esteja identificado.
Com a infraestrutura em código, o passo seguinte natural é que também a operação diária deixe de depender de alguém se lembrar dos passos.
Como o aplicamos: Automação e IaC.