The Inside Playbook. Võrgufunktsioonid uues Ansible Engine 2.9

Red Hat Ansible Engine 2.9 tulevas väljaandes ootavad teid muljetavaldavad parandused, millest mõned on kirjas selles artiklis. Nagu alati, oleme Ansible Networki täiustusi arendanud avatud koostöös kogukonnaga. Liituge — vaadake GitHubi ülesannete tahvlit ja uurige arendusplaani Red Hat Ansible Engine 2.9 väljaande jaoks Ansible Networki wiki lehelt Ansible Network.

Kuidas me hiljuti teatasime, Red Hat Ansible Automation Platform kätkeb nüüd Ansible Towerit, Ansible Engine'i ja kogu Ansible Networki sisu. Praegu rakendatakse enamikku populaarsetest võrguplatvormidest Ansible'i moodulite kaudu. Näiteks:

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

Täielik nimekiri platvormidest, mida Red Hat toetab täielikult Ansible Automationi tellimuse kaudu, on avaldatud siin.

Mida me õppisime

Viimase nelja aasta jooksul oleme palju õppinud võrguautomaatika platvormi arendamisest. Samuti oleme õppinud, kuidas kuidas platvormi artefakte kasutatakse Ansible'i plaanides ja rollides lõppkasutajate poolt. Ja siin on, mida me välja selgitasime:

• Organisatsioonid automatiseerivad seadmeid mitte ainult ühe, vaid paljude tootjate kaudu.
• Automatiseerimine ei ole ainult tehniline nähtus, vaid ka kultuuriline.
• Suurte võrguautomaatika ulatus on keerulisem, kui näib, põhistruktuuride automatiseerimise kavandamise tõttu.

Kui arutasime oma pikaajalisi arendusplaane rohkem kui aasta tagasi, soovisid meie ettevõtte kliendid järgmist:

• Faktide kogumine peab olema paremini standardiseeritud ja kooskõlastatud automaatika tööprotsessiga igasuguste seadmete jaoks.
• Seadme konfiguratsiooni värskendamine peab samuti olema standardiseeritud ja kooskõlastatud, et Ansible'i moodulid saaksid seadme teises pooles pärast faktide kogumist töötlemiseks.
• Vajalikud on rangelt hallatavad ja toetatud meetodid seadme konfiguratsiooni struktureeritud andmeteks muutmiseks. Selle alusel on tõe allika võimalus viia võrgu-seadmest mujale.

Faktide täiustamine

Ansible'i kaudu võrguseadmest faktide kogumine toimub sageli juhuslikult. Erinevatel määradel on võrguplatvormid varustatud faktide kogumise võimalustega, kuid neil pole peaaegu üldse — või ei ole üldse — funktsioone andmete analüüsimiseks ja standartiseerimiseks võtme-väärtuse paarides. Loe postitus Ken Celenza kohta, kuidas keeruline ja vaevaline võib olla faktide andmete analüüsimine ja standartiseerimine.

Võib-olla olete märganud, kuidas oleme töötanud Ansible Network Engine'i rolli kallal. Loomulikult, 24 000 allalaadimise pärast on Network Engine'i roll kiiresti saanud üheks populaarsemaks Ansible'i rolliks Ansible Galaxy's võrguhalduse automatiseerimise skriptide jaoks. Enne kui me edasi viisime palju sellest Ansible 2.8-sse, et valmistuda selleks, mis vajalik on Ansible 2.9-s, pakkus see Ansible'i roll esimest komplekti tööriistu käsu analüüsimiseks, meeskondade haldamiseks ja andmete kogumiseks võrguseadmest.

Kui te teate Network Engine'i kasutamisest, on see väga tõhus viis andmete faktide kogumiseks, analüüsimiseks ja standardiseerimiseks Ansible'is. Selle rolli puudus on see, et tuleb luua terve hulk parserid iga platvormi ja kogu võrguaktiivsuse jaoks. Selleks, et mõista, kui keeruline on parserite loomine, tarnimine ja haldamine, vaadake üle 1200 parserit Cisco tüüpidelt.

Lühidalt, massilise automatiseerimise jaoks on väga oluline saada seadmetelt fakte ja normaliseerida need võtme-väärtuse paarideks, kuid seda on keeruline saavutada, kui teil on palju müüjaid ja võrguplatvorme.

Iga Ansible'i 2.9 võrgu faktide moodul võib nüüd analüüsida võrgu seadme konfiguratsiooni ja tagastada struktureeritud andmed - ilma täiendavate teekide, Ansible'i rollide või kohandatud parseriteta.

Alates Ansible 2.9-st paranevad iga kord, kui avaldatakse uuendatud võrgu moodul, faktide moodul, et anda andmeid selle konfiguratsiooni osa kohta. See tähendab, et faktide ja moodulite areng toimub nüüd ühes tempos, ja neil on alati ühine andmestruktuur.

Võrgu seadme ressursi konfiguratsiooni saab välja tuua ja muuta struktureeritud andmeteks kahel viisil. Mõlemat viisi saab kasutada kindla loetelu ressursside kogumiseks ja teisendamiseks uue märksõnaga gather_network_resources. Ressursside nimed vastavad moodulite nimedele, ja see on väga mugav.

Faktide kogumise ajal:

Kasutades märksõna gather_facts , saate tuua seadme praeguse konfiguratsiooni mängu alguses ja seejärel kasutada seda kogu mängu vältel. Määrake eraldi ressursid, mida tuleb seadmest välja tuua.

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

Olete võib-olla märganud nende näidete seas midagi uut, nimelt - gather_facts: true nüüd on saadaval kohaliku faktilise kogumise funktsioon võrguseadmetele.

Kohese võrgufaktide mooduli kasutamine:

- name: koguge liidese konfigureerimise faktilisi andmeid
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

Playbook tagastab järgmised liidese faktid:

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

Pange tähele, kuidas Ansible kogub natiivseid konfiguratsioone Arista seadmest ja muundab need struktureeritud andmeteks, mida saab kasutada standardsete võtme-väärtuse paaridena edasiste ülesannete ja toimingute jaoks.

Liidese faktid saab lisada Ansible'i salvestatud muutujatesse ja kasutada kohe või hiljem sisendina ressursimoodulile eos_interfaces ilma täiendava töötlemise või muundamiseta.

Ressursimoodulid

Nii et oleme kogunud faktid, normaliseerinud andmed, paneme need standardiseeritud sisemisse andmestruktuuri ning saime valmis tõeallika. Hooray! See on muidugi tore, kuid me peame siiski kuidagi võtme-väärtuse paare tagasi kindla konfiguratsiooni vormi viima, mida konkreetne seadme platvorm ootab. Nüüd vajame konkreetsete platvormide mooduleid, et rahuldada neid uusi faktilise kogumise ja normaliseerimise nõudeid.

Mis on ressursimoodul? Seadme konfigureerimise sektsioone saab mõista kui selle seadme pakutavaid ressursse. Võrgandmete ressursimoodulid on teadlikult piiratud ühe ressursiga ning neid saab kokku panna nagu klotse, et seadistada keerulisi võrgu teenuseid. Seetõttu lihtsustatakse ressursimooduli nõudeid ja spetsifikatsiooni loomulikult, kuna ressursimoodul suudab lugeda ja spetsiifilise võrgu teenuse seadistamiseks võrgu seadmes.

Ressursimooduli toimimise selgitamiseks vaatame näidet playbook'ist, mis näitab idempotentset toimingut, kasutades uut võrgufakti ja moodulit eos_l3_interface.

- name: näide faktide edastamisest seadmele.
  hosts: arista
  gather_facts: false
  tasks:
  - name: tugiteenuste faktide kogumine
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

  - name: veendu, et IP-aadressi teave on täpne
    eos_l3_interfaces:
      config: "{{ ansible_network_resources['l3_interfaces'] }}"
      register: result

  - name: veendu, et konfiguratsioon ei ole muutunud
    assert:
      that: not result.changed

Nagu näete, edastatakse seadme kogutud andmed otse vastavasse ressursimoodulisse ilma töötlemiseta. Playbooki käivitamisel tuvastab see seadme väärtused ja võrdleb need oodatud väärtustega. Antud näites vastavad saadud väärtused oodatutele (st konfiguratsiooni eristamise kontroll on teostatav) ja antakse teada, kas konfiguratsioon on muutunud.

Ideaalsed viisid konfiguratsiooni eristamise tuvastamiseks on salvestada faktid Ansible'i salvestatud muutujatesse ja perioodiliselt kasutada neid koos ressursimooduliga kontrollrežiimis. See on lihtne meetod nähtavaks teha, kas keegi on väärtusi käsitsi muutnud. Enamikul juhtudel lubavad organisatsioonid käsitsi muudatusi ja konfiguratsiooni, kuigi paljusid toiminguid teostatakse Ansible Automatsiooni kaudu.

Kuidas erinevad uued ressursimoodulid eelmistest?

Võrguekspertide jaoks on Ansible 2.9 ressursimoodulite kolm peamist erinevust varasemate versioonide suhtes.

1) Teatud võrguresursi (mida võib ette kujutada ka konfiguratsiooni ala) puhul arenevad moodulid ja faktid kõigis toetatud võrgutoimingute süsteemides samaaegselt. Arvame, et kui Ansible toetab ressursi konfiguratsiooni ühel võrgupõhjal, peaksime seda toetama igal pool. See lihtsustab ressursside moodulite kasutamist, kuna võrguekspert saab nüüd seadistada ressurssi (nt LLDP) kõigis võrgutoimingute süsteemides natiivsete ja toetatud moodulitega.

2) Ressursimoodulid sisaldavad nüüd oleku väärtust.

• ühtlustatud: konfiguratsioon on ühendatud antud konfiguratsiooniga (vaikimisi);
• asendatud: ressursi konfiguratsioon asendatakse antud konfiguratsiooniga;
• üle kirjutatud: ressursi konfiguratsioon asendatakse antud konfiguratsiooniga; liigsed ressursi eksemplarid eemaldatakse;
• deleted: ressursi konfiguratsioon eemaldatakse/taastatakse vaikimisi.

3) Ressursimoodulid sisaldavad nüüd stabiilseid tagastatavaid väärtusi. Kui võrguressursi moodul on teinud (või ettepaneku teinud) vajalikud muudatused võrguseadmes, tagastab see samad võtme-väärtuse paarid mänguraamatusse.

• before: seadistamine seadmes struktureeritud andmete kujul enne ülesannet;
• pärast: kui seade on muutunud (või võib muutuda, kui on kasutusel kontrollrežiim), tagastatakse saadud seadistamine struktureeritud andmete kujul;
• käsklused: kõik seadme seadistamise käsud, et tuua see soovitud seisundisse.

Mida see kõik tähendab? Miks see on oluline?

Selles postituses käsitletakse palju keerulisi kontseptsioone, kuid loodame, et lõpuks mõistate paremini, mida ettevõtte kliendid küsivad faktide kogumise, andmete normaliseerimise ja konfigureerimise tsükli osas automatiseerimisplatvormi jaoks. Kuid miks neile need parandused vajalikud on? Praegu tegelevad paljud organisatsioonid digitaalse transformatsiooniga, et muuta oma IT-keskkonnad paindlikumaks ja konkurentsivõimelisemaks. Olgu see hea või halb, ent paljud võrgutehnikud muutuvad võrgurakendusi arendavateks professionaalideks — oma huvist või juhtide käskude tõttu.

Organisatsioonid mõistavad, et üksikute võrgu mallide automatiseerimine ei lahenda killustatuse probleemi ja tõstab efektiivsust vaid teatud piirini. Red Hat Ansible Automation Platform pakub rangeid ja normeeritud ressursiandmete mudeleid, et programmiliselt hallata põhjalikke andmeid võrgu seadmes. See tähendab, et kasutajad loobuvad järk-järgult individuaalsetest seadistuskavadest kaasaegsemate meetodite kasuks, rõhutades tehnoloogiaid (nt IP-aadressid, VLAN-id, LLDP jne), mitte konkreetseid tarnija teostusi.

Kas see tähendab, et usaldusväärsete ja testitud komandode ja konfiguratsioonide päevad on loetud? Kaugel sellest. Oodatavad võrguressursi moodulid ei kehti igas olukorras ega iga tarnija jaoks, mistõttu on võrkude inseneridel teatud rakenduste jaoks endiselt vaja komandode ja konfiguratsioonide mooduleid. Ressursside moodulite eesmärk on lihtsustada suuri Jinja malle ja normalizeerida struktuurita seadme konfiguratsioonid struktureeritud JSON formaati. Ressursside moodulitega on olemasolevatel võrkudel lihtsam muuta oma konfiguratsioon struktuurseteks võtme-väärtus paarideks, mis esindavad loetavat tõe allikat. Kasutades struktureeritud võtme-väärtus paare, on võimalik liikuda seadmete igas seadmega käitatavatest konfiguratsioonidest sõltumatute struktureeritud andmete töötlemise juurde, edendades võrke „infrastruktuur kui kood” lähenemisega.

Millised võrguressursside moodulid kuvatakse Ansible Engine 2.9-s?

Enne kui räägime üksikasjalikult sellest, mis Ansible 2.9-s on, tuletagem meelde, kuidas me jagasime kogu töömahu.

Me eraldasime 7 kategooriat ja määrasime igale teatud võrguressursid:

Märkus: rasvaselt esile toodud ressursid on planeeritud ja rakendatud Ansible 2.9-s.
Kliendi ja kogukonna tagasiside põhjal oli mõistlik alustada moodulitest, mis on seotud võrgu topoloogia, virtualiseerimise ja liidestega.
Järgmised võrguressursside moodulid on välja töötatud Ansible Networki meeskonna poolt ja vastavad Red Hati toetatavatele platvormidele:

Järgmised moodulid on välja töötatud Ansible'i kogukonna poolt:

• exos_lldp_global — Extreme Networksilt.
• nxos_bfd_interfaces — Cisco poolt
• nxos_telemetry — Cisco poolt

Nagu näete, sobib ressursimoodulite kontseptsioon meie platvormile orienteeritud strateegiasse. See tähendab, et me integreerime vajalikud võimekused ja funktsioonid Ansible'i endasse, et toetada standardiseerimist võrgu moodulite arendamisel ning lihtsustada kasutajate tööd Ansible'i rollide ja mängude tasemel. Ressursimoodulite arendamise laiendamiseks on Ansible'i meeskond välja töötanud Module Builder'i tööriista.

Plaane Ansible 2.10 ja edasise jaoks

Pärast Ansible 2.9 väljalaset keskendume järgmisele võrguressursside moodulite komplektile Ansible 2.10-s, mida saab kasutada võrgu topoloogia ja poliitika edasise kohandamise jaoks, näiteks ACL, OSPF ja BGPArenguplaan on endiselt kohandatav, seega kui teil on kommentaare, andke sellest teada Ansible Network'i kogukonnas.

Ressursid ja algus

Pressiteade Ansible Automation Platform'i kohta
Ansible Automation Platform'i blogi
Ansible'i sisu edastamise tulevik
Mõtted Ansible projekti struktuuri muutmisest

Allikas: habr.com