Comandos ad-hoc de Ansible y modo check para una primera ejecución segura sobre un conjunto de hosts

Objetivo

Comprobar que Ansible puede conectarse a un conjunto de hosts gestionados y previsualizar un cambio sobre ellos antes de aplicarlo de verdad, usando solo comandos ad-hoc y el modo check; para la previsualización no se necesita ningún playbook.

Requisitos previos

Ansible instalado en el nodo de control; un archivo de inventario con los hosts y grupos de destino; acceso funcional por SSH (o WinRM, en el caso de destinos Windows) y, para los cambios con privilegios, un método become como sudo configurado para el usuario que se conecta.

Pasos

1. Confirma la conectividad y que Python está disponible en cada nodo gestionado: ansible all -m ping. all es el grupo integrado de Ansible que abarca todos los hosts del inventario; un host en buen estado responde con un resultado pong (los hosts Windows usan ansible.windows.win_ping). La sintaxis de los comandos ad-hoc de Ansible se documenta, en general, como ansible [pattern] -m [module] -a "[module options]", donde el patrón selecciona los hosts y -m indica el módulo que se ejecuta.
2. Acota a un subconjunto antes de probar algo más arriesgado: ansible webservers --limit "*.example.com" -m ping, o apunta a un único host por su nombre. --limit restringe aún más un patrón ya resuelto, lo cual es más seguro que editar el inventario para probar con menos hosts.
3. Previsualiza un cambio real sin aplicarlo: ansible webservers -b -m ansible.builtin.service -a "name=cron state=started" --check. Sin -b, la previsualización se ejecuta sin privilegios y puede diferir de la ejecución real. La documentación de Ansible indica que "In check mode, Ansible runs without making any changes on remote systems" (en modo check, Ansible se ejecuta sin hacer ningún cambio en los sistemas remotos); los módulos compatibles con el modo check informan de los cambios que habrían hecho en lugar de realizarlos, y los módulos sin esa compatibilidad "report nothing and do nothing" (no informan de nada y no hacen nada).
4. Añade --diff junto con --check para ver el contenido antes y después en los módulos que lo admiten (principalmente los que manipulan archivos). La documentación advierte de que el modo diff "produces a large amount of output" (produce una gran cantidad de salida) y sugiere ir host por host (--limit host1); además, los diffs pueden mostrar secretos contenidos en archivos.
5. Para cualquier comando que requiera privilegios elevados en el destino, añade --become (-b): la propia documentación de Ansible describe become como el uso de "existing privilege escalation systems to execute tasks with root privileges or with another user's permissions" (sistemas de escalada de privilegios existentes para ejecutar tareas con privilegios de root o con los permisos de otro usuario), apoyado en herramientas como sudo, su o doas, según lo que esté configurado en cada host.
6. Solo cuando la previsualización en modo check sea correcta, vuelve a ejecutar el mismo comando sin --check para aplicarlo, idealmente todavía acotado con --limit, primero a un grupo canario pequeño.

Resultado esperado

ansible all -m ping devuelve un pong de cada host alcanzable; la ejecución con --check --diff muestra el cambio exacto que haría un módulo sin que se produzca ninguna modificación; y la ejecución real posterior coincide con lo que mostró la previsualización.

Límites y base de verificación

El modo check "is just a simulation" (es solo una simulación): en los playbooks, las tareas con condicionales basados en los resultados registrados de tareas anteriores no producen una salida significativa. El módulo ad-hoc por defecto, command, no puede predecir un comando arbitrario y se omite con --check. Un módulo sin compatibilidad con el modo check no hace nada bajo --check, lo que puede dar la impresión de que "no hacía falta cambiar nada"; antes de fiarte de una previsualización limpia, consulta en la documentación del módulo su atributo de compatibilidad check_mode. Los propios comandos ad-hoc no son artefactos de seguimiento idempotentes: nada deja constancia de que un comando ad-hoc concreto se haya ejecutado alguna vez, salvo el historial del shell y los registros que el nodo de control tenga configurados.