El libro de jugadas interior. Funciones de red en el nuevo Ansible Engine 2.9

El próximo lanzamiento de Red Hat Ansible Engine 2.9 te espera con mejoras impresionantes, algunas de las cuales se describen en este artículo. Como de costumbre, desarrollamos mejoras de Ansible Network abiertamente, con el apoyo de la comunidad. Únase: eche un vistazo al panel de tareas en GitHub y estudie el plan de desarrollo para el lanzamiento de Red Hat Ansible Engine 2.9 en la página wiki de Ansible Network .

Como anunciamos recientemente, Red Hat Ansible Automation Platform ahora incluye Ansible Tower, Ansible Engine y todo el contenido de Ansible Network. Ahora, las plataformas de red más populares se implementan a través de módulos Ansible. Por ejemplo:

• Arista eos
• Cisco IOS
• Cisco IOS XR
• Cisco NX-OS
• Juniper Junos
• Vyos

Una lista completa de plataformas que son totalmente compatibles con Red Hat a través de Ansible Automation está disponible aquí .

Que hemos aprendido

En los últimos cuatro años, hemos aprendido mucho sobre el desarrollo de una plataforma para la automatización de redes. También aprendimos cómo los usuarios finales juegan artefactos de plataforma en libros de jugadas y roles de Ansible. Y aquí está lo que descubrimos:

• Las organizaciones automatizan dispositivos no solo uno, sino muchos proveedores.
• La automatización no es solo un fenómeno técnico, sino también cultural.
• La automatización de redes a gran escala es más complicada de lo que parece, debido a los principios arquitectónicos fundamentales del diseño de automatización.

Cuando discutimos nuestros planes de desarrollo a largo plazo hace más de un año, nuestros clientes corporativos solicitaron lo siguiente:

• La recopilación de datos debe estar mejor estandarizada y alineada con el flujo de trabajo de automatización para cualquier dispositivo.
• La actualización de las configuraciones en el dispositivo también debe estandarizarse y armonizarse para que los módulos Ansible procesen la segunda mitad del ciclo después de recopilar los datos.
• Necesitamos métodos rigurosos y compatibles para convertir la configuración del dispositivo en datos estructurados. Sobre esta base, la fuente de la verdad se puede mover desde un dispositivo de red.

Mejoras de hecho

La recopilación de datos de dispositivos de red que usan Ansible a menudo es aleatoria. Las plataformas de red están equipadas en diversos grados con la capacidad de recopilar datos, pero casi no tienen, o incluso ninguna, funciones para analizar y estandarizar la presentación de datos en pares clave-valor. Lea la publicación de Ken Celenza sobre lo difícil y doloroso que es analizar y estandarizar datos reales.

Es posible que haya notado cómo trabajamos en el rol de Ansible Network Engine. Naturalmente, 24,000 descargas después, el rol de Network Engine se convirtió rápidamente en uno de los roles más populares de Ansible en Ansible Galaxy para escenarios de automatización de redes. Antes de trasladar gran parte de esto a Ansible 2.8, para prepararnos para lo que Ansible 2.9 necesitaba, este rol de Ansible proporcionó el primer conjunto de herramientas para ayudar en el análisis de comandos, la administración de comandos y la recopilación de datos para dispositivos de red.

Si es bueno en el uso de Network Engine, esta es una forma muy eficiente de recopilar, analizar y estandarizar datos de hechos para usar con Ansible. La desventaja de este rol es que necesita crear un montón de analizadores para cada plataforma y para toda la actividad de la red. Para comprender lo difícil que es crear, enviar y mantener analizadores, mire los más de 1200 analizadores de los muchachos de Cisco.

En pocas palabras, para la automatización a gran escala es muy importante recibir datos de los dispositivos y normalizarlos en pares clave-valor, pero esto es difícil de lograr cuando se tienen muchos proveedores y plataformas de red.

Cada módulo de hechos de red en Ansible 2.9 ahora puede analizar la configuración de un dispositivo de red y devolver datos estructurados, sin bibliotecas adicionales, roles de Ansible o analizadores personalizados.

Comenzando con Ansible 2.9, con cada versión del módulo de red actualizado, el módulo de hechos se mejora para proporcionar información sobre esta sección de configuración. Es decir, el desarrollo de hechos y módulos ahora está sucediendo al mismo ritmo, y siempre tendrán una estructura de datos común.

La configuración de recursos en un dispositivo de red se puede extraer y convertir en datos estructurados de dos maneras. En ambos sentidos, puede compilar y convertir una lista específica de recursos utilizando la nueva gather_network_resources . Los nombres de los recursos corresponden a los nombres de los módulos, y esto es muy conveniente.

A la hora de recopilar los hechos:

Con la gather_facts puede extraer la configuración actual del dispositivo al principio del libro de jugadas y luego usarla en todo el libro de jugadas. Especifique los recursos individuales para recuperar del dispositivo.

 - hosts: arista module_defaults: eos_facts: gather_subset: min gather_network_resources: - interfaces gather_facts: True 

Puede notar algo nuevo en estos ejemplos, a saber, gather_facts: true ahora gather_facts: true disponible para la búsqueda de datos nativa para dispositivos de red.

Usando el módulo de datos de red directamente:

 - name: collect interface configuration facts eos_facts: gather_subset: min gather_network_resources: - interfaces 

El libro de jugadas devuelve los siguientes datos sobre la interfaz:

 ansible_facts: ansible_network_resources: interfaces: - enabled: true name: Ethernet1 mtu: '1476' - enabled: true name: Loopback0 - enabled: true name: Loopback1 - enabled: true mtu: '1476' name: Tunnel0 - enabled: true name: Ethernet1 - enabled: true name: Tunnel1 - enabled: true name: Ethernet1 

Observe cómo Ansible recupera la configuración nativa del dispositivo Arista y la convierte en datos estructurados para usar como pares clave-valor estándar para tareas y operaciones posteriores.

Los datos de la interfaz pueden agregarse a las variables almacenadas de Ansible y usarse inmediatamente o más tarde como entrada al eos_interfaces recursos eos_interfaces sin procesamiento o conversión adicional.

Módulos de recursos

Entonces, extrajimos los hechos, normalizamos los datos, los ingresamos en un esquema interno estandarizado de la estructura de datos y obtuvimos una fuente de verdad. ¡Hurra! Esto, por supuesto, es excelente, pero aún necesitamos convertir de alguna manera los pares clave-valor a la configuración específica que una plataforma de dispositivo específica espera. Ahora necesitamos módulos para plataformas específicas para satisfacer estos nuevos requisitos de recopilación y normalización de hechos.

¿Qué es un módulo de recursos? Las secciones de configuración del dispositivo pueden considerarse como los recursos proporcionados por este dispositivo. Los módulos de recursos de red se limitan intencionalmente a un recurso, y se pueden apilar como ladrillos para configurar servicios de red complejos. Como resultado, los requisitos y especificaciones para el módulo de recursos se simplifican naturalmente, porque el módulo de recursos puede leer y configurar un servicio de red específico en un dispositivo de red.

Para explicar lo que hace el módulo de recursos, veamos un ejemplo de un libro de jugadas que muestra una operación idempoent usando nuevos hechos de un recurso de red y el módulo eos_l3_interface .

 - name: example of facts being pushed right back to device. hosts: arista gather_facts: false tasks: - name: grab arista eos facts eos_facts: gather_subset: min gather_network_resources: l3_interfaces - name: ensure that the IP address information is accurate eos_l3_interfaces: config: "{{ ansible_network_resources['l3_interfaces'] }}" register: result - name: ensure config did not change assert: that: not result.changed 

Como puede ver, los datos recopilados del dispositivo se transfieren directamente al módulo de recursos correspondiente sin conversión. Al inicio, el libro de jugadas recupera los valores del dispositivo y los compara con los esperados. En este ejemplo, los valores obtenidos corresponden a los esperados (es decir, se verifican las desviaciones de configuración) y se muestra un mensaje si la configuración ha cambiado.

Una forma ideal de detectar desviaciones de configuración es almacenar los hechos en variables almacenadas de Ansible y usarlas periódicamente con el módulo de recursos en modo de verificación. Este es un método simple para ver si alguien ha cambiado los valores manualmente. En la mayoría de los casos, las organizaciones permiten cambios y configuraciones manuales, aunque muchas operaciones se realizan a través de Ansible Automation.

¿En qué se diferencian los nuevos módulos de recursos de los anteriores?

Para un ingeniero de automatización de redes, existen 3 diferencias principales entre los módulos de recursos en Ansible 2.9 de las versiones anteriores.

1) Para un recurso de red específico (que también puede considerarse como una sección de configuración), los módulos y los hechos se desarrollarán en todos los sistemas operativos de red compatibles al mismo tiempo. Creemos que si Ansible admite la configuración de recursos en una única plataforma de red, deberíamos admitirlo en todas partes. Esto simplifica el uso de módulos de recursos, porque un ingeniero de automatización de redes ahora puede configurar un recurso (por ejemplo, LLDP) en todos los sistemas operativos de red con módulos nativos y compatibles.

2) Los módulos de recursos ahora incluyen un valor de estado.

• merged : la configuración se fusiona con la configuración provista (predeterminada);
• replaced : la configuración del recurso será reemplazada por la configuración provista;
• overridden : la configuración del recurso se reemplazará con la configuración proporcionada; las instancias de exceso de recursos se eliminarán;
• deleted : la configuración del recurso se eliminará / restaurará de forma predeterminada.

3) Los módulos de recursos ahora incluyen valores de retorno estables. Cuando el módulo de recursos de red ha realizado (o sugerido) los cambios necesarios en el dispositivo de red, devuelve los mismos pares clave-valor al libro de jugadas.

• before : configuración en el dispositivo en forma de datos estructurados antes de la tarea;
• after : si el dispositivo ha cambiado (o puede cambiar si se usa el modo de verificación), la configuración resultante se devolverá en forma de datos estructurados;
• commands : cualquier comando de configuración que se ejecute en el dispositivo para llevarlo al estado deseado.

¿Qué significa todo esto? ¿Por qué es esto importante?

Esta publicación describe muchos conceptos complejos, pero esperamos que al final comprenda mejor que los clientes corporativos solicitan datos, normalización de datos y configuración de bucles para la plataforma de automatización. Pero, ¿por qué necesitan estas mejoras? Muchas organizaciones ahora se dedican a la transformación digital para hacer que sus entornos de TI sean más flexibles y competitivos. Para bien o para mal, muchos ingenieros de redes se convierten en desarrolladores de redes, ya sea por su propio interés o por orden de los gerentes.

Las organizaciones entienden que la automatización de plantillas de red individuales no resuelve el problema de fragmentación y solo aumenta la eficiencia hasta cierto límite. La plataforma de automatización de Red Hat Ansible proporciona modelos de datos de recursos rigurosos y normativos para administrar mediante programación los datos subyacentes en un dispositivo de red. Es decir, los usuarios están abandonando gradualmente los métodos de configuración individuales en favor de métodos más modernos con énfasis en las tecnologías (por ejemplo, direcciones IP, VLAN, LLDP, etc.), y no en la implementación de un proveedor específico.

¿Significa esto que los días de módulos de comando y configuraciones confiables y probados están contados? De ninguna manera Los módulos de recursos de red esperados no serán aplicables en todos los casos y no para cada proveedor, por lo que los ingenieros de red aún necesitarán módulos de comando y configuración para ciertas implementaciones. El propósito de los módulos de recursos es simplificar grandes plantillas Jinja y normalizar configuraciones de dispositivos no estructurados en un formato JSON estructurado. Con los módulos de recursos, será más fácil para las redes existentes transformar su configuración en pares clave-valor estructurados que serán una fuente de verdad fácil de leer. Si utiliza pares estructurados de clave-valor, puede cambiar de configuraciones en ejecución en cada dispositivo a trabajar con datos estructurados independientes y llevar las redes a la vanguardia con el enfoque de "infraestructura como código".

¿Qué módulos de recursos aparecerán en Ansible Engine 2.9?

Antes de contar en detalle lo que sucederá en Ansible 2.9, recordemos cómo dividimos la cantidad total de trabajo.

Identificamos 7 categorías y cada una asignó recursos de red específicos:

Nota: se planearon e implementaron recursos audaces en Ansible 2.9.
Según los comentarios de los clientes corporativos y la comunidad, era lógico tratar primero con los módulos relacionados con protocolos de topología de red, virtualización e interfaces.
Los siguientes módulos de recursos son desarrollados por el equipo de Ansible Network y corresponden a las plataformas que admite Red Hat:

Los siguientes módulos son desarrollados por la comunidad Ansible:

• exos_lldp_global - de Extreme Networks.
• nxos_bfd_interfaces - de Cisco
• nxos_telemetry - de Cisco

Como puede ver, el concepto de módulos de recursos se ajusta a nuestra estrategia de orientación de plataforma. Es decir, incluimos las capacidades y funciones necesarias en Ansible, con el fin de apoyar la estandarización en el desarrollo de módulos de red, y también para simplificar el trabajo de los usuarios a nivel de roles y libros de jugadas de Ansible. Para expandir el desarrollo de los módulos de recursos, el equipo de Ansible lanzó la herramienta Module Builder.

Planes para Ansible 2.10 en adelante

Después del lanzamiento de Ansible 2.9, trataremos con el siguiente conjunto de módulos de recursos para Ansible 2.10, que se pueden utilizar para configurar aún más la topología y la política de red, por ejemplo, ACL, OSPF y BGP . El plan de desarrollo aún se puede ajustar, así que si tiene comentarios, infórmelo a la comunidad de Ansible Network .

Recursos y primeros pasos

Comunicado de prensa de la plataforma de automatización Ansible
Blog de plataforma de automatización Ansible
El futuro de la entrega de contenido en Ansible
Reflexiones sobre cómo cambiar la estructura del proyecto Ansible