Introducción
La automatización solo es segura cuando llega a los hosts previstos. Dos alias para una misma máquina, un host ausente o una selección demasiado amplia pueden hacer que un comando correcto resulte engañoso.
En este laboratorio, organizarás dos destinos SSH distintos en grupos canary y stable, inspeccionarás un grupo padre, previsualizarás patrones de hosts y crearás un archivo marcador únicamente en el host canary. Ansible y las conexiones de formación ya están preparados; trabajarás con el inventario y el alcance de los comandos.
Organizar hosts en grupos
En este paso, agruparás los dos hosts SSH existentes sin duplicar sus identidades ni sus direcciones.
Abre el Terminal y entra en el proyecto:
cd /home/labex/project
Lee el inventario proporcionado antes de editarlo:
cat inventory.ini
Define web1 y web2 con distintos valores ansible_host. Conserva esas líneas y los ajustes de conexión de [all:vars]. Los nombres del inventario identifican hosts; colocar el mismo nombre en varios grupos no crea otro servidor.
Un grupo describe un conjunto de hosts. Usaremos canary para el primer host, stable para el segundo y webservers como padre que contiene ambos grupos. Añade estas secciones. >> conserva el archivo existente y el delimitador entrecomillado del documento insertado mantiene literal el texto pegado:
cat >> inventory.ini <<'EOF'
[canary]
web1
[stable]
web2
[webservers:children]
canary
stable
EOF
[canary] y [stable] contienen nombres de host. Una sección que termina en :children contiene nombres de grupos, por lo que webservers hereda los hosts pertenecientes a canary y stable. No pongas nuevas direcciones de destino bajo estos grupos.
ansible-inventory --graph dibuja la pertenencia resuelta:
ansible-inventory --graph
Deberías ver web1 bajo canary y web2 bajo stable, con ambos grupos debajo de webservers. También pueden aparecer las entradas especiales all y ungrouped. Un host puede aparecer en más de una rama del gráfico y seguir siendo un único host del inventario.
Un patrón de hosts selecciona los destinos de un comando. Previsualiza el grupo padre sin ejecutar un módulo:
ansible webservers --list-hosts
Deberías obtener exactamente web1 y web2. En un patrón, :& significa intersección: selecciona los hosts que pertenecen a ambas partes. Entrecomíllalo para que la shell no interprete &:
ansible 'webservers:&canary' --list-hosts
Deberías obtener solo web1. Esta previsualización te permite detectar un error de selección antes de cambiar ningún host.
Limitar un cambio al host canary
En este paso, harás un pequeño cambio en el host canary mientras conservas el host stable y el controlador.
El primer patrón de un comando selecciona un conjunto inicial. --limit lo restringe aún más; no añade hosts ajenos a ese conjunto. Previsualiza una selección limitada antes de usarla:
ansible webservers --limit canary --list-hosts
Deberías obtener un host, web1. Un límite que no coincida con ningún host no demostraría un cambio correcto, aunque el comando termine sin un fallo del módulo.
Usa el módulo command del laboratorio anterior para ejecutar touch. Este comando de Linux crea un archivo vacío cuando no existe y actualiza su marca de tiempo si existe. El marcador debe estar en el directorio personal del usuario automation administrado. El valor entrecomillado de -a mantiene juntos el ejecutable y la ruta:
ansible webservers --limit canary -m ansible.builtin.command -a 'touch /home/automation/canary-ready'
Deberías obtener un resultado correcto del comando únicamente para web1. Esta acción es deliberadamente un ejercicio sencillo de alcance; touch puede actualizar las marcas de tiempo en ejecuciones repetidas, por lo que su estado CHANGED no demuestra idempotencia.
Inspecciona los archivos visibles del directorio personal de cada usuario administrado. ls enumera el directorio de cada destino porque lo ejecuta el módulo command de Ansible:
ansible webservers -m ansible.builtin.command -a 'ls /home/automation'
El resultado de web1 debería contener canary-ready. El resultado de web2 no debería contener ese nombre; su stdout puede estar vacío. Estos son directorios remotos, separados del espacio de trabajo de tu controlador.
Por último, inspecciona el directorio actual del controlador:
ls
Debería mostrar la configuración y el inventario del proyecto, sin un marcador canary-ready local. Has seleccionado un host administrado real en lugar de hacer un cambio en el controlador. En laboratorios posteriores usarás módulos que declaran directamente el estado de los archivos y después verifican la idempotencia.
Resumen
Has conservado dos identidades distintas del inventario, organizado hosts y grupos hijos, previsualizado un patrón de intersección entrecomillado y restringido un comando con --limit. El estado real de los destinos mostró el marcador únicamente en el host canary, mientras que el host stable y el controlador quedaron fuera del cambio.
