El próximo lanzamiento de Red Hat Ansible Engine 2.9 trae mejoras interesantes, algunas de las cuales se analizan en este artículo. Como siempre, hemos estado desarrollando mejoras de Ansible Network abiertamente, con el apoyo de la comunidad. Únase a nosotros - eche un vistazo y estudiar el plan de desarrollo para en la página wiki para .
Como anunciamos recientemente, ahora incluye Ansible Tower, Ansible Engine y todo el contenido de Ansible Network. Hoy en día, las plataformas de redes más populares se implementan a través de módulos Ansible. Por ejemplo:
- AristaEOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- enebro junos
- VyOS
Para obtener una lista completa de las plataformas totalmente compatibles con Red Hat a través de la suscripción a Ansible Automation, .
¿Qué hemos aprendido?
Durante los últimos cuatro años, hemos aprendido mucho sobre el desarrollo de una plataforma de automatización de redes. También aprendimos que cómo Los artefactos de la plataforma se utilizan en los manuales y roles de Ansible por parte de los usuarios finales. Y esto es lo que descubrimos:
- Las organizaciones están automatizando dispositivos no solo de uno, sino de muchos proveedores.
- La automatización no es sólo un fenómeno técnico, sino también cultural.
- Automatizar redes a escala es más difícil de lo que parece debido a los principios arquitectónicos fundamentales del diseño de automatización.
Cuando hablamos de nuestros planes de crecimiento a largo plazo hace más de un año, nuestros clientes corporativos pidieron lo siguiente:
- La recopilación de datos debe estar mejor estandarizada y alineada con los flujos de trabajo de automatización en todos los dispositivos.
- La actualización de las configuraciones en el dispositivo también debe ser estandarizada y consistente para que los módulos de Ansible manejen 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 trasladar desde el dispositivo de red.
Mejoras de hechos
La recopilación de datos de dispositivos de red que utilizan Ansible a menudo ocurre de forma aleatoria. Las plataformas basadas en web tienen distintos grados de capacidades de recopilación de datos, pero tienen poca o ninguna funcionalidad para analizar y estandarizar la representación de datos en pares clave-valor. Leer Ken Celenza sobre lo difícil y doloroso que puede ser analizar y estandarizar datos fácticos.
Es posible que haya notado que trabajamos en la función de Ansible Network Engine. Naturalmente, después de 24K descargas, la función Network Engine se ha convertido rápidamente en una de las funciones de Ansible más populares 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 sería necesario en Ansible 2.9, esta función de Ansible proporcionó el primer conjunto de herramientas para ayudar a analizar comandos, administrar comandos y recopilar datos para dispositivos de red.
Si sabe cómo utilizar Network Engine, esta es una forma muy eficaz de recopilar, analizar y estandarizar datos de hechos para su uso en Ansible. La desventaja de esta función es que necesita crear una gran cantidad 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, eche un vistazo a de los chicos de Cisco.
En pocas palabras, obtener datos de los dispositivos y normalizarlos en pares clave-valor es esencial para la automatización a escala, pero lograrlo es difícil cuando hay muchos proveedores y plataformas de red.
Cada módulo de datos 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 ni analizadores personalizados.
Desde Ansible 2.9, cada vez que se lanza un módulo de red actualizado, el módulo de hechos se mejora para proporcionar datos sobre esta sección de la configuración. Es decir, el desarrollo de hechos y módulos ahora ocurre 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 recuperar y convertir en datos estructurados de dos maneras. De ambas maneras, puedes recopilar y transformar una lista específica de recursos usando una nueva palabra clave. gather_network_resources. Los nombres de los recursos coinciden con los nombres de los módulos, lo cual es muy conveniente.
Mientras recopila datos:
Usando una palabra clave gather_facts puede recuperar la configuración actual del dispositivo al comienzo del libro de estrategias y luego usarla a lo largo de todo el libro de estrategias. Especifique los recursos individuales que se recuperarán del dispositivo.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueEs posible que haya notado algo nuevo en estos ejemplos, a saber: gather_facts: true ahora está disponible para la recopilación de datos nativos para dispositivos de red.
Usando el módulo de hechos de red directamente:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesEl 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: Ethernet1Observe cómo Ansible recupera la configuración nativa del dispositivo Arista y la transforma en datos estructurados para utilizarlos como pares clave-valor estándar para tareas y operaciones posteriores.
Los datos de la interfaz se pueden agregar a las variables almacenadas de Ansible y usarse inmediatamente o más tarde como entrada a un módulo de recursos. eos_interfaces sin procesamiento o conversión adicional.
Módulos de recursos
Entonces, extrajimos los hechos, normalizamos los datos, los ajustamos a un diagrama de estructura de datos interno estandarizado y recibimos una fuente de verdad ya preparada. ¡Hurra! Esto es genial, por supuesto, pero aún necesitamos convertir de alguna manera los pares clave-valor a la configuración específica que espera la plataforma del dispositivo específico. Ahora necesitamos módulos específicos de la plataforma para cumplir con estos nuevos requisitos de normalización y recopilación de datos.
¿Qué es un módulo de recursos? Puede pensar en las secciones de configuración de un dispositivo como recursos proporcionados por ese dispositivo. Los módulos de recursos de red se limitan intencionalmente a un único recurso y se pueden apilar como bloques de construcción para configurar servicios de red complejos. Como resultado, los requisitos y especificaciones para un módulo de recursos se simplifican naturalmente, ya que el módulo de recursos puede leer и configurar un servicio de red específico en un dispositivo de red.
Para explicar lo que hace un módulo de recursos, veamos un libro de jugadas de ejemplo que muestra una operación idempodente utilizando datos y módulos de recursos de red nuevos. 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.changedComo puede ver, los datos recopilados del dispositivo se transfieren directamente al módulo de recursos correspondiente sin conversión. Cuando se inicia, el libro de jugadas recupera valores del dispositivo y los compara con los esperados. En este ejemplo, los valores devueltos son los esperados (es decir, verifica si hay desviaciones de configuración) e informa si la configuración ha cambiado.
La forma ideal de detectar cambios en la configuración es almacenar datos en variables almacenadas de Ansible y usarlos periódicamente con el módulo de recursos en modo de inspecció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 manualmente, 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 tres diferencias principales entre los módulos de recursos de Ansible 3 y las versiones anteriores.
1) Para un recurso de red determinado (que también puede considerarse como una sección de configuración), los módulos y hechos evolucionarán en todos los sistemas operativos de red compatibles simultáneamente. Creemos que si Ansible admite la configuración de recursos en una plataforma de red, deberíamos admitirla 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 (como 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 proporcionada (predeterminada);replaced: La configuración del recurso será reemplazada por la configuración proporcionada;overridden: La configuración del recurso será reemplazada por la configuración proporcionada; se eliminarán las instancias de recursos innecesarias;deleted: La configuración del recurso se eliminará/restaurará a los valores predeterminados.
3) Los módulos de recursos ahora incluyen valores de retorno estables. Cuando el módulo de recursos de red ha realizado (o propuesto) los cambios necesarios en el dispositivo de red, devuelve los mismos pares clave-valor al libro de estrategias.
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 utiliza el modo de prueba), la configuración resultante se devolverá como datos estructurados;commands: Todos los comandos de configuración se ejecutan en el dispositivo para llevarlo al estado deseado.
¿Qúe significa todo esto? ¿Por qué es importante?
Esta publicación cubre muchos conceptos complejos, pero esperamos que al final comprenda mejor lo que los clientes empresariales solicitan en materia de recopilación de datos, normalización de datos y configuración de bucle para una plataforma de automatización. Pero ¿por qué necesitan estas mejoras? Muchas organizaciones ahora están buscando una transformación digital para hacer que sus entornos de TI sean más ágiles y competitivos. Para bien o para mal, muchos ingenieros de redes se convierten en desarrolladores de redes, ya sea por interés propio o por orden de la dirección.
Las organizaciones se están dando cuenta de que la automatización de plantillas de red individuales no resuelve el problema de los silos y solo aumenta la eficiencia hasta cierto punto. Red Hat Ansible Automation Platform proporciona modelos de datos de recursos rigurosos y normativos para gestionar 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 tecnologías (por ejemplo, direcciones IP, VLAN, LLDP, etc.), en lugar de una implementación de proveedor específica.
¿Significa esto que los días de configuración y módulos de comando confiables y probados están contados? En ningún caso. Los módulos de recursos de red esperados no serán aplicables en todos los casos ni para todos los proveedores, por lo que los ingenieros de red seguirán necesitando los módulos de comando y configuración para ciertas implementaciones. El propósito de los módulos de recursos es simplificar las plantillas grandes de Jinja y normalizar las 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 representen una fuente de verdad fácil de leer. Al utilizar pares clave-valor estructurados, puede pasar de ejecutar configuraciones en cada dispositivo a trabajar con datos estructurados independientes y llevar las redes a la vanguardia de un enfoque de infraestructura como código.
¿Qué módulos de recursos vendrán en Ansible Engine 2.9?
Antes de contarle en detalle lo que sucederá en Ansible 2.9, recordemos cómo dividimos todo el alcance del trabajo.
Identificamos 7 categorías y asignamos recursos de red específicos a cada una:
Nota: Los recursos en negrita se planificaron e implementaron en Ansible 2.9.
Según los comentarios de los clientes empresariales y la comunidad, era lógico abordar primero los módulos relacionados con los protocolos de topología de red, la virtualización y las interfaces.
Los siguientes módulos de recursos fueron desarrollados por el equipo de Ansible Network y corresponden a las plataformas admitidas por Red Hat:
Los siguientes módulos son desarrollados por la comunidad de Ansible:
exos_lldp_global- de Redes Extremas.nxos_bfd_interfaces- de cisconxos_telemetry- de cisco
Como puede ver, el concepto de módulos de recursos encaja en nuestra estrategia centrada en la plataforma. Es decir, incluimos las capacidades y funciones necesarias en el propio Ansible para respaldar 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 playbooks de Ansible. Para ampliar 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á
Una vez que se lance Ansible 2.9, trabajaremos en el siguiente conjunto de módulos de recursos para Ansible 2.10, que se pueden usar para configurar aún más la topología y la política de la red, p. . El plan de desarrollo aún se puede ajustar, por lo que si tiene comentarios, infórmelo a .
Recursos y primeros pasos
Fuente: habr.com