Introducción
Ejecutar un playbook es solo una parte del trabajo con Ansible. También es necesario inspeccionar la salida de las tareas, comprender el resumen (recap) y verificar el estado final del nodo gestionado.
En este laboratorio, ejecutará un playbook con ansible-navigator, creará archivos gestionados, volverá a ejecutar el playbook e inspeccionará las pruebas de que el estado deseado se ha alcanzado.
Preparar la configuración del proyecto
En este paso, creará un proyecto que navigator pueda ejecutar sin necesidad de opciones adicionales en la línea de comandos. La configuración es similar a la del laboratorio anterior, pero esta vez el playbook gestionará varios archivos.
Cree y acceda al proyecto.
cd /home/labex/project
mkdir -p rhce-ansible/{inventory/group_vars,playbooks,files}
cd rhce-ansible
Cree los archivos de inventario y configuración.
cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_connection=local
EOF
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
retry_files_enabled = False
interpreter_python = auto_silent
EOF
El inventario crea un grupo managed con un alias de host local. El archivo ansible.cfg establece ese inventario como predeterminado, por lo que navigator puede ejecutar el playbook desde el directorio del proyecto sin necesidad de flags de inventario adicionales.
cat > ansible-navigator.yml <<'EOF'
---
ansible-navigator:
mode: stdout
execution-environment:
enabled: false
playbook-artifact:
enable: false
EOF
La configuración de navigator mantiene este laboratorio orientado a la terminal. mode: stdout imprime la salida de las tareas directamente, la ejecución local evita la configuración de contenedores y la desactivación de artefactos mantiene los archivos visibles del proyecto limitados a los que usted cree.
Crear el contenido fuente para el Playbook
En este paso, creará el contenido fuente que el playbook desplegará. Mantener los archivos fuente dentro del proyecto deja claro qué es lo que Ansible gestiona.
Antes de ejecutar los comandos en este paso, regrese al directorio del proyecto para que las rutas relativas hagan referencia al proyecto de Ansible.
cd /home/labex/project/rhce-ansible
Cree un archivo fuente.
cat > files/motd.txt <<'EOF'
RHCE Ansible navigator practice host
EOF
Este es el contenido fuente: es el archivo que desea que Ansible despliegue, no la copia gestionada final. Mantener los archivos fuente separados de la salida generada facilita ver qué es lo que el playbook gestiona.
Cree una variable de ruta de directorio de destino en un archivo de variables de grupo del inventario. Mantener este archivo bajo inventory/group_vars hace que se cargue de forma consistente cuando los playbooks se almacenan en un subdirectorio.
mkdir -p inventory/group_vars
cat > inventory/group_vars/all.yml <<'EOF'
managed_dir: /home/labex/project/rhce-ansible/managed-state
EOF
managed_dir es una variable específica del proyecto. Definirla en inventory/group_vars/all.yml permite que el playbook haga referencia a un nombre en lugar de repetir la misma ruta absoluta en cada tarea.
Escribir el Playbook de estado gestionado
En este paso, escribirá un playbook que crea un directorio y copia un archivo en él. El módulo file gestiona directorios y permisos; el módulo copy despliega el contenido del archivo. Debido a que este playbook reside en el directorio playbooks, la ruta de origen ../files/motd.txt apunta al directorio files a nivel de proyecto.
Antes de ejecutar los comandos en este paso, regrese al directorio del proyecto para que las rutas relativas hagan referencia al proyecto de Ansible.
cd /home/labex/project/rhce-ansible
Cree playbooks/manage-state.yml.
cat > playbooks/manage-state.yml <<'EOF'
---
- name: Manage local state with navigator
hosts: managed
gather_facts: false
tasks:
- name: Create managed state directory
ansible.builtin.file:
path: "{{ managed_dir }}"
state: directory
mode: '0755'
- name: Deploy managed message
ansible.builtin.copy:
src: ../files/motd.txt
dest: "{{ managed_dir }}/motd.txt"
mode: '0644'
EOF
Lea el playbook en orden. La primera tarea asegura que el directorio de destino exista, y la segunda tarea copia el archivo fuente en ese directorio. Las expresiones {{ managed_dir }} se reemplazan con el valor cargado desde inventory/group_vars/all.yml.
Ejecute una comprobación de sintaxis antes de realizar cambios en el sistema.
ansible-playbook playbooks/manage-state.yml --syntax-check
Esta comprobación sigue siendo útil aunque ejecute el playbook con navigator. Navigator entrega el playbook a Ansible, por lo que un playbook que falle en el análisis de sintaxis normal también fallará a través de navigator.
Ejecutar el Playbook con Navigator
En este paso, ejecutará el playbook. La línea de resumen (recap) es importante: ok cuenta las tareas que alcanzaron el estado deseado, changed cuenta las tareas que modificaron algo, y failed=0 significa que la ejecución se completó con éxito.
Antes de ejecutar los comandos en este paso, regrese al directorio del proyecto para que las rutas relativas hagan referencia al proyecto de Ansible.
cd /home/labex/project/rhce-ansible
Ejecute el playbook.
ansible-navigator run playbooks/manage-state.yml
Inspeccione el archivo de salida gestionado directamente.
El resumen le indica si la ejecución se completó, pero el archivo gestionado demuestra que el estado solicitado existe. Debería ver el mismo texto que colocó en files/motd.txt.
cat managed-state/motd.txt
Ejecutar de nuevo e inspeccionar la idempotencia
En este paso, ejecutará el mismo playbook nuevamente. Un playbook bien escrito debería ser seguro de repetir. Si el archivo ya tiene el contenido y los permisos solicitados, Ansible no debería necesitar cambiar nada.
Antes de ejecutar los comandos en este paso, regrese al directorio del proyecto para que las rutas relativas hagan referencia al proyecto de Ansible.
cd /home/labex/project/rhce-ansible
Ejecute el playbook por segunda vez y guarde la salida.
ansible-navigator run playbooks/manage-state.yml | tee navigator-second-run.txt
Busque el resumen. El espaciado exacto puede variar, pero el resumen debería seguir mostrando cero fallos.
La segunda ejecución trata sobre la repetibilidad. Una ejecución limpia con failed=0 demuestra que el playbook puede aplicarse de nuevo sin romper el estado gestionado; si también aparece changed=0, demuestra que las tareas ya estaban satisfechas.
grep -E 'failed=0' navigator-second-run.txt
Resumen
Ha ejecutado un playbook con ansible-navigator, inspeccionado el archivo gestionado que creó y repetido el playbook para comprobar que puede ejecutarse de nuevo de forma limpia. Este es el ciclo básico de ejecutar-inspeccionar-verificar utilizado en todo el trabajo de automatización con Ansible.
