La Ena Ludlibro. Retaj funkcioj en la nova Ansible Engine 2.9

La Ena Ludlibro. Retaj funkcioj en la nova Ansible Engine 2.9

La venonta eldono de Red Hat Ansible Engine 2.9 alportas ekscitajn plibonigojn, iuj el kiuj estas kovritaj en ĉi tiu artikolo. Kiel ĉiam, ni disvolvis plibonigojn de Ansible Network malkaŝe, kun komunuma subteno. Aliĝu al ni - rigardu eldona tabulo en GitHub kaj studi la disvolvan planon por eldono de Red Hat Ansible Engine 2.9 sur la vikipaĝo por Ansible Reto.

Kiel ni lastatempe anoncis, Red Hat Ansible Automation Platform nun inkluzivas Ansible Tower, Ansible Engine kaj la tutan enhavon de Ansible Network. Nuntempe, plej popularaj interkonektaj platformoj estas efektivigitaj per Ansible-moduloj. Ekzemple:

  • Arista EOS
  • Cisco IOS
  • Cisco IOS XR
  • Cisco NX-OS
  • Junipero Junos
  • VyOS

Por kompleta listo de platformoj, kiuj estas plene subtenataj de Red Hat per abono de Ansible Automation, publikigita ĉi tie.

Kion ni lernis

Dum la pasintaj kvar jaroj, ni lernis multon pri evoluigado de reto-aŭtomatiga platformo. Ni ankaŭ lernis tion kiom platformartefaktoj estas uzitaj en Ansible-ludlibroj kaj roloj fare de finuzantoj. Kaj jen kion ni eksciis:

  • Organizoj aŭtomatigas aparatojn de ne nur unu, sed multaj vendistoj.
  • Aŭtomatigo estas ne nur teknika fenomeno, sed ankaŭ kultura.
  • Aŭtomatigi retojn skale estas pli malfacila ol ĝi ŝajnas pro la fundamentaj arkitekturaj principoj de aŭtomatiga dezajno.

Kiam ni diskutis pri niaj longdaŭraj kreskplanoj antaŭ pli ol unu jaro, niaj kompaniaj klientoj petis la jenon:

  • Faktkolekto devas esti pli bone normigita kaj akordigita kun aŭtomatigaj laborfluoj tra ĉiuj aparatoj.
  • Ĝisdatigi agordojn sur la aparato ankaŭ devas esti normigita kaj konsekvenca por ke Ansible-moduloj traktu la duan duonon de la ciklo post kolektado de faktoj.
  • Ni bezonas rigorajn kaj subtenatajn metodojn por konverti aparatan agordon en strukturitajn datumojn. Sur ĉi tiu bazo, la fonto de vero povas esti movita de la reto-aparato.

Faktaj plibonigoj

Kolekti faktojn de retaj aparatoj uzante Ansible ofte okazas hazarde. Ret-bazitaj platformoj havas diversajn gradojn da fakto-kolektaj kapabloj, sed ili havas malmulte aŭ neniun funkciecon por analizado kaj normigado de la reprezentado de datenoj en ŝlosil-valoraj paroj. Legu afiŝo Ken Celenza pri kiom malfacila kaj dolora povas esti analizi kaj normigi faktajn datumojn.

Vi eble rimarkis, ke ni laboras pri la rolo de Ansible Network Engine. Kompreneble, 24K elŝutas poste, la rolo de Network Engine rapide fariĝis unu el la plej popularaj Ansible-roloj en Ansible Galaxy por retaj aŭtomatigaj scenaroj. Antaŭ ol ni movis multon de ĉi tio en Ansible 2.8 por prepari por tio, kio bezonus en Ansible 2.9, ĉi tiu Ansible-rolo disponigis la unuan aron da iloj por helpi analizi komandojn, administri komandojn kaj kolekti datumojn por retaj aparatoj.

Se vi scias kiel uzi Retan Motoron, ĉi tio estas tre efika maniero kolekti, analizi kaj normigi faktojn por uzi en Ansible. La malavantaĝo de ĉi tiu rolo estas, ke vi devas krei tutan aron da analiziloj por ĉiu platformo kaj por ĉiu reto-agado. Por kompreni kiom malfacile estas krei, sendi kaj konservi analizilojn, rigardu Pli ol 1200 analiziloj de la uloj ĉe Cisco.

En resumo, akiri faktojn de aparatoj kaj normaligi ilin en ŝlosil-valorajn parojn estas esenca por aŭtomatigo ĉe skalo, sed atingi ĉi tion estas malfacila kiam vi havas multajn vendistojn kaj retajn platformojn.

Ĉiu reto-fakta modulo en Ansible 2.9 nun povas analizi la agordon de reto-aparato kaj resendi strukturitajn datumojn - sen pliaj bibliotekoj, Ansible-roloj aŭ kutimaj analiziloj.

Ekde Ansible 2.9, ĉiufoje kiam ĝisdatigita retmodulo estas liberigita, la fakta modulo estas plibonigita por provizi datumojn pri ĉi tiu sekcio de la agordo. Tio estas, la disvolviĝo de faktoj kaj moduloj nun okazas samrapide, kaj ili ĉiam havos komunan datumstrukturon.

La agordo de resursoj sur reta aparato povas esti prenita kaj konvertita en strukturitajn datenojn en du manieroj. Ambaŭmaniere, vi povas kolekti kaj transformi specifan liston de rimedoj uzante novan ŝlosilvorton gather_network_resources. La nomoj de rimedoj kongruas kun la nomoj de moduloj, kio estas tre oportuna.

Dum kolektado de faktoj:

Uzante ŝlosilvorton gather_facts vi povas retrovi la nunan aparatan agordon komence de la ludlibro, kaj poste uzi ĝin tra la tuta ludlibro. Indiku la individuajn rimedojn por esti prenitaj de la aparato.

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

Vi eble rimarkis ion novan en ĉi tiuj ekzemploj, nome - gather_facts: true nun disponeblas por denaska fakkolekto por retaj aparatoj.

Uzante la retan faktomodulon rekte:

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

La ludlibro resendas la sekvajn faktojn pri la interfaco:

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

Rimarku kiel Ansible prenas la indiĝenan agordon de la Arista aparato kaj transformas ĝin en strukturitajn datumojn por uzi kiel normajn ŝlosilvalorajn parojn por kontraŭfluaj taskoj kaj operacioj.

Interfacfaktoj povas esti aldonitaj al Ansible konservitaj variabloj kaj uzataj tuj aŭ poste kiel enigo al rimedmodulo eos_interfaces sen plia prilaborado aŭ konvertiĝo.

Rimedaj Moduloj

Do, ni ĉerpis la faktojn, normaligis la datumojn, ĝustigis ilin en normigita interna datumstrukturdiagramo kaj ricevis pretan fonton de vero. Hura! Ĉi tio estas bonega, kompreneble, sed ni ankoraŭ bezonas iel konverti la ŝlosil-valorajn parojn reen al la specifa agordo, kiun la specifa aparato-platformo atendas. Ni nun bezonas platform-specifajn modulojn por plenumi ĉi tiujn novajn postulojn pri fakto-kolektado kaj normaligo.

Kio estas rimedmodulo? Vi povas pensi pri la agordaj sekcioj de aparato kiel rimedoj provizitaj de tiu aparato. Retaj rimedmoduloj estas intencite limigitaj al ununura rimedo kaj povas esti stakitaj kiel konstrubriketoj por agordi kompleksajn retajn servojn. Kiel rezulto, la postuloj kaj specifo por rimedmodulo estas nature simpligitaj, ĉar la rimedmodulo povas legi и agordi specifan retan servon sur reta aparato.

Por klarigi kion faras rimedmodulo, ni rigardu ekzemplan ludlibron, kiu montras idempodentan operacion uzante novajn retajn rimedfaktojn kaj modulon. 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

Kiel vi povas vidi, la datumoj kolektitaj de la aparato estas transdonitaj rekte al la responda rimeda modulo sen konvertiĝo. Kiam estas lanĉita, la ludlibro prenas valorojn de la aparato kaj komparas ilin kun atendataj valoroj. En ĉi tiu ekzemplo, la valoroj redonitaj estas kiel atenditaj (tio estas, ĝi kontrolas por agordaj devioj) kaj raportas ĉu la agordo ŝanĝiĝis.

La ideala maniero por detekti agordan drivon estas stoki faktojn en Ansible konservitaj variabloj kaj periode uzi ilin kun la rimedmodulo en inspekta reĝimo. Ĉi tio estas simpla metodo por vidi ĉu iu mane ŝanĝis la valorojn. Plejofte, organizoj permesas ŝanĝojn kaj agordon permane, kvankam multaj operacioj estas faritaj per Ansible Automation.

Kiel la novaj rimedmoduloj diferencas de la antaŭaj?

Por retaŭtomatiga inĝeniero, ekzistas 3 ĉefaj diferencoj inter rimedmoduloj en Ansible 2.9 kaj antaŭaj versioj.

1) Por antaŭfiksita retrimedo (kiu ankaŭ povas esti opiniita kiel agorda sekcio), moduloj kaj faktoj evoluos tra ĉiuj subtenataj retaj operaciumoj samtempe. Ni pensas, ke se Ansible subtenas rimedan agordon sur unu retoplatformo, ni devus subteni ĝin ĉie. Tio simpligas la uzon de rimedmoduloj ĉar retaŭtomatigo-inĝeniero nun povas agordi rimedon (kiel ekzemple LLDP) sur ĉiuj retaj operaciumoj kun indiĝenaj kaj subtenataj moduloj.

2) Rimedaj moduloj nun inkluzivas ŝtatan valoron.

  • merged: la agordo estas kunfandita kun la provizita agordo (defaŭlte);
  • replaced: La rimeda agordo estos anstataŭigita per la provizita agordo;
  • overridden: La rimeda agordo estos anstataŭigita per la provizita agordo; nenecesaj rimedokazaĵoj estos forigitaj;
  • deleted: La rimeda agordo estos forigita/restarigita defaŭlte.

La Ena Ludlibro. Retaj funkcioj en la nova Ansible Engine 2.9

3) Rimedaj moduloj nun inkluzivas stabilajn revenvalorojn. Kiam la reto-rimeda modulo faris (aŭ proponis) la necesajn ŝanĝojn al la reta aparato, ĝi resendas la samajn ŝlosil-valorajn parojn al la ludlibro.

  • before: agordo sur la aparato en formo de strukturitaj datumoj antaŭ la tasko;
  • after: se la aparato ŝanĝiĝis (aŭ eble ŝanĝiĝos se testareĝimo estas uzata), la rezulta agordo estos resendita kiel strukturitaj datumoj;
  • commands: Ĉiuj agordaj komandoj funkcias sur la aparato por alporti ĝin en la deziratan staton.

La Ena Ludlibro. Retaj funkcioj en la nova Ansible Engine 2.9

La Ena Ludlibro. Retaj funkcioj en la nova Ansible Engine 2.9

Kion ĉio ĉi signifas? Kial ĝi estas grava?

Ĉi tiu afiŝo kovras multajn kompleksajn konceptojn, sed ni esperas, ke finfine vi havos pli bonan komprenon pri tio, kion entreprenaj klientoj petas fakte kolekton, datumnormaligon kaj buklan agordon por aŭtomatiga platformo. Sed kial ili bezonas ĉi tiujn plibonigojn? Multaj organizoj nun traktas ciferecan transformon por fari siajn IT-mediojn pli lertaj kaj konkurencivaj. Por pli bone aŭ malbone, multaj retaj inĝenieroj fariĝas retaj programistoj aŭ pro propra intereso aŭ laŭ ordono de administrado.

Organizoj rimarkas, ke aŭtomatigi individuajn retajn ŝablonojn ne solvas la problemon de siloj kaj nur certagrade pliigas efikecon. La Red Hat Ansible Automation Platform disponigas rigorajn kaj normigajn rimedojn datummodelojn por programe administri la subestajn datumojn sur reta aparato. Tio estas, uzantoj iom post iom forlasas individuajn agordajn metodojn en favoro de pli modernaj metodoj kun emfazo sur teknologioj (ekzemple, IP-adresoj, VLANoj, LLDP, ktp.), prefere ol sur specifa vendista efektivigo.

Ĉu ĉi tio signifas, ke la tagoj de fidindaj kaj pruvitaj komandmoduloj kaj agordo estas nombritaj? En neniu kazo. La atendataj retaj rimedmoduloj ne estos uzeblaj en ĉiuj kazoj aŭ por ĉiu vendisto, do la komando- kaj agordaj moduloj ankoraŭ estos bezonataj de retaj inĝenieroj por certaj efektivigoj. La celo de rimedmoduloj estas simpligi grandajn Jinja-ŝablonojn kaj normaligi nestrukturitajn aparatajn agordojn en strukturitan JSON-formaton. Kun rimedmoduloj, estos pli facile por ekzistantaj retoj transformi sian agordon en strukturitajn ŝlosil-valorajn parojn, kiuj reprezentas facile legeblan fonton de vero. Uzante strukturitajn ŝlosil-valorajn parojn, vi povas moviĝi de funkciado de agordoj sur ĉiu aparato al labori kun sendependaj strukturitaj datumoj kaj alporti retojn al la avangardo de infrastruktura-kiel-koda aliro.

Kiuj rimedmoduloj venos en Ansible Engine 2.9?

Antaŭ ol ni rakontos al vi detale, kio okazos en Ansible 2.9, ni memoru kiel ni dividis la tutan amplekson de laboro.

Ni identigis 7 kategoriojn kaj asignis specifajn retajn rimedojn al ĉiu:

La Ena Ludlibro. Retaj funkcioj en la nova Ansible Engine 2.9

Noto: Rimedoj en grasa skribo estis planitaj kaj efektivigitaj en Ansible 2.9.
Surbaze de sugestoj de entreprenaj klientoj kaj la komunumo, estis logike unue trakti tiujn modulojn ligitajn al retaj topologiaj protokoloj, virtualigo kaj interfacoj.
La sekvaj rimedmoduloj estis evoluigitaj de la teamo de Ansible Network kaj respondas al la platformoj subtenataj de Red Hat:

La Ena Ludlibro. Retaj funkcioj en la nova Ansible Engine 2.9

La sekvaj moduloj estas evoluigitaj fare de la Ansible-komunumo:

  • exos_lldp_global - de Ekstremaj Retoj.
  • nxos_bfd_interfaces - de Cisco
  • nxos_telemetry - de Cisco

Kiel vi povas vidi, la koncepto de rimedmoduloj konvenas al nia platform-centra strategio. Tio estas, ni inkluzivas la necesajn kapablojn kaj funkciojn en Ansible mem por subteni normigon en la disvolviĝo de retaj moduloj, kaj ankaŭ por simpligi la laboron de uzantoj je la nivelo de roloj kaj ludlibroj de Ansible. Por vastigi la evoluon de rimedmoduloj, la Ansible-teamo publikigis la Module Builder-ilon.

Planoj por Ansible 2.10 kaj poste

Post kiam Ansible 2.9 estos liberigita, ni laboros pri la sekva aro de rimedmoduloj por Ansible 2.10, kiu povas esti uzata por plue agordi retan topologion kaj politikon, ekz. ACL, OSPF kaj BGP. La disvolva plano ankoraŭ povas esti alĝustigita, do se vi havas komentojn, bonvolu raporti ĝin al Ansible Network-komunumo.

Rimedoj kaj komenci

Gazetara komuniko pri Ansible Automation Platform
Blogo pri Ansible Automation Platform
La estonteco de enhavo livero en Ansible
Reflektadoj pri ŝanĝado de la Ansible-projektstrukturo

fonto: www.habr.com

Aldoni komenton