Introducción
Varios comandos puntuales relacionados son más fáciles de repetir y revisar cuando se guardan en un playbook. Un playbook útil describe un estado deseado estable y produce resultados observables en cada destino previsto.
Escribirás un pequeño playbook YAML usando los módulos file y copy, lo aplicarás a dos nodos SSH y verificarás tanto los archivos creados como una ejecución repetida sin cambios. Este laboratorio introduce plays, tareas e idempotencia sin variables, bucles ni roles.
Escribir un playbook en YAML
En este paso, combinarás los módulos file y copy que ya has practicado en un playbook reutilizable.
Entra en el proyecto desde el Terminal:
cd /home/labex/project
Un playbook es una lista YAML de plays. Cada play vincula un patrón de hosts con una lista ordenada de tareas. Cada tarea nombra un módulo y sus argumentos. Las etiquetas name ayudan a las personas a leer la salida; no crean configuración por sí mismas.
YAML usa sangría para anidar datos. Usa espacios, no tabuladores. Un - inicial comienza un elemento de lista y los dos puntos introducen el valor de una clave. Aquí, tasks contiene dos tareas de módulos. Los modos entrecomillados como "0750" siguen siendo cadenas de permisos. gather_facts: false omite la recopilación automática de datos porque estas tareas de estado fijo no consumen facts.
Crea el archivo con un documento insertado entrecomillado, como has practicado antes. Copia hasta la línea EOF final incluida:
cat > workspace.yml <<'EOF'
- name: Prepare managed workspaces
hosts: all
gather_facts: false
tasks:
- name: Create the workspace directory
ansible.builtin.file:
path: /home/automation/workspace
state: directory
mode: "0750"
- name: Write the workspace notice
ansible.builtin.copy:
dest: /home/automation/workspace/README.txt
content: "Workspace managed by Ansible\n"
mode: "0640"
EOF
La primera tarea declara un directorio. La segunda usa el argumento content de copy para proporcionar texto literal directamente, en lugar de leer un archivo src del controlador. La cadena YAML entre comillas dobles interpreta \n como un salto de línea final. El contenido fijo hace estable una ejecución repetida; no añadas una marca de tiempo cambiante.
El play usa hosts: all, que significa ambos nodos SSH proporcionados. Las tareas normales se ejecutan como automation, por lo que se puede escribir en su directorio personal sin become.
ansible-playbook ejecuta archivos de playbook. Primero usa --syntax-check para validar la estructura sin aplicar tareas:
ansible-playbook workspace.yml --syntax-check
Deberías obtener una línea que identifica el playbook y ningún error del analizador. La validación de sintaxis por sí sola no demuestra conectividad remota ni archivos finales correctos.
Previsualiza la selección de hosts del play usando --list-hosts:
ansible-playbook workspace.yml --list-hosts
El play debe enumerar web1 y web2. Una lista vacía no es un playbook utilizable de dos hosts.
Aplicar el estado deseado
En este paso, ejecutarás el playbook e inspeccionarás sus resultados remotos reales.
Ejecuta el archivo desde el proyecto para que se seleccionen su configuración e inventario:
ansible-playbook workspace.yml
Ansible imprime el nombre de cada play y tarea y después un PLAY RECAP. En un entorno nuevo, las dos tareas deberían cambiar cada host:
web1 : ok=2 changed=2 unreachable=0 failed=0 ...
web2 : ok=2 changed=2 unreachable=0 failed=0 ...
El espaciado y el orden de los hosts pueden variar. ok cuenta las tareas correctas, changed cuenta las tareas que necesitaron cambios, y unreachable/failed deberían ser ambos cero. El nombre de una tarea correcta por sí solo no demuestra los bytes ni los permisos requeridos del archivo.
Lee cada aviso remoto usando el módulo command ad hoc:
ansible all -m ansible.builtin.command -a 'cat /home/automation/workspace/README.txt'
Ambos valores stdout deberían mostrar Workspace managed by Ansible. La consulta de comando de solo lectura todavía puede informar CHANGED; los resultados de file/copy del playbook describen el estado declarado. El directorio administrado tiene permisos 0750, el aviso tiene permisos 0640 y ambos pertenecen a automation.
Verificar la convergencia idempotente
En este paso, repetirás el playbook y confirmarás que un estado coincidente no requiere cambios adicionales.
La idempotencia significa que aplicar repetidamente el mismo estado deseado no produce cambios innecesarios después de la convergencia. Ejecuta otra vez el mismo playbook:
ansible-playbook workspace.yml
Deberías obtener un resumen de cada destino con ok=2, changed=0, unreachable=0 y failed=0. Ambos archivos permanecen presentes y correctos. Una marca de tiempo cambiante o un comando general incondicional perjudicaría este resultado estable.
--check solicita una previsualización: los módulos compatibles predicen cambios sin aplicarlos. Tanto file como copy admiten este flujo de trabajo. Previsualiza el playbook que ya ha convergido:
ansible-playbook workspace.yml --check
Deberías obtener otra vez cero cambios para ambos hosts. Una previsualización no sustituye la primera ejecución real ni la inspección del estado real. Aquí confirma que los espacios de trabajo ya creados coinciden con las declaraciones.
Conserva el playbook para reutilizarlo en el futuro. No suprimas cambios con changed_when ni fuerces tareas fuera del modo de comprobación para fabricar un resumen limpio; el resultado debe reflejar un estado real coincidente.
Resumen
Has expresado la selección de hosts y las tareas ordenadas de módulos en YAML, comprobado la sintaxis y el alcance de los destinos y aplicado el playbook a dos nodos administrados reales. El estado real de los archivos coincidió con los requisitos, una segunda ejecución real no hizo cambios adicionales y el modo de comprobación de solo lectura no encontró cambios pendientes.
