O próximo lanzamento de Red Hat Ansible Engine 2.9 trae melloras interesantes, algunhas das cales se comentan neste artigo. Como sempre, estivemos desenvolvendo melloras de Ansible Network de xeito aberto, co apoio da comunidade. Únete a nós - bótalle un ollo e estudar o plan de desenvolvemento para na páxina wiki para .
Como anunciamos recentemente, agora inclúe Ansible Tower, Ansible Engine e todo o contido de Ansible Network. Hoxe en día, as plataformas de rede máis populares están implementadas a través de módulos Ansible. Por exemplo:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Para obter unha lista completa de plataformas que son totalmente compatibles con Red Hat mediante a subscrición a Ansible Automation, .
Que aprendemos
Durante os últimos catro anos, aprendemos moito sobre o desenvolvemento dunha plataforma de automatización de rede. Tamén aprendemos iso como Os artefactos da plataforma úsanse nos manuais e roles de Ansible polos usuarios finais. E aquí está o que descubrimos:
- As organizacións están automatizando dispositivos non só dun, senón de moitos provedores.
- A automatización non é só un fenómeno técnico, senón tamén cultural.
- Automatizar redes a escala é máis difícil do que parece debido aos principios arquitectónicos fundamentais do deseño de automatización.
Cando comentamos os nosos plans de crecemento a longo prazo hai máis dun ano, os nosos clientes corporativos solicitaron o seguinte:
- A recollida de datos debe estar mellor estandarizada e aliñada cos fluxos de traballo de automatización en todos os dispositivos.
- A actualización das configuracións no dispositivo tamén debe estar estandarizada e coherente para que os módulos Ansible xestionen a segunda metade do ciclo despois de recoller datos.
- Necesitamos métodos rigorosos e compatibles para converter a configuración do dispositivo en datos estruturados. Sobre esta base, a fonte da verdade pódese mover desde o dispositivo de rede.
Melloras de feitos
A recompilación de datos de dispositivos de rede usando Ansible adoita ocorrer ao azar. As plataformas baseadas na web teñen diferentes graos de capacidades de recollida de datos, pero teñen pouca ou ningunha funcionalidade para analizar e estandarizar a representación de datos en pares clave-valor. Ler Ken Celenza sobre o difícil e doloroso que pode ser analizar e estandarizar datos feitos.
Quizais teña notado que traballamos no rol de Motor de rede de Ansible. Por suposto, 24K descargas máis tarde, o rol de motor de rede converteuse rapidamente nun dos roles de Ansible máis populares en Ansible Galaxy para escenarios de automatización de redes. Antes de trasladar moito disto a Ansible 2.8 para prepararse para o que sería necesario en Ansible 2.9, este rol de Ansible proporcionou o primeiro conxunto de ferramentas para axudar a analizar comandos, xestionar comandos e recompilar datos para dispositivos de rede.
Se sabes como usar o motor de rede, esta é unha forma moi eficiente de recoller, analizar e estandarizar datos de feitos para usar en Ansible. A desvantaxe deste papel é que cómpre crear un montón de analizadores para cada plataforma e para toda a actividade da rede. Para comprender o difícil que é crear, enviar e manter analizadores, bótalle unha ollada dos mozos de Cisco.
En poucas palabras, obter datos dos dispositivos e normalizalos en pares clave-valor é esencial para a automatización a escala, pero conseguilo é difícil cando tes moitos provedores e plataformas de rede.
Cada módulo de feito de rede en Ansible 2.9 agora pode analizar a configuración dun dispositivo de rede e devolver datos estruturados, sen bibliotecas adicionais, roles de Ansible ou analizadores personalizados.
Desde Ansible 2.9, cada vez que se lanza un módulo de rede actualizado, mellórase o módulo de feitos para proporcionar datos sobre esta sección da configuración. É dicir, o desenvolvemento de feitos e módulos ocorre agora ao mesmo ritmo, e sempre terán unha estrutura de datos común.
A configuración dos recursos nun dispositivo de rede pódese recuperar e converter en datos estruturados de dúas formas. De ambos os xeitos, pode recoller e transformar unha lista específica de recursos mediante unha nova palabra clave gather_network_resources. Os nomes dos recursos coinciden cos nomes dos módulos, o que é moi cómodo.
Ao recoller datos:
Usando unha palabra clave gather_facts pode recuperar a configuración actual do dispositivo ao comezo do manual de xogos e, a continuación, utilizalo ao longo de todo o manual. Especifique os recursos individuais que se van recuperar do dispositivo.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueQuizais teña notado algo novo nestes exemplos, a saber: gather_facts: true agora está dispoñible para a recollida de datos nativos para dispositivos de rede.
Usando o módulo de feito de rede directamente:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesO playbook devolve os seguintes datos sobre a interface:
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 como Ansible recupera a configuración nativa do dispositivo Arista e transfórmaa en datos estruturados para utilizalos como pares clave-valor estándar para tarefas e operacións posteriores.
Os feitos da interface pódense engadir ás variables almacenadas de Ansible e utilizarse inmediatamente ou máis tarde como entrada a un módulo de recursos eos_interfaces sen procesamento ou conversión adicional.
Módulos de recursos
Entón, extraemos os feitos, normalizamos os datos, encaixámolos nun diagrama de estrutura de datos interno estandarizado e recibimos unha fonte de verdade preparada. Hurra! Isto é xenial, por suposto, pero aínda temos que converter dalgún xeito os pares clave-valor de volta á configuración específica que a plataforma específica do dispositivo espera. Agora necesitamos módulos específicos da plataforma para cumprir estes novos requisitos de normalización e recollida de datos.
Que é un módulo de recursos? Podes pensar nas seccións de configuración dun dispositivo como recursos proporcionados por ese dispositivo. Os módulos de recursos de rede están limitados intencionadamente a un só recurso e pódense apilar como bloques de construción para configurar servizos de rede complexos. Como resultado, os requisitos e especificacións para un módulo de recursos simplifícanse naturalmente, xa que o módulo de recursos pode ler и configurar un servizo de rede específico nun dispositivo de rede.
Para explicar o que fai un módulo de recursos, vexamos un manual de exemplo que mostra unha operación idempodent usando novos datos e módulos de recursos de rede 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 podes ver, os datos recollidos do dispositivo transfírense directamente ao módulo de recursos correspondente sen conversión. Cando se inicia, o playbook recupera valores do dispositivo e compáraos cos valores esperados. Neste exemplo, os valores devoltos son os esperados (é dicir, comproba as desviacións da configuración) e informa se a configuración cambiou.
A forma ideal de detectar a deriva da configuración é almacenar os feitos en variables almacenadas de Ansible e usalos periodicamente co módulo de recursos en modo de inspección. Este é un método sinxelo para ver se alguén cambiou manualmente os valores. Na maioría dos casos, as organizacións permiten cambios e configuración manualmente, aínda que moitas operacións realízanse a través de Ansible Automation.
En que se diferencian os novos módulos de recursos dos anteriores?
Para un enxeñeiro de automatización de redes, hai 3 diferenzas principais entre os módulos de recursos en Ansible 2.9 e as versións anteriores.
1) Para un determinado recurso de rede (que tamén se pode considerar como unha sección de configuración), os módulos e os feitos evolucionarán en todos os sistemas operativos de rede compatibles simultaneamente. Pensamos que se Ansible admite a configuración de recursos nunha plataforma de rede, deberíamos apoiala en todas partes. Isto simplifica o uso de módulos de recursos porque un enxeñeiro de automatización de redes agora pode configurar un recurso (como LLDP) en todos os sistemas operativos de rede con módulos nativos e compatibles.
2) Os módulos de recursos agora inclúen un valor de estado.
merged: a configuración combínase coa configuración proporcionada (por defecto);replaced: A configuración do recurso substituirase pola configuración proporcionada;overridden: A configuración do recurso substituirase pola configuración proporcionada; eliminaranse as instancias de recursos innecesarias;deleted: Eliminarase/restaurarase a configuración do recurso á configuración predeterminada.
3) Os módulos de recursos agora inclúen valores de retorno estables. Cando o módulo de recursos de rede realizou (ou propuxo) os cambios necesarios no dispositivo de rede, devolve os mesmos pares clave-valor ao manual.
before: configuración no dispositivo en forma de datos estruturados antes da tarefa;after: se o dispositivo cambiou (ou pode cambiar se se usa o modo de proba), a configuración resultante devolverase como datos estruturados;commands: Calquera comando de configuración execútase no dispositivo para poñelo no estado desexado.
Que significa todo isto? Por que é importante?
Esta publicación abarca moitos conceptos complexos, pero esperamos que, ao final, entenda mellor o que os clientes empresariais piden, en realidade, a recollida, a normalización de datos e a configuración de bucles para unha plataforma de automatización. Pero por que necesitan estas melloras? Moitas organizacións están a perseguir agora a transformación dixital para facer os seus contornos informáticos máis áxiles e competitivos. Para ben ou para mal, moitos enxeñeiros de rede convértense en desenvolvedores de redes por interese propio ou por orde da xestión.
As organizacións están a entender que a automatización de modelos de rede individuais non resolve o problema dos silos e só aumenta a eficiencia ata certo punto. Red Hat Ansible Automation Platform ofrece modelos de datos de recursos rigorosos e normativos para xestionar mediante programación os datos subxacentes nun dispositivo de rede. É dicir, os usuarios están abandonando gradualmente os métodos de configuración individuais en favor de métodos máis modernos con énfase nas tecnoloxías (por exemplo, enderezos IP, VLAN, LLDP, etc.), en lugar de implementar un provedor específico.
Significa isto que os días de configuración e módulos de comando fiables e probados están contados? En ningún caso. Os módulos de recursos de rede esperados non serán aplicables en todos os casos nin para todos os provedores, polo que os enxeñeiros de rede aínda necesitarán os módulos de comando e configuración para determinadas implementacións. O propósito dos módulos de recursos é simplificar grandes modelos de Jinja e normalizar as configuracións de dispositivos non estruturadas nun formato JSON estruturado. Con módulos de recursos, será máis doado para as redes existentes transformar a súa configuración en pares de clave-valor estruturados que representen unha fonte de verdade de fácil lectura. Ao usar pares clave-valor estruturados, pode pasar de executar configuracións en cada dispositivo a traballar con datos estruturados independentes e poñer as redes á vangarda dun enfoque de infraestrutura como código.
Que módulos de recursos chegarán en Ansible Engine 2.9?
Antes de contarche en detalle o que ocorrerá en Ansible 2.9, lembremos como dividimos todo o ámbito de traballo.
Identificamos 7 categorías e asignamos recursos de rede específicos a cada unha:
Nota: os recursos en negra planificáronse e implementáronse en Ansible 2.9.
En función dos comentarios dos clientes empresariais e da comunidade, era lóxico abordar primeiro aqueles módulos relacionados cos protocolos de topoloxía de rede, a virtualización e as interfaces.
O equipo de Ansible Network desenvolveu os seguintes módulos de recursos e corresponden ás plataformas admitidas por Red Hat:
Os seguintes módulos son desenvolvidos pola comunidade Ansible:
exos_lldp_global- de Extreme Networks.nxos_bfd_interfaces- de Cisconxos_telemetry- de Cisco
Como podes ver, o concepto de módulos de recursos encaixa na nosa estratexia centrada na plataforma. É dicir, incluímos as capacidades e funcións necesarias no propio Ansible para apoiar a estandarización no desenvolvemento de módulos de rede, e tamén para simplificar o traballo dos usuarios a nivel de roles e playbooks de Ansible. Para ampliar o desenvolvemento de módulos de recursos, o equipo de Ansible lanzou a ferramenta Module Builder.
Plans para Ansible 2.10 e posteriores
Unha vez que se publique Ansible 2.9, traballaremos no seguinte conxunto de módulos de recursos para Ansible 2.10, que se poden usar para configurar aínda máis a topoloxía e a política de rede, por exemplo. . O plan de desenvolvemento aínda se pode axustar, polo que se tes comentarios, infórmao a .
Recursos e inicio
Fonte: www.habr.com