• Ejemplo de secuencia de comandos de inventario: zapatero

  • Ejemplo de script de inventario: OpenStack

    • Uso explícito del script de inventario de OpenStack
    • Uso implícito del script de inventario de OpenStack
    • Actualizar la caché
  • Otros scripts de inventario
  • Usar directorios de inventario y múltiples fuentes de inventario
  • Grupos estáticos de grupos dinámicos

Si su inventario de Ansible fluctúa con el tiempo, con hosts girando y cerrándose en respuesta a las demandas comerciales, las soluciones de inventario estático descritas en Cómo construir su inventario no satisfará sus necesidades. Es posible que deba realizar un seguimiento de los hosts de varias fuentes: proveedores de nube, LDAP, Zapateroy / o sistemas CMDB empresariales.

Ansible integra todas estas opciones a través de un sistema de inventario externo dinámico. Ansible admite dos formas de conectarse con el inventario externo: Complementos de inventario y inventory scripts.

Los complementos de inventario aprovechan las actualizaciones más recientes del código central de Ansible. Recomendamos complementos en lugar de scripts para inventario dinámico. Usted puede escribe tu propio complemento para conectarse a fuentes de inventario dinámicas adicionales.

Aún puede usar scripts de inventario si lo desea. Cuando implementamos complementos de inventario, garantizamos la compatibilidad con versiones anteriores a través del complemento de inventario de scripts. Los ejemplos siguientes ilustran cómo utilizar los scripts de inventario.

Si prefiere una GUI para manejar el inventario dinámico, el Torre Ansible de Red Hat La base de datos de inventario se sincroniza con todas sus fuentes de inventario dinámicas, proporciona acceso web y REST a los resultados y ofrece un editor gráfico de inventario. Con un registro de la base de datos de todos sus hosts, puede correlacionar el historial de eventos pasados ​​y ver qué hosts han tenido fallas en sus últimas ejecuciones del libro de jugadas.

Ejemplo de secuencia de comandos de inventario: zapatero

Ansible se integra perfectamente con Zapatero, un servidor de instalación de Linux escrito originalmente por Michael DeHaan y ahora dirigido por James Cammarata, que trabaja para Ansible.

Si bien se usa principalmente para iniciar instalaciones de SO y administrar DHCP y DNS, Cobbler tiene una capa genérica que puede representar datos para múltiples sistemas de administración de configuración (incluso al mismo tiempo) y servir como una ‘CMDB liviana’.

Para vincular su inventario de Ansible a Cobbler, copie este guión para /etc/ansible y chmod +x el archivo. Correr cobblerd cada vez que utilice Ansible y utilice el -i opción de línea de comando (por ejemplo, -i /etc/ansible/cobbler.py) para comunicarse con Cobbler utilizando la API XMLRPC de Cobbler.

Agrega un cobbler.ini presentar en /etc/ansible para que Ansible sepa dónde está el servidor Cobbler y se pueden utilizar algunas mejoras de caché. Por ejemplo:

[cobbler]

# Set Cobbler's hostname or IP address
host = http://127.0.0.1/cobbler_api

# API calls to Cobbler can be slow. For this reason, we cache the results of an API
# call. Set this to the path you want cache files to be written to. Two files
# will be written to this directory:
#   - ansible-cobbler.cache
#   - ansible-cobbler.index

cache_path = /tmp

# The number of seconds a cache file is considered valid. After this many
# seconds, a new API call will be made, and the cache file will be updated.

cache_max_age = 900

Primero pruebe el script ejecutando /etc/ansible/cobbler.py directamente. Debería ver una salida de datos JSON, pero es posible que todavía no contenga nada.

Exploremos qué hace esto. En Cobbler, asuma un escenario parecido al siguiente:

cobbler profile add --name=webserver --distro=CentOS6-x86_64
cobbler profile edit --name=webserver --mgmt-classes="webserver" --ksmeta="a=2 b=3"
cobbler system edit --name=foo --dns-name="foo.example.com" --mgmt-classes="atlanta" --ksmeta="c=4"
cobbler system edit --name=bar --dns-name="bar.example.com" --mgmt-classes="atlanta" --ksmeta="c=5"

En el ejemplo anterior, el sistema ‘foo.example.com’ es direccionable por ansible directamente, pero también es direccionable cuando se utilizan los nombres de grupo ‘webserver’ o ‘atlanta’. Dado que Ansible usa SSH, contacta al sistema foo a través de ‘foo.example.com’, solo, nunca solo a ‘foo’. De manera similar, si probara “ansible foo”, no encontraría el sistema … pero “ansible ‘foo *'” lo haría, porque el nombre DNS del sistema comienza con ‘foo’.

La secuencia de comandos proporciona más información que el anfitrión y el grupo. Además, como beneficio adicional, cuando se ejecuta el módulo de ‘configuración’ (lo que ocurre automáticamente cuando se usan los libros de jugadas), las variables ‘a’, ‘b’ y ‘c’ se completarán automáticamente en las plantillas:

# file: /srv/motd.j2
Welcome, I am templated with a value of a= a , b= b , and c= c

Que podría ejecutarse así:

ansible webserver -m setup
ansible webserver -m template -a "src=/tmp/motd.j2 dest=/etc/motd"

Nota

El nombre ‘servidor web’ vino de Cobbler, al igual que las variables para el archivo de configuración. Aún puede pasar sus propias variables como es normal en Ansible, pero las variables del script de inventario externo anularán cualquiera que tenga el mismo nombre.

Entonces, con la plantilla de arriba (motd.j2), esto da como resultado que los siguientes datos se escriban en /etc/motd para el sistema ‘foo’:

Welcome, I am templated with a value of a=2, b=3, and c=4

Y en la ‘barra’ del sistema (bar.example.com):

Welcome, I am templated with a value of a=2, b=3, and c=5

Y técnicamente, aunque no hay una buena razón importante para hacerlo, esto también funciona:

ansible webserver -m ansible.builtin.shell -a "echo  a "

Entonces, en otras palabras, también puede usar esas variables en argumentos / acciones.

Ejemplo de script de inventario: OpenStack

Si usa una nube basada en OpenStack, en lugar de mantener manualmente su propio archivo de inventario, puede usar el openstack_inventory.py Inventario dinámico para extraer información sobre sus instancias informáticas directamente desde OpenStack.

Puede descargar la última versión del script de inventario de OpenStack aquí.

Puede utilizar el script de inventario de forma explícita (pasando el -i openstack_inventory.py argumento a Ansible) o implícitamente (colocando el guión en /etc/ansible/hosts).

Uso explícito del script de inventario de OpenStack

Descargue la última versión del script de inventario dinámico de OpenStack y conviértalo en ejecutable:

wget https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack_inventory.py
chmod +x openstack_inventory.py

Nota

No le pongas nombre openstack.py. Este nombre entrará en conflicto con las importaciones de openstacksdk.

Obtenga un archivo OpenStack RC:

source openstack.rc

Nota

Un archivo OpenStack RC contiene las variables de entorno requeridas por las herramientas del cliente para establecer una conexión con el proveedor de la nube, como la URL de autenticación, el nombre de usuario, la contraseña y el nombre de la región. Para obtener más información sobre cómo descargar, crear u obtener un archivo OpenStack RC, consulte Establecer variables de entorno utilizando el archivo OpenStack RC.

Puede confirmar que el archivo se ha obtenido correctamente ejecutando un comando simple, como nova list y asegurándose de que no devuelva errores.

Nota

Los clientes de la línea de comandos de OpenStack deben ejecutar el nova list mando. Para obtener más información sobre cómo instalarlos, consulte Instale los clientes de línea de comandos de OpenStack.

Puede probar el script de inventario dinámico de OpenStack manualmente para confirmar que funciona como se esperaba:

./openstack_inventory.py --list

Después de unos momentos, debería ver un resultado JSON con información sobre sus instancias de procesamiento.

Una vez que confirme que el script de inventario dinámico está funcionando como se esperaba, puede decirle a Ansible que use el openstack_inventory.py script como un archivo de inventario, como se ilustra a continuación:

ansible -i openstack_inventory.py all -m ansible.builtin.ping

Uso implícito del script de inventario de OpenStack

Descargue la última versión del script de inventario dinámico de OpenStack, hágalo ejecutable y cópielo en /etc/ansible/hosts:

wget https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack_inventory.py
chmod +x openstack_inventory.py
sudo cp openstack_inventory.py /etc/ansible/hosts

Descargue el archivo de configuración de muestra, modifíquelo para adaptarlo a sus necesidades y cópielo en /etc/ansible/openstack.yml:

wget https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack.yml
vi openstack.yml
sudo cp openstack.yml /etc/ansible/

Puede probar el script de inventario dinámico de OpenStack manualmente para confirmar que funciona como se esperaba:

/etc/ansible/hosts --list

Después de unos momentos, debería ver un resultado JSON con información sobre sus instancias de procesamiento.

Actualizar la caché

Tenga en cuenta que el script de inventario dinámico de OpenStack almacenará en caché los resultados para evitar llamadas repetidas a la API. Para borrar explícitamente la caché, puede ejecutar el script openstack_inventory.py (o hosts) con el --refresh parámetro:

./openstack_inventory.py --refresh --list

Otros scripts de inventario

En Ansible 2.10 y versiones posteriores, los scripts de inventario se trasladaron a sus colecciones asociadas. Muchos están ahora en el directorio community.general scripts / Inventory. Le recomendamos que utilice Complementos de inventario en lugar de.

Usar directorios de inventario y múltiples fuentes de inventario

Si la ubicación dada a -i en Ansible es un directorio (o como está configurado en ansible.cfg), Ansible puede utilizar varias fuentes de inventario al mismo tiempo. Al hacerlo, es posible mezclar fuentes de inventario administradas dinámicamente y estáticamente en la misma ejecución ansible. ¡Nube híbrida instantánea!

En un directorio de inventario, los archivos ejecutables se tratan como fuentes de inventario dinámicas y la mayoría de los demás archivos como fuentes estáticas. Los archivos que terminan con cualquiera de los siguientes se ignoran:

~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo

Puede reemplazar esta lista con su propia selección configurando un inventory_ignore_extensions lista en ansible.cfg, o configurando el ANSIBLE_INVENTORY_IGNORE Variable ambiental. El valor en cualquier caso debe ser una lista de patrones separados por comas, como se muestra arriba.

Alguna group_vars y host_vars Los subdirectorios en un directorio de inventario se interpretan como se esperaba, lo que hace que los directorios de inventario sean una forma poderosa de organizar diferentes conjuntos de configuraciones. Ver Usando múltiples fuentes de inventario para más información.

Grupos estáticos de grupos dinámicos

Al definir grupos de grupos en el archivo de inventario estático, los grupos secundarios también deben definirse en el archivo de inventario estático; de lo contrario, ansible devuelve un error. Si desea definir un grupo estático de grupos secundarios dinámicos, defina los grupos dinámicos como vacíos en el archivo de inventario estático. Por ejemplo:

[tag_Name_staging_foo]

[tag_Name_staging_bar]

[staging:children]
tag_Name_staging_foo
tag_Name_staging_bar

Ver también

Cómo construir su inventario

Todo sobre archivos de inventario estático

Lista de correo

¿Preguntas? ¿Ayudar? Ideas? Pasa por la lista de Grupos de Google

irc.freenode.net

#ansible canal de chat de IRC