Cómo usar la nueva función de inventario construido en Ansible Automation Platform 2.4

La nueva función de inventario construido

En esta publicación de blog, presentamos la idea de una nueva forma más inteligente de manejar el inventario, la cual se basa en el plugin construido de Ansible. Ahora, la incorporamos como una función con soporte completo en Ansible Automation Platform 2.4, y la explicaremos en esta publicación. 

El inventario construido es el sucesor de la función actual Smart Inventory, y  ahora se presenta como otra opción a la hora de crear un inventario en el controlador de Ansible Automation Platform. Tomará una lista de inventarios "normales" como entrada, realizará operaciones definidas por el usuario, filtrará los datos y como resultado producirá un inventario con contenido de los inventarios de entrada.

¿Qué es el inventario construido?

La función es similar al inventario inteligente actual, ya que permite que los usuarios ejecuten tareas en los hosts de múltiples inventarios. 

Sin embargo, el inventario construido presenta nuevas funciones, incluida la capacidad integrada de definir y usar tanto hostvars como groupvars:

• Los grupos están presentes en el inventario construido y desempeñan un papel fundamental en su configuración.
• La lógica definida por el usuario (para agregar grupos, vars y host seleccionados) se ejecuta mediante el comando ansible-inventory, que el controlador realiza por ti, y se muestra en la interfaz de usuario como una actualización de inventario.
• El formato de la lógica definida por el usuario está en formato jinja2, muy utilizado en Ansible.

Uno de los principios rectores es que al crear un inventario construido, se debe pensar tal como cuando se escribe un playbook. Esto contrasta con el inventario inteligente, en el cual tenías que pensar en el inventario como lo veía la aplicación.

Inventario construido en la interfaz de usuario

Después de hacer clic en "Add constructed inventory" en Inventories, verás este menú:

Hay tres elementos clave exclusivos del inventario construido.

• Input inventories es donde enumerarás los inventarios actuales de los cuales el inventario construido obtendrá el contenido (hosts, grupos, etc.).
• Limit se pasa a ansible-inventory directamente y permite filtrar los hosts con la sintaxis estándar para los patrones de host de Ansible.
• Source vars es la entrada para el plugin del inventario ansible.builtin.constructed.

NOTA: Los inventarios de entrada se ordenan de modo que, en caso de que haya conflictos entre nombre de host y variable, tengan prioridad las variables del último inventario. Las variables se fusionan, por lo que esto no anulará una variable de un inventario de entrada anterior. Si no hay conflictos de nombre de hosts, esto no es relevante, por lo que en el ejemplo usado aquí se mencionará el orden.

No te preocupes por estos elementos en este momento, ya que se explorarán con un ejemplo más adelante.

Inventario construido en su forma más sencilla

Debes tener al menos un inventario de entrada, pero no es necesario completar los otros campos. En algunas situaciones, puede tener sentido proporcionar dos o más inventarios de entrada y dejar los campos limit y source-vars en blanco. Así, puedes ejecutar tareas que actúen en la combinación del contenido de ambos inventarios de entrada. 

Casos prácticos de inventario construido más avanzados

Para explicar el uso de Limit y Source vars, que permiten aprovechar al máximo la función, será útil tener un ejemplo concreto.

Configuración del inventario construido

Imagínate que tienes dos inventarios que vienen del mismo proveedor de nube, pero cubren diferentes regiones y, por lo tanto, tienen diferentes conjuntos de hosts. Estos inventarios se mantienen separados, ya que tienen cuentas, funciones y ubicaciones diferentes. En este ejemplo, utilizamos inventarios de entrada sencillos que corresponden cada uno a una región, East y West.

Obtendremos los inventarios de archivos .ini basados en Git, y los mantendremos según un enfoque de configuración como código con prácticas de DevOps.

Primero, configura un nuevo proyecto y sincronízalo para que sepamos de dónde obtener la información del inventario. Selecciona Projects en la interfaz de usuario y haz clic en Add:

Una vez que el proyecto se complete y guarde, se sincronizará automáticamente:

Ahora creamos los nuevos inventarios que harán referencia a la información de los archivos del proyecto. En "Inventories", haz clic en "Create":

Ahora, haz clic en Sources y en Add:

En Name, escribimos un nombre para la fuente, en este caso para los hosts de la región East, definimos la Source como Sourced from a Project, y proporcionamos el proyecto recién agregado y el archivo fuente east.ini correspondiente:

Una vez guardado, haz clic en el botón Sync para obtener la información:

Cuando se haya sincronizado, puedes consultar el resultado de la tarea para ver lo que se procesó:

En este caso, verás que se detectan y se agregan automáticamente 3 hosts y 3 grupos. Puedes ver esta información en la interfaz de usuario, en Hosts.

Ahora debemos hacer lo mismo para la región West. Dejaré que lo hagas tú siguiendo el ejemplo anterior, pero usando el archivo west.ini como fuente.

Para este escenario hipotético, nos gustaría ejecutar tareas en algunos de los hosts de las regiones East y West simultáneamente, según los criterios que definamos.

Así que ahora vamos a crear un nuevo inventario construido en la interfaz de usuario:

Agregamos ambos inventarios de nube como entradas. A continuación, usaremos source-vars para construir un nuevo grupo "target_group" y, luego, usaremos limit para filtrar ese grupo:

Una vez sincronizado, podrás ver lo que sucede a través del resultado de la tarea:

Ahora tenemos 4 grupos con 4 hosts, los cuales podrás explorar en Hosts y Groups en la interfaz de usuario para confirmar el resultado. Veamos los grupos para este ejemplo en particular:

Cuando se ejecutó la actualización del inventario construido, se copiaron los grupos "account_1234", "account_4321" y "accounts" de los inventarios de entrada en el inventario construido resultante. 

Además, vemos que el inventario construido también incluye el grupo "target_group", al cual nos referiremos en breve.

Si una plantilla de tareas usó este inventario construido para ejecutar una tarea, esta podría utilizar cualquiera de los grupos definidos.

Ahora, si haces referencia a los source-vars en el formulario del inventario construido, podrás encontrar la definición del nuevo grupo "target_group".

    plugin: constructed
    strict: true
    groups:
        target_group: account_alias | default("") == "product_dev"

El "target_group" no estaba presente en los inventarios originales East y West. El plugin del inventario construido lo creó cuando se produjo la actualización. 

En este caso, los hosts se agregan al grupo cuando la plantilla jinja2 {{ account_alias | default("") == "product_dev" }} se resuelve en un valor verdadero (como 1, "1" o True) para un host determinado. 

Durante la actualización, Ansible genera estas plantillas para que cada host en los inventarios de entrada realice estas evaluaciones. En caso de incluir inventarios de entrada más grandes, puede que lleve unos minutos completar la actualización. 

Los inventarios construidos se actualizarán automáticamente antes de que se ejecute una tarea de cualquier plantilla que los utilice, pero si las actualizaciones tardan demasiado, puedes reducir la frecuencia de las actualizaciones con la opción Update cache timeout de la configuración del inventario construido en la interfaz de usuario. Si estableces esta opción en un valor > 1, los resultados de la actualización del inventario construido durante esa cantidad de segundos se almacenarán en caché.

La plantilla jinja2 para crear "target_group" incluirá un host si, cuando inspecciones el host, la variable hostvar de "account_alias" existe y es igual a "product_dev". 

La sintaxis predeterminada "| default" resulta necesaria en caso de que la variable no esté definida para algunos hosts. 

La opción "strict: true" indica que si se hace referencia a una variable indefinida, se interrumpirá la actualización del inventario, de manera que es necesario establecer "| default". 

Se recomienda usar el uso de "|default" y el parámetro estricto, para forzarte a hacer explícito el caso no definido.

La creación de grupos puede ser útil para agregar grupos sobre la marcha para que los playbooks hagan referencia a ellos. ¿Por qué querrías hacerlo? A veces, es conveniente sintetizar los grupos de los hostvars, ya que con los grupos puedes realizar acciones que no puedes hacer con los hostvars, por ejemplo, usarlos en los patrones del host, como con Limit en este ejemplo. 

Observa todos los hosts producidos para nuestro inventario construido:

En este ejemplo, podemos ver que host3 en el inventario East y host5 en el inventario West no están incluidos. Esto se debe a que en los inventarios de entrada están en una cuenta diferente (account_4321), la cual tiene un "account_alias" que no coincide con nuestro valor "product_dev" especificado. Ten en cuenta que, aunque el grupo para account_4321 se importó al inventario construido, ningún host en ese grupo cumplió con nuestro requisito, por lo que el grupo importado está vacío en nuestro inventario construido.

La entrada de Source vars puede incluir variables del host, además de agregar grupos.

El repositorio de Github de Alan también contiene otro ejemplo que puede resultarte útil. En construct.yml, resolvemos el "estado" de un host y lo asignamos a una cantidad de grupos en función de si está apagado o forma parte de un entorno particular (de desarrollo). La fuente de información para este archivo .yml puede provenir de otros sistemas fuera de Ansible Automation Platform, y podemos usarla para llevar a cabo ejecuciones de automatización en subconjuntos de hosts sobre la marcha.

Sugerencias de depuración

Usemos el ejemplo anterior. Imaginemos que durante el desarrollo del inventario construido eliminas el valor límite y cambias el source-vars al siguiente contenido.

Esto ejecutará una plantilla similar de {{ account_alias | default(“”) }} y lo guardará en una variable denominada "efective_account_alias". Al dejar el valor limit en blanco, nos aseguraremos de obtener todos los hosts de los inventarios de entrada. Esto nos permitirá inspeccionar información detallada de los criterios de inclusión en los hosts individuales, como se muestra a continuación para el host3.

Aquí vemos que el valor de hostvar "efective_account_alias" es "sustaining" y no "product_dev". 

El plugin del inventario construido tiene varias opciones más que pueden ser muy útiles y efectivas. Consulta la documentación del plugin en https://docs.ansible.com/ansible/latest/collections/ansible/builtin/constructed_inventory.html para obtener más información.

También puedes encontrar algunos otros ejemplos en la guía del usuario en https://docs.ansible.com/automation-controller/4.4/html/userguide/inventories.html#ug-inventories-constructed.

Resumen:

Espero que hayas obtenido una idea del uso práctico del inventario construido en Ansible Automation Platform. 

Debido a que los conceptos fundamentales, como el patrón del host y el plugin del inventario construido, son conceptos generales de Ansible, los usuarios podrán agregar grupos y variables o incluir hosts en función de criterios arbitrariamente complejos.

Los beneficios incluyen:

• La posibilidad de crear grupos de forma dinámica a partir de varias fuentes de información
• La posibilidad de filtrar, analizar y limitar los hosts de varios inventarios, y de utilizarlos para ejecutar procesos automatizados
• La posibilidad de utilizar hostvars predefinidos al filtrar los datos
• La posibilidad de que varios equipos tengan su propio inventario y metadatos asociados con sus hosts, y estos se puedan utilizar desde un mismo lugar a través de Ansible Automation Platform