El proper llançament de Red Hat Ansible Engine 2.9 aporta millores interessants, algunes de les quals es comenten en aquest article. Com sempre, hem estat desenvolupant millores a Ansible Network de manera oberta, amb el suport de la comunitat. Uneix-te a nosaltres: fes-hi una ullada i estudiar el pla de desenvolupament per a la pàgina wiki per .
Com hem anunciat recentment, ara inclou Ansible Tower, Ansible Engine i tot el contingut d'Ansible Network. Actualment, les plataformes de xarxes més populars s'implementen mitjançant mòduls Ansible. Per exemple:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Per obtenir una llista completa de plataformes que són totalment compatibles amb Red Hat mitjançant la subscripció a Ansible Automation, .
Què hem après
Durant els últims quatre anys, hem après molt sobre el desenvolupament d'una plataforma d'automatització de xarxa. També ho vam aprendre как Els usuaris finals utilitzen els artefactes de la plataforma als llibres de jugades i rols d'Ansible. I això és el que vam descobrir:
- Les organitzacions estan automatitzant dispositius no només d'un, sinó de molts proveïdors.
- L'automatització no és només un fenomen tècnic, sinó també cultural.
- Automatitzar xarxes a escala és més difícil del que sembla a causa dels principis arquitectònics fonamentals del disseny d'automatització.
Quan vam parlar dels nostres plans de creixement a llarg termini fa més d'un any, els nostres clients corporatius van demanar el següent:
- La recollida de dades s'ha d'estandarditzar millor i alinear-se amb els fluxos de treball d'automatització de tots els dispositius.
- L'actualització de les configuracions al dispositiu també ha de ser estandarditzada i coherent perquè els mòduls Ansible gestionen la segona meitat del cicle després de recopilar fets.
- Necessitem mètodes rigorosos i compatibles per convertir la configuració del dispositiu en dades estructurades. Sobre aquesta base, la font de la veritat es pot moure des del dispositiu de xarxa.
Millores de fets
La recopilació de dades dels dispositius de xarxa amb Ansible sovint es fa a l'atzar. Les plataformes basades en web tenen diferents graus de capacitats de recopilació de fets, però tenen poca o cap funcionalitat per analitzar i estandarditzar la representació de dades en parells clau-valor. Llegeix Ken Celenza sobre el difícil i dolorós que pot ser analitzar i estandarditzar dades de fet.
És possible que hàgiu notat que treballem en la funció del motor de xarxa Ansible. Naturalment, 24K descàrregues més tard, la funció de motor de xarxa s'ha convertit ràpidament en una de les funcions Ansible més populars d'Ansible Galaxy per als escenaris d'automatització de la xarxa. Abans de traslladar gran part d'això a Ansible 2.8 per preparar-nos per al que es necessitaria a Ansible 2.9, aquesta funció Ansible va proporcionar el primer conjunt d'eines per ajudar a analitzar ordres, gestionar ordres i recopilar dades per als dispositius de xarxa.
Si sabeu com utilitzar Network Engine, aquesta és una manera molt eficient de recopilar, analitzar i estandarditzar dades de fets per utilitzar-les a Ansible. L'inconvenient d'aquesta funció és que cal crear un munt d'analitzadors per a cada plataforma i per a tota l'activitat de la xarxa. Per entendre el difícil que és crear, enviar i mantenir analitzadors, feu una ullada a dels nois de Cisco.
En poques paraules, obtenir fets dels dispositius i normalitzar-los en parells clau-valor és essencial per a l'automatització a escala, però aconseguir-ho és difícil quan teniu molts proveïdors i plataformes de xarxa.
Cada mòdul de fets de xarxa d'Ansible 2.9 ara pot analitzar la configuració d'un dispositiu de xarxa i retornar dades estructurades, sense biblioteques addicionals, rols Ansible ni analitzadors personalitzats.
Des d'Ansible 2.9, cada vegada que es publica un mòdul de xarxa actualitzat, el mòdul de fets es millora per proporcionar dades sobre aquesta secció de la configuració. És a dir, el desenvolupament de fets i mòduls es produeix ara al mateix ritme, i sempre tindran una estructura de dades comuna.
La configuració dels recursos en un dispositiu de xarxa es pot recuperar i convertir en dades estructurades de dues maneres. De totes dues maneres, podeu recopilar i transformar una llista específica de recursos mitjançant una paraula clau nova gather_network_resources. Els noms dels recursos coincideixen amb els noms dels mòduls, cosa que és molt convenient.
Mentre es recullen fets:
Utilitzant una paraula clau gather_facts podeu recuperar la configuració actual del dispositiu al principi del llibre de jugades i, a continuació, utilitzar-lo durant tot el llibre de jocs. Especifiqueu els recursos individuals que voleu recuperar del dispositiu.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueÉs possible que hagis notat alguna cosa nova en aquests exemples, és a dir: gather_facts: true ara està disponible per a la recollida de dades natives per a dispositius de xarxa.
Utilitzant directament el mòdul de fets de xarxa:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesEl llibre de jugades retorna els fets següents sobre la interfície:
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: Ethernet1Observeu com Ansible recupera la configuració nativa del dispositiu Arista i la transforma en dades estructurades per utilitzar-les com a parells clau-valor estàndard per a tasques i operacions posteriors.
Els fets de la interfície es poden afegir a les variables emmagatzemades d'Ansible i utilitzar-los immediatament o més tard com a entrada a un mòdul de recursos eos_interfaces sense processament ni conversió addicionals.
Mòduls de recursos
Així doncs, vam extreure els fets, vam normalitzar les dades, les vam encaixar en un diagrama d'estructura de dades interna estandarditzada i vam rebre una font de veritat ja feta. Hura! Això és fantàstic, per descomptat, però encara hem de convertir d'alguna manera els parells clau-valor a la configuració específica que espera la plataforma del dispositiu específica. Ara necessitem mòduls específics de la plataforma per complir amb aquests nous requisits de normalització i recollida de dades.
Què és un mòdul de recursos? Podeu pensar en les seccions de configuració d'un dispositiu com a recursos proporcionats per aquest dispositiu. Els mòduls de recursos de xarxa es limiten intencionadament a un sol recurs i es poden apilar com a blocs de construcció per configurar serveis de xarxa complexos. Com a resultat, els requisits i l'especificació d'un mòdul de recursos es simplifiquen de manera natural, ja que el mòdul de recursos pot llegir и configurar un servei de xarxa específic en un dispositiu de xarxa.
Per explicar què fa un mòdul de recursos, mirem un exemple de llibre de jugades que mostra una operació idempodent utilitzant nous fets i mòduls de recursos de xarxa. 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.changedCom podeu veure, les dades recollides del dispositiu es transfereixen directament al mòdul de recursos corresponent sense conversió. Quan es llança, el llibre de jugades recupera valors del dispositiu i els compara amb els valors esperats. En aquest exemple, els valors retornats són els esperats (és a dir, comprova les desviacions de configuració) i informa si la configuració ha canviat.
La manera ideal de detectar la deriva de configuració és emmagatzemar els fets en variables emmagatzemades d'Ansible i utilitzar-los periòdicament amb el mòdul de recursos en mode d'inspecció. Aquest és un mètode senzill per veure si algú ha canviat manualment els valors. En la majoria dels casos, les organitzacions permeten els canvis i la configuració manualment, encara que moltes operacions es realitzen mitjançant Ansible Automation.
En què es diferencien els nous mòduls de recursos dels anteriors?
Per a un enginyer d'automatització de xarxes, hi ha 3 diferències principals entre els mòduls de recursos d'Ansible 2.9 i versions anteriors.
1) Per a un recurs de xarxa determinat (que també es pot considerar com una secció de configuració), els mòduls i els fets evolucionaran a través de tots els sistemes operatius de xarxa compatibles simultàniament. Pensem que si Ansible admet la configuració de recursos en una plataforma de xarxa, l'hauríem de donar suport a tot arreu. Això simplifica l'ús de mòduls de recursos perquè un enginyer d'automatització de xarxes ara pot configurar un recurs (com ara LLDP) en tots els sistemes operatius de xarxa amb mòduls natius i compatibles.
2) Els mòduls de recursos ara inclouen un valor d'estat.
merged: la configuració es combina amb la configuració proporcionada (per defecte);replaced: La configuració del recurs es substituirà per la configuració proporcionada;overridden: La configuració del recurs es substituirà per la configuració proporcionada; se suprimiran les instàncies de recursos innecessàries;deleted: La configuració del recurs s'eliminarà/restaurarà al valor predeterminat.
3) Els mòduls de recursos ara inclouen valors de retorn estables. Quan el mòdul de recursos de xarxa ha fet (o proposat) els canvis necessaris al dispositiu de xarxa, retorna els mateixos parells clau-valor al llibre de jugades.
before: configuració del dispositiu en forma de dades estructurades abans de la tasca;after: si el dispositiu ha canviat (o pot canviar si s'utilitza el mode de prova), la configuració resultant es retornarà com a dades estructurades;commands: Qualsevol ordre de configuració s'executa al dispositiu per portar-lo a l'estat desitjat.
Què significa tot això? Per què és important?
Aquesta publicació cobreix molts conceptes complexos, però esperem que al final entenguis millor què demanen els clients empresarials, de fet, la recollida, la normalització de dades i la configuració de bucles per a una plataforma d'automatització. Però, per què necessiten aquestes millores? Moltes organitzacions estan perseguint la transformació digital per fer que els seus entorns informàtics siguin més àgils i competitius. Per bé o per mal, molts enginyers de xarxa es converteixen en desenvolupadors de xarxes per interès propi o per ordre de la gestió.
Les organitzacions s'estan adonant que l'automatització de plantilles de xarxa individuals no resol el problema de les sitges i només augmenta l'eficiència fins a cert punt. La plataforma d'automatització Ansible de Red Hat proporciona models de dades de recursos rigorosos i normatius per gestionar programadament les dades subjacents en un dispositiu de xarxa. És a dir, els usuaris estan abandonant gradualment els mètodes de configuració individuals en favor de mètodes més moderns amb èmfasi en les tecnologies (per exemple, adreces IP, VLAN, LLDP, etc.), en lloc de la implementació d'un proveïdor específic.
Vol dir això que els dies de configuració i mòduls de comandament fiables i provats estan comptats? En cap cas. Els mòduls de recursos de xarxa esperats no seran aplicables en tots els casos ni per a tots els proveïdors, de manera que els enginyers de xarxa seguiran necessitant els mòduls d'ordres i configuració per a determinades implementacions. L'objectiu dels mòduls de recursos és simplificar les plantilles Jinja grans i normalitzar les configuracions de dispositius no estructurades en un format JSON estructurat. Amb els mòduls de recursos, serà més fàcil que les xarxes existents transformin la seva configuració en parells clau-valor estructurats que representin una font de veritat fàcil de llegir. Mitjançant l'ús de parells clau-valor estructurats, podeu passar d'executar configuracions a cada dispositiu a treballar amb dades estructurades independents i posar les xarxes al capdavant d'un enfocament d'infraestructura com a codi.
Quins mòduls de recursos arribaran a Ansible Engine 2.9?
Abans d'explicar-vos amb detall què passarà a Ansible 2.9, recordem com vam dividir tot l'àmbit de treball.
Hem identificat 7 categories i hem assignat recursos de xarxa específics a cadascuna:
Nota: els recursos en negreta es van planificar i implementar a Ansible 2.9.
A partir dels comentaris dels clients empresarials i de la comunitat, era lògic abordar primer els mòduls relacionats amb els protocols de topologia de xarxa, la virtualització i les interfícies.
Els mòduls de recursos següents van ser desenvolupats per l'equip d'Ansible Network i corresponen a les plataformes suportades per Red Hat:
La comunitat Ansible desenvolupa els mòduls següents:
exos_lldp_global- d'Extreme Networks.nxos_bfd_interfaces- de Cisconxos_telemetry- de Cisco
Com podeu veure, el concepte de mòduls de recursos s'adapta a la nostra estratègia centrada en la plataforma. És a dir, incloem les capacitats i funcions necessàries al mateix Ansible per donar suport a l'estandardització en el desenvolupament de mòduls de xarxa, i també per simplificar el treball dels usuaris a nivell de rols i llibres de jocs d'Ansible. Per ampliar el desenvolupament de mòduls de recursos, l'equip d'Ansible va llançar l'eina Module Builder.
Plans per a Ansible 2.10 i posteriors
Un cop publicat Ansible 2.9, treballarem en el següent conjunt de mòduls de recursos per a Ansible 2.10, que es poden utilitzar per configurar encara més la topologia i la política de xarxa, p. . El pla de desenvolupament encara es pot ajustar, així que si teniu comentaris, si us plau, informeu-ho .
Recursos i inicis
Font: www.habr.com