🥇The Inside Playbook. Funciones de red en el nuevo Ansible Engine 2.9

En la próxima versión de Red Hat Ansible Engine 2.9, encontrará mejoras impresionantes, algunas de las cuales se describen en este artículo. Como de costumbre, hemos desarrollado las mejoras de Ansible Network de manera abierta, con el apoyo de la comunidad. Únase a nosotros; eche un vistazo a la tabla de tareas en GitHub y explore el plan de desarrollo para la versión de Red Hat Ansible Engine 2.9 en la página wiki de Ansible Network.

Como anunciamos recientemente, la plataforma de automatización de Red Hat Ansible ahora incluye Ansible Tower, Ansible Engine y todo el contenido de Ansible Network. Actualmente, la mayoría de las plataformas de red populares se implementan a través de módulos de Ansible. Por ejemplo:

Arista EOS
Cisco IOS
Cisco IOS XR
Cisco NX-OS
Juniper Junos
VyOS

La lista completa de plataformas que están completamente soportadas por Red Hat a través de la suscripción de Ansible Automation se publica aquí.

Lo 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 hemos aprendido sobre cómo cómo se aplican los artefactos de la plataforma en los playbooks y roles de Ansible desde el lado de los usuarios finales. Y esto es lo que hemos descubierto:

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

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

La recopilación de hechos debe estandarizarse mejor y alinearse con el flujo de trabajo de automatización para cualquier dispositivo.
La actualización de configuraciones en un dispositivo también debe estandarizarse y alinearse, para que los módulos de Ansible manejen la segunda mitad del ciclo después de la recopilación de hechos.
Se necesitan métodos estrictos y mantenidos para convertir la configuración del dispositivo en datos estructurados. Sobre esta base, la fuente de verdad se podrá mover fuera del dispositivo de red.

Mejoras en la recopilación de hechos

La recopilación de hechos de dispositivos de red con Ansible a menudo se realiza al azar. Las plataformas de red están equipadas en diferentes grados con capacidades de recopilación de hechos, pero tienen poco o ninguna funcionalidad para analizar y estandarizar la representación de datos en pares clave-valor. Lea publicación a Ken Celenza sobre lo difícil y doloroso que puede ser analizar y estandarizar los datos de hechos.

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

Si está familiarizado con el uso de Network Engine, es una manera muy eficaz de recopilar, analizar y estandarizar datos de hechos para su uso en Ansible. La desventaja de este rol es que se debe crear una gran cantidad de analizadores para cada plataforma y para toda la actividad de red. Para entender lo difícil que es crear, distribuir y mantener analizadores, eche un vistazo a más de 1200 analizadores de los chicos de Cisco.

En pocas palabras, para la automatización a gran escala es muy importante obtener hechos de los dispositivos y normalizarlos en pares clave-valor, pero esto resulta complicado 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.

A partir de Ansible 2.9, cada vez que se lanza una versión actualizada del módulo de red, se mejora el módulo de hechos para proporcionar datos sobre esta sección de la configuración. Es decir, el desarrollo de hechos y módulos ahora avanza 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 transformar en datos estructurados de dos maneras. Ambas formas permiten recopilar y transformar una lista específica de recursos mediante la nueva palabra clave gather_network_resources. Los nombres de los recursos coinciden con los nombres de los módulos, lo cual es muy conveniente.

Durante la recopilación de hechos:

Con la palabra clave gather_facts se puede extraer la configuración actual del dispositivo al inicio del playbook, y luego utilizarla a lo largo de todo el playbook. Especifique los recursos individuales que deben extraerse del dispositivo.

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

Es posible que haya notado algo nuevo en estos ejemplos, a saber — gather_facts: true ahora disponible para la recopilación nativa de hechos para dispositivos de red.

Uso del módulo de hechos de red directamente:

- name: recopilar hechos de configuración de interfaces
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

El playbook devuelve los siguientes hechos 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 extrae la configuración nativa del dispositivo Arista y la convierte en datos estructurados, para utilizarlos como pares clave-valor estándar para tareas y operaciones posteriores.

Los hechos de la interfaz se pueden agregar a las variables almacenadas de Ansible y utilizarse de inmediato o más tarde como entrada para el módulo de recursos. eos_interfaces sin procesamiento o transformación adicional.

Módulos de recursos

Entonces, hemos extraído los hechos, normalizado los datos, los hemos incorporado a un esquema estandarizado de datos y tenemos una fuente de verdad lista. ¡Hurra! Esto es, por supuesto, genial, pero aún necesitamos alguna manera de transformar los pares clave-valor de nuevo a la configuración específica que espera la plataforma del dispositivo en particular. Ahora necesitamos módulos para plataformas específicas para satisfacer estos nuevos requisitos de recopilación de hechos y normalización.

¿Qué es un módulo de recursos? Las secciones de configuración del dispositivo se pueden considerar como recursos proporcionados por ese dispositivo. Los módulos de recursos de red están intencionadamente restringidos a un único recurso y se pueden apilar, como bloques, para configurar servicios de red complejos. Como resultado, los requisitos y la especificación para el módulo de recursos se simplifican naturalmente, ya que el módulo de recursos puede leer y configurar un servicio de red específico en el dispositivo de red.

Para explicar lo que hace un módulo de recursos, veamos un ejemplo de un playbook que muestra una operación idempotente utilizando los nuevos hechos de recursos de red y el módulo eos_l3_interface.

- nombre: ejemplo de hechos enviados directamente al dispositivo.
  hosts: arista
  gather_facts: false
  tasks:
  - nombre: obtener hechos de eos de arista
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

  - nombre: asegurar que la información de la dirección IP sea precisa
    eos_l3_interfaces:
      config: "{{ ansible_network_resources['l3_interfaces'] }}"
      register: result

  - nombre: asegurar que la configuración no haya cambiado
    assert:
      that: not result.changed

Como pueden ver, los datos recolectados del dispositivo se envían directamente al módulo de recursos correspondiente sin transformación. Al ejecutar el playbook, se extraen los valores del dispositivo y se comparan con los esperados. En este ejemplo, los valores obtenidos coinciden con los esperados (es decir, se realiza la verificación de desviaciones de configuración) y se informa si la configuración ha cambiado.

La forma ideal de detectar desviaciones en la configuración es almacenar los hechos en variables persistentes de Ansible y utilizarlas periódicamente junto con el módulo de recursos en modo de verificación. Este es un método sencillo 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.

¿Qué diferencia a los nuevos módulos de recursos de las versiones anteriores?

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

1) Para un recurso de red específico (que también se puede considerar como una sección de configuración), los módulos y hechos se desarrollarán en todos los sistemas operativos de red compatibles simultáneamente. Creemos que si Ansible admite la configuración del recurso en una plataforma de red, deberíamos admitirla en todas partes. Esto simplifica el uso de los módulos de recursos, porque el ingeniero de automatización de redes ahora puede configurar el 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.

fusionado: la configuración se ha fusionado con la configuración proporcionada (por defecto);
reemplazado: la configuración del recurso será reemplazada por la configuración proporcionada;
anulado: la configuración del recurso será reemplazada por la configuración proporcionada; instancias adicionales de recursos serán eliminadas;
deleted: la configuración del recurso será eliminada/restaurada por defecto.

3) Los módulos de recursos ahora incluyen valores de retorno estables. Cuando el módulo de recurso de red realiza (o propone) los cambios necesarios en el dispositivo de red, devuelve las mismas parejas clave-valor al playbook.

before: configuración en el dispositivo en forma de datos estructurados antes de la tarea;
después: si el dispositivo ha cambiado (o puede cambiarse, si se utiliza el modo de verificación), la configuración resultante se devolverá en forma de datos estructurados;
comandos: cualquier comando de configuración ejecutado en el dispositivo para llevarlo a su estado deseado.

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

Este artículo describe muchos conceptos complejos, pero esperamos que al final comprenda mejor lo que los clientes corporativos solicitan sobre la recopilación de hechos, normalización de datos y la configuración del ciclo para la plataforma de automatización. ¿Pero por qué necesitan estas mejoras? Actualmente, muchas organizaciones están llevando a cabo transformaciones digitales para hacer que sus entornos de TI sean más flexibles y competitivos. Sea bueno o malo, muchos ingenieros de redes se están convirtiendo en desarrolladores de redes, ya sea por interés propio o por mandato de los líderes.

Las organizaciones entienden que la automatización de plantillas de red individuales no resuelve el problema de la fragmentación y solo mejora la eficiencia hasta cierto límite. La plataforma Red Hat Ansible Automation Platform proporciona modelos de datos de recursos estrictos y normativos para gestionar programáticamente los datos subyacentes en el dispositivo de red. Es decir, los usuarios están dejando lentamente los métodos de configuración individuales a favor de métodos más modernos con un enfoque en tecnologías (por ejemplo, direcciones IP, VLAN, LLDP, etc.), en lugar de la implementación específica del proveedor.

¿Significa esto que los días de los módulos de comandos y configuraciones confiables han llegado a su fin? En absoluto. Los módulos de recursos de red previstos no se aplicarán en todos los casos ni para cada proveedor, por lo que los módulos de comandos y configuraciones seguirán siendo necesarios para ciertas implementaciones por parte de los ingenieros de red. El objetivo de los módulos de recursos es simplificar las grandes plantillas de Jinja y normalizar configuraciones no estructuradas de dispositivos en un formato estructurado JSON. Con los módulos de recursos, las redes existentes podrán transformar más fácilmente su configuración en pares clave-valor estructurados, que representarán una fuente de verdad fácil de leer. Al utilizar pares clave-valor estructurados, se puede pasar de ejecutar configuraciones en cada dispositivo a trabajar con datos estructurados independientes, poniendo a las redes en el centro del enfoque de 'infraestructura como código'.

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

Antes de entrar en detalles sobre lo que habrá en Ansible 2.9, recordemos cómo dividimos todo el volumen de trabajo.

Hemos identificado 7 categorías y asignado recursos de red específicos a cada una:

Nota: los recursos destacados en negrita fueron planificados e implementados en Ansible 2.9.
Basado en comentarios de clientes corporativos y de la comunidad, tenía sentido abordar primero aquellos módulos relacionados con los protocolos de la topología de la red, la virtualización y las interfaces.
Los siguientes módulos de recursos fueron desarrollados por el equipo de Ansible Network y son compatibles con las plataformas que soporta Red Hat:

Los siguientes módulos fueron desarrollados por la comunidad de Ansible:

exos_lldp_global — de Extreme Networks.
nxos_bfd_interfaces — de Cisco
nxos_telemetry — de Cisco

Como pueden ver, el concepto de módulos de recursos se alinea con nuestra estrategia de enfoque en plataformas. Es decir, incorporamos las capacidades y funciones necesarias directamente en Ansible para apoyar la estandarización en el desarrollo de módulos de red, así como para simplificar el trabajo de los usuarios en los niveles de roles y playbooks de Ansible. Para expandir el desarrollo de módulos de recursos, el equipo de Ansible lanzó la herramienta Module Builder.

Planes para Ansible 2.10 y más allá

Después del lanzamiento de Ansible 2.9, nos centraremos en el siguiente conjunto de módulos de recursos para Ansible 2.10, que se podrán utilizar para una mayor configuración de la topología y políticas de red, por ejemplo, ACL, OSPF y BGPEl plan de desarrollo aún se puede ajustar, así que, si tiene comentarios, hágalos saber en la comunidad de Ansible Network.