Cómo manejar cloud-init en una instancia nueva de Debian o Ubuntu: user-data, status --wait y reejecuciones seguras

Objetivo

Comprobar que cloud-init ha terminado de configurar una imagen cloud de Debian o Ubuntu, validar un archivo user-data antes de depender de él y volver a probarlo de forma segura en la misma instancia.

Requisitos previos

Una instancia arrancada desde una imagen cloud con cloud-init instalado (algo habitual en las imágenes cloud/server de Debian y Ubuntu) y acceso a la shell, preferiblemente a través de la consola del proveedor durante el primer arranque, por si el user-data deja la red inutilizable.

Pasos

1. Tras el arranque, bloquee cualquier otra automatización hasta que el aprovisionamiento haya terminado: cloud-init status --wait. La referencia de comandos describe --wait como un bloqueo "until cloud-init completes" (hasta que cloud-init termina). El subcomando status, por su parte, indica si cloud-init está en estado running, done, disabled o en error, y devuelve el código de salida 1 si se produce un fallo grave y 2 si hay errores recuperables.
2. Si algo falla, consulte para el diagnóstico los dos archivos de registro que el propio cloud-init señala: /var/log/cloud-init.log (traza detallada de los módulos) y /var/log/cloud-init-output.log (stdout/stderr capturados de lo que ejecutó cloud-init).
3. Antes de asociar un nuevo archivo user-data a una instancia, valídelo en local: cloud-init schema --system --annotate. El subcomando schema permite "Validate cloud-config files using jsonschema" (validar archivos cloud-config mediante jsonschema); --system lo dirige al user-data que realmente está en uso, en lugar de un archivo pasado como argumento, y --annotate marca directamente en el texto las líneas con errores.
4. Para volver a probar el aprovisionamiento en una instancia en ejecución, en lugar de lanzar una nueva, restablezca el estado de cloud-init: cloud-init clean --logs --reboot. El subcomando clean elimina los artefactos de cloud-init "to simulate a clean instance" (para simular una instancia limpia); en el siguiente arranque, cloud-init vuelve a ejecutar todas las etapas igual que la primera vez. --logs borra además los archivos de registro anteriores, de modo que la salida de la nueva ejecución no se mezcle con la antigua.
5. Tras el reinicio, repita el paso 1 para confirmar que la nueva ejecución ha terminado y, si algo ha cambiado, compare con diff el nuevo /var/log/cloud-init.log con el anterior.

Resultado esperado

cloud-init status --wait termina tras el aprovisionamiento con código de salida 0, y cloud-init schema --system no informa de errores en el user-data activo.

Límites y base de verificación

cloud-init clean en una instancia de producción no elimina por sí mismo datos de usuario, pero sí restablece los marcadores de identidad del host que se usan para decidir «si es el primer arranque» (con --machine-id, también /etc/machine-id). Está pensado para clonar imágenes base (golden images) y para pruebas, no para la operación rutinaria: trátelo como un paso de laboratorio. --reboot es necesario para que la reejecución comience automáticamente; sin él hay que lanzar manualmente cloud-init init.