Use cloud-init o user data para ejecutar scripts en el primer arranque. Ansible, Chef o Puppet mantienen la config consistente entre servidores. Guarde secretos en un vault; nunca hardcode. Documente el proceso de bootstrap.
Primer arranque: cloud-init y user data
- Cloud-init: Estándar en muchas imágenes Linux. Usted pasa user data (YAML o script) al crear la instancia; se ejecuta en el primer arranque. Úselo para instalar paquetes, crear usuarios, escribir configs y ejecutar comandos.
- User data: Específico del proveedor (ej. user data de EC2); misma idea: script o config cloud-init ejecutado al lanzar. Evite secretos en texto plano (use endpoint de secretos o env de un almacén seguro).
- Límites: User data tiene límite de tamaño; para setup complejo llame a un script en otro sitio o use config management en una segunda fase.
Config management (segunda fase)
- Ansible / Chef / Puppet: Cuando el servidor sea accesible, ejecute playbooks o manifiestos para llevarlo al estado deseado. Mantiene todos los servidores consistentes y versionados.
- Cuándo: Dispare desde CI/CD tras crear la instancia, o ejecute en schedule (ej. Ansible pull). Combine con cloud-init para instalar Ansible y ejecutar un playbook.
- Secretos: Obténgalos de un vault (HashiCorp Vault, gestor de secretos de la nube). Nunca ponga contraseñas o claves en Git o user data en texto plano.
Documentación y repetibilidad
- Documente: Escriba un runbook corto: qué hace cloud-init, qué hace config management y en qué orden. Así cualquiera (o un pipeline) puede levantar un nuevo servidor igual.
- Pruebe: Periódicamente cree un servidor desde cero con el mismo proceso para detectar drift y suposiciones rotas.
- Versionar: Mantenga playbooks y scripts en Git.
Resumen
Use cloud-init o user data para setup en el primer arranque; use Ansible/Chef/Puppet para config continua. Guarde secretos en vault; nunca hardcode. Documente y pruebe el proceso de bootstrap para que sea repetible.
