Introducción
Ansible puede estar instalado correctamente y, aun así, usar el inventario, el intérprete o los privilegios equivocados. Un proyecto fiable hace explícitas esas decisiones y confirma su efecto en destinos reales.
En este laboratorio, crearás una configuración del proyecto, inspeccionarás los valores cargados, establecerás Python de destino mediante el inventario y compararás la ejecución normal con la elevación explícita de privilegios en dos nodos SSH preparados. Este entorno independiente proporciona Ansible y las conexiones; no hace falta instalar paquetes ni cambiar el servidor SSH.
Crear y cargar la configuración del proyecto
En este paso, crearás una configuración del proyecto y confirmarás que Ansible realmente la carga.
Ya instalaste Ansible en el laboratorio anterior. Este entorno independiente proporciona la instalación compartida del curso para que puedas centrarte en la configuración. Abre el Terminal y selecciona el espacio de trabajo:
cd /home/labex/project
Ansible usa un único archivo de configuración: el primero disponible entre ANSIBLE_CONFIG, el ansible.cfg del directorio actual, la configuración del directorio personal del usuario y la configuración del sistema. Por tanto, cambiar de directorio puede cambiar qué configuración del proyecto se carga. Una variable de entorno puede seleccionar otro archivo incluso cuando existe un archivo del proyecto.
El archivo preparado connection-reference.cfg contiene los ajustes de conexión originales de formación. cat lo muestra:
cat connection-reference.cfg
Selecciona el inventario del proyecto y un archivo de claves de host de confianza. El laboratorio ya ha creado las claves y los nodos; no cambies tu inicio de sesión en la plataforma ni el servidor SSH.
Crea el siguiente ansible.cfg. cat > escribe la entrada estándar en un archivo, sustituyendo el contenido existente. <<'EOF' inicia un documento insertado: pega todas las líneas hasta el EOF final incluido. Las comillas del delimitador mantienen el texto literal. Los nombres de sección INI entre corchetes agrupan ajustes, y cada línea name = value establece una opción.
cat > ansible.cfg <<'EOF'
[defaults]
inventory = /home/labex/project/inventory.ini
host_key_checking = True
interpreter_python = /usr/bin/python3
[privilege_escalation]
become = False
[ssh_connection]
ssh_args = -o UserKnownHostsFile=/home/labex/.local/share/ansible-course/known_hosts -o StrictHostKeyChecking=yes -o ControlMaster=auto -o ControlPersist=30s
EOF
inventory selecciona la lista de hosts. host_key_checking mantiene activadas las comprobaciones de identidad del servidor. interpreter_python establece el Python de destino predeterminado, no el intérprete del controlador. become = False mantiene las tareas normales sin privilegios elevados. Los ssh_args preparados usan el archivo known_hosts de formación, exigen claves de confianza y reutilizan conexiones SSH de corta duración.
Muestra la información de versión y configuración:
ansible --version
Busca config file = /home/labex/project/ansible.cfg. En este laboratorio, la ruta del módulo pertenece a la instalación compartida del curso; el ejercicio de instalación anterior usó un entorno independiente del alumno.
ansible-config dump muestra la configuración efectiva. --only-changed la limita a los ajustes no predeterminados e identifica de dónde procede cada uno:
ansible-config dump --only-changed
Busca CONFIG_FILE() = /home/labex/project/ansible.cfg, un DEFAULT_HOST_LIST del proyecto e INTERPRETER_PYTHON establecido en /usr/bin/python3. La salida usa nombres internos de opciones que pueden diferir de su escritura en INI. Leer un archivo por sí solo no demuestra que Ansible lo haya cargado.
Prueba la configuración del proyecto con el módulo ping de Python que ya conoces:
ansible all -m ansible.builtin.ping
Tanto web1 como web2 deberían devolver pong. Ejecuta los comandos en este espacio de trabajo para que siga activa la configuración prevista.
Establecer el intérprete de destino en el inventario
En este paso, establecerás una variable de conexión para ambos hosts y comprenderás su relación con el valor predeterminado del proyecto.
Lee el inventario preparado:
cat inventory.ini
Contiene dos destinos ansible_host distintos seguidos de [all:vars]. Los ajustes posteriores a esa sección se aplican a ambos hosts, incluidos ansible_user=automation y la ruta de la clave privada de formación. Describen la cuenta SSH y la autenticación en los nodos administrados.
Una variable de conexión llamada ansible_python_interpreter tiene prioridad sobre el valor predeterminado de configuración interpreter_python para sus hosts. Úsala cuando un inventario necesite un intérprete de destino específico. Un valor predeterminado correcto no puede compensar una variable del inventario que apunte a un ejecutable inexistente.
printf imprime texto; \n significa un salto de línea. >> añade contenido sin sustituir el inventario existente. Añade la variable del intérprete bajo la sección [all:vars] existente:
printf '\nansible_python_interpreter=/usr/bin/python3\n' >> inventory.ini
Muestra otra vez el inventario y busca el nuevo ajuste debajo de [all:vars]:
cat inventory.ini
La instalación de Python del controlador permanece sin cambios. Esta ruta se ejecutará por separado dentro de cada nodo administrado. Prueba ambos destinos:
ansible all -m ansible.builtin.ping
Cada uno debería seguir devolviendo pong y changed: false. Ahora tienes un ajuste de intérprete funcional por inventario, además de un valor predeterminado del proyecto. La salida de configuración describe valores predeterminados; las variables de conexión pueden tener prioridad sobre ellos durante la ejecución.
Comparar la ejecución normal y con privilegios elevados
En este paso, observarás el usuario remoto real antes y después de una elevación explícita de privilegios.
El módulo command ejecuta un programa en el destino. -a proporciona argumentos del módulo; entrecomilla id -un para que la shell pase el programa y su opción como una única cadena de argumentos. id -un imprime el nombre del usuario efectivo:
ansible all -m ansible.builtin.command -a 'id -un'
Ambos hosts deberían informar automation. Esta es la cuenta del nodo administrado seleccionada por el inventario, no el usuario labex del controlador.
--become solicita una elevación de privilegios para esta invocación. Los nodos de formación permiten a la cuenta automation usar sudo sin contraseña; el valor predeterminado del proyecto sigue manteniendo desactivada la elevación para las ejecuciones normales:
ansible all -m ansible.builtin.command -a 'id -un' --become
Ambos hosts deberían informar root. El módulo command de Ansible normalmente informa CHANGED cuando ejecuta un comando, incluso para esta consulta de identidad de solo lectura. Esa etiqueta por sí sola no demuestra que haya cambiado una configuración del sistema; interpreta la salida stdout real y el estado de retorno.
Repite sin --become:
ansible all -m ansible.builtin.command -a 'id -un'
La salida vuelve a ser automation. La elevación fue explícita para una invocación, en lugar de un cambio permanente de la cuenta de inicio de sesión. Deja desactivada la elevación global y mantén sin cambios la configuración de cuentas de la plataforma.
Resumen
Has creado y cargado una configuración del proyecto, inspeccionado los valores predeterminados efectivos y proporcionado un intérprete de destino de mayor prioridad mediante el inventario. La ejecución real de módulos por SSH confirmó ambos destinos, y las consultas de identidad demostraron la diferencia entre el acceso normal de automation y el uso explícito de become. Estas comprobaciones proporcionan una base para diagnosticar los ajustes de conexión sin cambiar el acceso a la plataforma.
