Introducción
Un comando puntual de Ansible puede inspeccionar un conjunto de máquinas o aplicar un estado de configuración pequeño y explícito. Elegir el módulo adecuado facilita comprender su comportamiento y los resultados devueltos.
Inspeccionarás dos destinos Linux, prepararás un directorio administrado y distribuirás un archivo de origen del controlador. Compararás la ejecución de comandos con módulos que informan de si el estado solicitado necesitaba realmente un cambio. El inventario y las conexiones SSH ya están preparados.
Inspeccionar un grupo de hosts con módulos
En este paso, elegirás módulos puntuales de Ansible para inspeccionar los dos nodos administrados preparados.
Abre el Terminal y selecciona el espacio de trabajo:
cd /home/labex/project
Un comando ad hoc ejecuta un módulo directamente en los hosts seleccionados del inventario, sin un playbook. Su estructura básica es ansible PATTERN -m MODULE -a ARGUMENTS. El laboratorio proporciona un grupo webservers que contiene ambos destinos SSH. Previsualiza ese grupo:
ansible webservers --list-hosts
Deberías obtener exactamente web1 y web2. Usa el módulo command del laboratorio anterior para ejecutar uname -s, que imprime el nombre del kernel del sistema operativo:
ansible webservers -m ansible.builtin.command -a 'uname -s'
Cada host debería imprimir Linux. El módulo command normalmente informa CHANGED incluso para una consulta de solo lectura. Inspecciona stdout y el estado de retorno en lugar de interpretar esa etiqueta como un cambio de configuración.
El módulo setup recopila facts, información estructurada descubierta en un nodo administrado. El argumento filter del módulo restringe los datos devueltos. Inspecciona el nombre de la distribución:
ansible webservers -m ansible.builtin.setup -a 'filter=ansible_distribution'
Cada resultado correcto debería incluir un objeto ansible_facts que contenga "ansible_distribution": "Ubuntu". setup suele informar changed: false para esta inspección. Los facts describen el destino, no tu controlador; en laboratorios posteriores los usarás en automatizaciones.
Un resultado de tarea distinto de cero es un fallo, y UNREACHABLE indica un problema de conexión. Dos hosts esperados requieren dos resultados correctos. No confundas una selección vacía con una inspección completada.
Declarar un directorio administrado
En este paso, usarás un módulo orientado al estado para preparar el mismo directorio en ambos destinos.
El módulo file administra el estado del sistema de archivos. Su path identifica la ruta de destino, y state=directory solicita un directorio en lugar de un archivo vacío. mode=0750 concede al propietario acceso completo, al grupo acceso de lectura y búsqueda y al resto ningún acceso. El cero inicial indica un valor de permisos octal.
Las tareas normales se ejecutan con la cuenta automation preparada. Crea un directorio dentro del directorio personal de ese usuario, de modo que no se necesite become:
ansible webservers -m ansible.builtin.file -a 'path=/home/automation/ops state=directory mode=0750'
Ambos hosts deberían informar changed: true cuando el directorio se crea por primera vez, con un campo path o dest que identifique /home/automation/ops. El directorio pertenece a automation porque esa cuenta lo crea.
Ejecuta la misma declaración otra vez:
ansible webservers -m ansible.builtin.file -a 'path=/home/automation/ops state=directory mode=0750'
Ahora deberías obtener changed: false en ambos hosts: el estado solicitado ya existe. Esto difiere de emitir repetidamente un comando general como touch, que todavía puede actualizar marcas de tiempo.
Copiar un archivo del controlador a ambos destinos
En este paso, crearás un pequeño archivo de origen en el controlador y desplegarás su contenido exacto con permisos explícitos en el destino.
printf escribe el texto y un salto de línea final; > crea o sustituye el archivo de origen en el proyecto actual. El formato entrecomillado mantiene unido el mensaje, mientras que \n solicita el salto de línea:
printf 'Managed by Ansible\n' > message.txt
El módulo copy transfiere un archivo de origen del controlador a un destino administrado. src está en el controlador, mientras que dest está en cada destino. Para un archivo normal, mode=0640 concede al propietario lectura y escritura, al grupo lectura y al resto ningún acceso:
ansible webservers -m ansible.builtin.copy -a 'src=/home/labex/project/message.txt dest=/home/automation/ops/message.txt mode=0640'
Cada destino debería informar changed: true en la copia inicial. Ejecuta otra vez la misma transferencia:
ansible webservers -m ansible.builtin.copy -a 'src=/home/labex/project/message.txt dest=/home/automation/ops/message.txt mode=0640'
Deberías obtener changed: false cuando los bytes y los permisos solicitados ya coincidan. El módulo file preparó el directorio padre; copiar un archivo no sustituye ese paso de creación del directorio.
Lee el contenido remoto real con el módulo command:
ansible webservers -m ansible.builtin.command -a 'cat /home/automation/ops/message.txt'
Ambos resultados stdout deberían mostrar Managed by Ansible. La consulta con command puede informar CHANGED, pero el resultado changed:false anterior del módulo copy describe un archivo administrado que ya coincide. Tu archivo de origen del controlador sigue separado de ambas copias remotas.
Resumen
Has ejecutado módulos ad hoc en un grupo real de dos hosts, interpretado la salida de comandos y descubierto datos de la distribución. Has declarado un directorio, copiado un archivo de origen separado del controlador con permisos explícitos y observado resultados sin cambios cuando los módulos orientados al estado encontraron un estado coincidente en una ejecución repetida.
