Introducción
Estás preparando un nodo de control de Ansible para administrar dos servidores Linux. Antes de escribir automatizaciones, necesitas una instalación predecible y pruebas de que el controlador puede ejecutar módulos Python en ambos destinos.
En este laboratorio, crearás un entorno virtual del proyecto, instalarás Ansible Core desde una caché de paquetes sin conexión, lo activarás en el Terminal y usarás un inventario proporcionado para probar dos conexiones SSH reales. Basta con tener conocimientos básicos de la línea de comandos; no se requiere experiencia previa con Ansible.
Crear un entorno aislado del controlador
En este paso, crearás el entorno Python que contendrá tu propia instalación de Ansible.
Ansible se ejecuta en un nodo de control y se conecta a nodos administrados mediante SSH. Tu Terminal de LabEx es el nodo de control Ubuntu. Dos contenedores Linux preparados, web1 y web2, actúan como nodos administrados separados: tienen distintas direcciones, nombres de host y sistemas de archivos, pero comparten el kernel de la máquina virtual. No necesitarás comandos de Docker ni cambios en la configuración de inicio de sesión de la plataforma.
Un entorno virtual de Python mantiene los paquetes del proyecto separados del sistema operativo y de las herramientas compartidas del curso. La imagen ya incluye un comando compartido de Ansible para la infraestructura, pero tu tarea consiste en instalar una copia independiente en /home/labex/project/.venv.
Abre el Terminal. Usa cd para seleccionar el directorio del proyecto; las rutas relativas posteriores se resuelven desde aquí:
cd /home/labex/project
pwd muestra tu directorio de trabajo actual:
pwd
La salida debería ser /home/labex/project. Sigue usando este directorio durante todo el laboratorio.
ansible-python selecciona el Python preparado para el curso. --version muestra su versión:
ansible-python --version
Deberías obtener Python 3.12.15. El Python del sistema del nodo de control permanece separado; no lo sustituyas.
La opción -m venv ejecuta el módulo de entornos virtuales de Python. El argumento final .venv nombra el directorio que se creará dentro del proyecto. Un punto inicial lo oculta en los listados normales de directorios:
ansible-python -m venv .venv
Normalmente termina sin mostrar salida. Crea el entorno y pip, el instalador de paquetes de Python; todavía no ha instalado Ansible.
Ejecuta el Python del nuevo entorno mediante su ruta relativa. Así confirmarás que puedes usar el intérprete aislado sin activarlo primero:
.venv/bin/python --version
También debería mostrar Python 3.12.15. Los dos comandos Python usan la misma versión de Python, pero los paquetes instalados en .venv pertenecen a este proyecto.
Instalar y activar Ansible sin conexión
En este paso, instalarás en .venv la versión fijada de Ansible Core y harás que el Terminal la utilice.
Ansible Core proporciona el comando ansible y los módulos integrados que se usan en este curso. Los archivos wheel preparados son paquetes Python locales, por lo que la instalación no depende de descargas de Internet. El archivo de requisitos especifica versiones compatibles y fijadas.
El siguiente comando usa el Python del proyecto para ejecutar pip. install instala paquetes, --no-index desactiva los índices de paquetes en línea, --find-links selecciona el directorio local de archivos wheel y -r lee el archivo de requisitos:
.venv/bin/python -m pip install --no-index --find-links /opt/labex/ansible-course/wheels -r /opt/labex/ansible-course/requirements.txt
La salida enumera los paquetes procesados desde la caché local y termina con Successfully installed ..., incluido ansible-core-2.21.5. Si repites la instalación, puede indicar Requirement already satisfied.
La activación coloca el directorio de comandos del entorno al principio de la ruta de búsqueda de esta shell. source ejecuta el script de activación en el Terminal actual, por lo que el cambio se mantiene para los comandos posteriores:
source .venv/bin/activate
Ahora el indicador puede comenzar con (.venv). El Terminal usa zsh; rehash actualiza las ubicaciones de comandos que tiene en caché después de instalar nuevos ejecutables:
rehash
command -v muestra qué ejecutable selecciona un nombre de comando:
command -v ansible
Deberías obtener /home/labex/project/.venv/bin/ansible. Una ruta compartida como /usr/local/bin/ansible no demuestra que la instalación del proyecto esté activa. Si abres un Terminal nuevo, vuelve al proyecto, activa de nuevo el entorno y ejecuta rehash.
Ahora inspecciona la versión de Ansible en ejecución:
ansible --version
Busca estos campos en la salida:
ansible [core 2.21.5]
config file = /home/labex/project/ansible.cfg
...
ansible python module location = /home/labex/project/.venv/lib/python3.12/site-packages/ansible
executable location = /home/labex/project/.venv/bin/ansible
python version = 3.12.15 ...
...
Las rutas del ejecutable y del módulo muestran que estás ejecutando la instalación del proyecto. El laboratorio proporciona el archivo de configuración; aprenderás a configurarlo en el siguiente grupo de competencias.
Por último, el comando check de pip comprueba si las dependencias de los paquetes instalados son compatibles:
.venv/bin/python -m pip check
Deberías obtener No broken requirements found. Ahora tienes un controlador funcional sin cambiar los paquetes del sistema ni las herramientas compartidas.
Conectar con ambos nodos administrados
En este paso, inspeccionarás el inventario preparado y ejecutarás una prueba de conexión basada en Python en ambos destinos SSH.
Un inventario indica a Ansible qué hosts puede administrar. cat muestra el contenido de un archivo; lee el inventario del proyecto proporcionado:
cat inventory.ini
Su estructura es:
web1 ansible_host=...
web2 ansible_host=...
[all:vars]
ansible_user=automation
ansible_ssh_private_key_file=/home/labex/.local/share/ansible-course/id_ed25519
ansible_python_interpreter=/usr/bin/python3
Las direcciones reales sustituyen a ...; usa los valores existentes. web1 y web2 son nombres del inventario, mientras que ansible_host proporciona cada destino SSH. [all:vars] aplica los ajustes de conexión siguientes a ambos hosts. automation es la cuenta normal dentro de los nodos administrados, no tu cuenta labex del nodo de control. El laboratorio proporciona una clave de formación nueva y claves de host de confianza; no necesitas generar claves ni cambiar los ajustes de SSH.
La ruta de Python de destino /usr/bin/python3 pertenece a cada nodo administrado. Es distinta del Python del proyecto del controlador: la mayoría de los módulos de Ansible necesitan Python tanto en el destino como en el controlador.
El archivo ansible.cfg proporcionado selecciona este inventario cuando los comandos se ejecutan desde el proyecto. all selecciona todos los hosts del inventario; --list-hosts permite previsualizar esa selección sin ejecutar un módulo:
ansible all --list-hosts
Deberías obtener exactamente estos dos nombres de host; el orden puede variar:
hosts (2):
web1
web2
La opción -m selecciona un módulo, una unidad de trabajo de Ansible. ansible.builtin.ping es el nombre completamente cualificado del módulo ping integrado. Se conecta mediante SSH y ejecuta Python en cada destino; no es un ping de red ICMP:
ansible all -m ansible.builtin.ping
Ambos hosts deberían devolver resultados con estos campos estables; el orden de los resultados puede variar:
web1 | SUCCESS => {
"changed": false,
"ping": "pong"
}
web2 | SUCCESS => {
"changed": false,
"ping": "pong"
}
Un pong demuestra que la autenticación SSH y la ejecución de Python en el destino funcionaron para ese host. changed: false significa que esta prueba de conexión no solicitó un cambio de configuración. Un solo host con éxito no basta: busca ambos nombres. UNREACHABLE significa que falló la conexión; FAILED significa que falló una tarea. Una lista de hosts vacía tampoco demuestra conectividad.
Si el comando falla, comprueba primero que sigues en el directorio del proyecto, que command -v ansible selecciona .venv/bin/ansible y que el inventario proporcionado todavía contiene ambos destinos originales. Mantén sin cambios la configuración de inicio de sesión, SSH y sudo de la plataforma.
Resumen
Has creado un entorno aislado del controlador, instalado paquetes de Ansible Core con versiones fijadas desde una caché sin conexión, activado los comandos del proyecto y comprobado sus rutas y dependencias. Has leído el inventario proporcionado y recibido un pong de Python de cada nodo distinto administrado por SSH. Ahora puedes distinguir el Python del controlador, el Python de los destinos y los nombres del inventario antes de aprender a configurar el proyecto.
