Use cloud-init ou user data para rodar scripts no primeiro boot. Ansible, Chef ou Puppet mantêm config consistente entre servidores. Guarde segredos em um vault; nunca hardcode. Documente o processo de bootstrap.
Primeiro boot: cloud-init e user data
- Cloud-init: Padrão em muitas imagens Linux. Você passa user data (YAML ou script) ao criar a instância; roda no primeiro boot. Use para instalar pacotes, criar usuários, escrever configs e rodar comandos.
- User data: Específico do provedor (ex.: user data da EC2); mesma ideia: script ou config cloud-init executado no launch. Evite segredos em texto plano (use endpoint de segredos ou env de um store seguro).
- Limites: User data tem limite de tamanho; para setup complexo chame um script em outro lugar ou use config management em uma segunda fase.
Config management (segunda fase)
- Ansible / Chef / Puppet: Depois que o servidor estiver acessível, rode playbooks ou manifests para levar ao estado desejado. Mantém todos os servidores consistentes e versionados.
- Quando: Dispare a partir do CI/CD após criar a instância, ou rode em agendamento (ex.: Ansible pull). Combine com cloud-init para instalar Ansible e rodar um playbook.
- Segredos: Obtenha de um vault (HashiCorp Vault, secret manager da nuvem). Nunca coloque senhas ou chaves no Git ou user data em texto plano.
Documentação e repetibilidade
- Documente: Escreva um runbook curto: o que o cloud-init faz, o que o config management faz e em que ordem. Assim qualquer um (ou um pipeline) pode subir um novo servidor do mesmo jeito.
- Teste: De tempos em tempos crie um servidor do zero com o mesmo processo para detectar drift e premissas quebradas.
- Versione: Mantenha playbooks e scripts no Git.
Resumo
Use cloud-init ou user data para setup no primeiro boot; use Ansible/Chef/Puppet para config contínua. Guarde segredos em vault; nunca hardcode. Documente e teste o processo de bootstrap para ser repetível.
