cloud-init es el estándar de facto para inicializar instancias en la nube durante su primer arranque. Cuando lanzas una instancia y le pasas un script de user-data, es cloud-init quien lo interpreta y ejecuta: crea usuarios, escribe ficheros, instala paquetes, monta discos o arranca servicios.
La combinación ideal es clara: la golden AMI contiene lo que no cambia —sistema operativo, runtime, hardening— y user-data aporta lo que varía por entorno o por instancia: configuración, secretos inyectados, rol. Así reutilizas una sola imagen en muchos contextos.
Dos formas de escribir user-data
user-data admite varios formatos; los dos más habituales son el script de shell y el cloud-config.
- Script de shell: empieza por
#!/bin/bash. Simple y directo para tareas rápidas. - cloud-config: empieza por
#cloud-configy usa YAML declarativo. Más limpio, legible e idempotente para configurar usuarios, paquetes, ficheros y comandos.
Ejemplo de cloud-config
Un #cloud-config típico declara secciones como packages: (paquetes a instalar),
write_files: (ficheros de configuración), runcmd: (comandos finales) y users:
(cuentas y claves). Al ser declarativo, es más fácil de revisar y mantener que un script
largo.
Buenas prácticas
- Mantén user-data pequeño: si crece demasiado, probablemente eso debería estar horneado en la AMI.
- Idempotencia: diseña los comandos para que reejecutarlos no rompa nada.
- Nunca pongas secretos en claro en user-data: es legible desde los metadatos de la instancia. Inyéctalos desde Secrets Manager, Parameter Store o Vault en tiempo de ejecución.
- Protege el acceso a los metadatos: usa IMDSv2 para mitigar el robo de credenciales vía SSRF.
- Registra y depura: los logs de cloud-init (
/var/log/cloud-init-output.log) son tu mejor amigo cuando algo falla.
Baking o booting: dónde poner cada cosa
| Va en la AMI (baking) | Va en user-data (booting) |
|---|---|
| Sistema operativo y parches | Configuración específica del entorno |
| Runtime, agentes y hardening | Variables y parámetros por instancia |
| Software estable y pesado | Registro en el clúster y descubrimiento |
| Todo lo que tarda en instalarse | Inyección de secretos en runtime |
Regla de oro: lo estable y lento se hornea; lo variable y ligero va en el arranque.
Errores comunes que cuestan horas
- Meter en user-data lo que debería estar en la imagen, con arranques lentos y frágiles como resultado.
- Exponer secretos en texto plano en los metadatos.
- Suponer que user-data se reejecuta en cada arranque: por defecto solo corre en el primero.
- No revisar los logs de cloud-init cuando la instancia «no hace lo que debería».
Preguntas frecuentes
¿user-data se ejecuta en cada reinicio?
Por defecto, solo en el primer arranque. Se puede configurar cloud-init para ejecutar ciertas partes en cada arranque, pero conviene hacerlo de forma consciente e idempotente.
¿Es seguro pasar contraseñas en user-data?
No. user-data es legible desde los metadatos de la instancia. Usa un gestor de secretos e inyéctalos en tiempo de ejecución, y protege los metadatos con IMDSv2.
¿cloud-init solo funciona en AWS?
No. cloud-init es multiplataforma y funciona en AWS, Azure, GCP y otros, lo que lo hace ideal para automatizar el arranque de forma portable.
En imaxe.cloud diseñamos imágenes pensadas para combinarse con cloud-init, de modo que una sola AMI te sirva en muchos escenarios.
