🥇The Inside Playbook. Võrgufunktsioonid uues Ansible Engine 2.9

Red Hat Ansible Engine 2.9 tulevases versioonis ootavad teid tähelepanuväärsed täiustused, millest mõned on selles artiklis kirjeldatud. Nagu tavaliselt, arendasime Ansible Networki täiustusi avatud koostöös kogukonnaga. Liituge — vaadake GitHubi ülesannete tahvlit ja uurige arendusplaani Red Hat Ansible Engine 2.9 väljaande jaoks wiki lehelt Ansible Network.

Kuidas me hiljuti teada andsime, Red Hat Ansible Automation Platform kätkeb nüüd Ansible Toweri, Ansible Engine'i ja kogu Ansible Networki sisu. Praegu rakendavad enamik tuntud võrguplatvormidest Ansible'i mooduleid. Näiteks:

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

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

Mida me oleme õppinud

Viimase nelja aasta jooksul oleme õppinud palju võrguautomaatika platvormi arendamisest. Samuti oleme õppinud, kuidas kuidas platvormi artefakte rakendatakse Ansible'i mängude ja rollide kaudu lõppkasutajate poolt. Ja siin on, mida me avastasime:

Organisatsioonid automatiseerivad seadmeid mitte ühelt, vaid paljude tootjatelt.
Automatiseerimine on mitte ainult tehniline nähtus, vaid ka kultuuriline.
Võrguhalduse ulatuslik automatiseerimine on keerulisem, kui esmapilgul tundub, kuna see põhineb automaatika projekteerimise fundamentaalsetel arhitektuuripõhimõtetel.

Kuna me arutasime oma pikaajalisi arenguplaani rohkem kui aasta tagasi, siis palusid meie korporatiivsed kliendid järgmist:

Faktide kogumist tuleb paremini standardiseerida ja kooskõlastada automaatika tööprotsessiga igasuguste seadmete jaoks.
Ka seadme konfiguratsioonide värskendamine peab olema standardiseeritud ja kooskõlastatud, et Ansible'i moodulid saaksid kogumise tsükli teise osa töödelda.
Vajadus on rangete ja toetatavate meetodite järele seadme konfiguratsiooni muutmiseks struktureeritud andmeteks. Selle alusel saaks tõe allika viia võrgu seadmetelt.

Faktide täiustamine

Faktide kogumine võrgu seadmetelt Ansible'i abil toimub sageli juhuslikult. Võrgupaltvormidel on erineval määral faktide kogumise võimalusi, kuid neil on peaaegu puuduvad — või isegi täiesti puuduvad — andmete analüüsi ja esitamise standardimise funktsioonid võtme-väärtuse paaridena. Loe post Ken Celenza räägib, kui keeruline ja vaevarikas on faktide andmete analüüsimine ja standardiseerimine.

Võib-olla olete märganud, kuidas me oleme töötanud Ansible Network Engine'i rolli kallal. Loomulikult, pärast 24 000 allalaadimist, on Network Engine'i roll kiiresti saanud üheks populaarseimaks Ansible'i rolliks Ansible Galaxy's võrguautomaatika skriptide jaoks. Enne kui me palju sellest Ansible 2.8-sse edastasime, et valmistuda Ansible 2.9 jaoks, pakkus see Ansible'i roll esimesi tööriistu käskude parsimiseks, meeskondade haldamiseks ja andmete kogumiseks võrguseadmetelt.

Kui te tunnete Network Engine'i kasutamist, on see väga tõhus viis faktide andmete kogumiseks, parsimiseks ja standardiseerimiseks Ansible'is. Selle rolli miinus on see, et tuleb luua hulk parsereid igale platvormile ja kogu võrguaktiivsuse jaoks. Et mõista, kui keeruline on parsereid luua, tarnida ja hooldada, vaadake üle 1200 parsereid Cisco meestelt.

Lühidalt, ulatusliku automatiseerimise jaoks on oluline saada seadmetelt fakte ja normaliseerida need võtme-väärtuse paarideks, kuid see on keeruline, kui teil on palju müüjaid ja võrgupaltforme.

Iga Ansible 2.9 võrgufaktide moodul suudab nüüd analüüsida võrgu seadme konfiguratsiooni ja tagastada struktureeritud andmeid — ilma täiendavate teekide, Ansible'i rollideta või kohandatud tõlgendajateta.

Alates Ansible 2.9 iga värskendatud võrgu mooduli väljaandmisel täiustatakse faktide moodulit, et esitada andmeid antud konfiguratsiooni osa kohta. See tähendab, et faktide ja moodulite areng toimub nüüd koos ning neil on alati ühtne andmestruktuur.

Võrgu seadme ressursside konfiguratsiooni saab välja tõmmata ja muuta struktureeritud andmeteks kahel viisil. Mõlemal juhul on võimalik koguda ja muuta kindel ressursside nimekiri uue märksõna abil gather_network_resources. Ressursside nimed vastavad moodulite nimedele, mis on väga mugav.

Faktide kogumise ajal:

Märksõna abil gather_facts saate alguses seadme praeguse konfiguratsiooni playbookis välja võtta ja seejärel kasutada seda kogu playbooki vältel. Määrake eraldi ressursid, mille soovite seadmest välja võtta.

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

Olete võinud märgata, et nendes näidetes on midagi uut, nimelt — gather_facts: true on nüüd saadaval võrgu seadmete jaoks natiivsete faktide kogumiseks.

Võrgufaktide mooduli otse kasutamine:

- name: kogu liidese konfiguratsiooni faktid
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

Playbook tagastab järgmised faktid liidese kohta:

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 tõmbab seadme Arista natiivset konfiguratsiooni ja muudab selle struktureeritud andmeteks, et kasutada standardsete võtme-väärtuse paaridena edasistes ülesannetes ja toimingutes.

Ansible'i salvestatud muutujaid saab lisada liideste faktidesse ja kasutada kohe või hiljem sisendina ressursimooduli jaoks. eos_interfaces ilma lisatöötluse või muutmiseta.

Ressursimoodulid

Nii oleme faktid välja tõmmanud, andmed normaliseerinud, need standardiseeritud sisemisse andmestruktuuri kirja pannud ja valmis tõeallika saanud. Jeii! See on muidugi suurepärane, kuid meil on endiselt vaja mingil moel teisendada võtme-väärtuse paare tagasi spetsiifiliseks konfiguratsiooniks, mida konkreetne seadmeplatvorm ootab. Nüüd vajame platvormi spetsiifilisi mooduleid, et rahuldada neid uusi faktide kogumise ja normaliseerimise nõudeid.

Mis on ressursimoodul? Seadme konfigureerimise jaotisi võib ette kujutada kui selle seadme poolt pakutavaid ressursse. Võrgumoodulid on teadlikult piiratud ühe ressursiga ning neid saab virna laduda nagu klotse, et seadistada keerukamaid võrguteenuseid. Selle tulemusena lihtsustuvad ressursimooduli nõuded ja spetsifikatsioon loomulikult, kuna ressursimoodul suudab lugeda ja konfigureerima teatud võrgu teenust võrgu seadmes.

Selgitamaks, mida ressursimoodul teeb, vaatame näidet mänguraamatust, mis näitab idempotentset operatsiooni, kasutades uusi võrgu ressursi fakte ja moodulit. eos_l3_interface.

- name: näide faktidest, mis tagasi seadmesse edastatakse.
  hosts: arista
  gather_facts: false
  tasks:
  - name: võtta arista eos faktid
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

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

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

Nagu näete, edastatakse seadme kogutud andmed otse vastavale ressursimoodulile ilma konversioonita. Käivitamisel tõmbab mänguraamat seadmetelt väärtused ja võrdleb neid oodatud väärtustega. Käesolevas näites vastavad saadud väärtused oodatud väärtustele (st toimub konfiguratsiooni kõrvalekallete kontroll) ja väljastatakse teade, kas konfiguratsioon on muutunud.

Ideaalne viis konfigureerimise kõrvalekalde tuvastamiseks on salvestada faktid Ansible'i salvestatud muutujatesse ja perioodiliselt kasutada neid koos ressursside mooduliga kontrollrežiimis. See on lihtne meetod näha, kas keegi on väärtusi käsitsi muutnud. Enamiku jaoks lubavad organisatsioonid käsitsi muudatusi ja konfigureerimist, kuigi paljusid toiminguid tehakse läbi Ansible'i automatiseerimise.

Kuidas erinevad uued ressursi moodulid varasematest?

Võrguhalduse automatiseerimise insenerile on Ansible 2.9 ressursi moodulite ja varasemate versioonide vahel kolm peamist erinevust.

1) Teatud võrguresursi (mida võib ette kujutada ka konfiguratsioonide osana) puhul arenevad moodulid ja faktid kõigis toetatud võrgukäitus süsteemides samal ajal. Me arvame, et kui Ansible toetab ressursi konfiguratsiooni ühel võrgupõhjal, peaksime selle toetama igal pool. See lihtsustab ressursside moodulite kasutamist, sest võrguhalduse automatiseerimise insener saab nüüd seadistada ressurssi (nt LLDP) kõigis võrgukäitus süsteemides koos kohalike ja toetatud moodulitega.

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

ühendatud: seadistused on ühendatud esitatud seadistustega (vaikimisi);
asendatud: ressursi seadistus asendatakse esitatud seadistusega;
ülekirjutatud: ressursi seadistus asendatakse esitatud seadistusega; üleliigsed ressursi eksemplarid eemaldatakse;
kustutatud: ressursi seadistus eemaldatakse/taastatakse vaikimisi.

3) Ressursimoodulid sisaldavad nüüd stabiilseid tagastatud väärtusi. Kui võrguressursi moodul on teinud (või soovitanud) vajalikud muudatused võrgu seadmes, tagastab see samad võtme-väärtuse paarid mänguraamatus.

before: seadistamine seadmes struktureeritud andmete kujul enne ülesannet;
pärast: kui seade on muutunud (või võib muutuda, kui kontrollrežiimi kasutatakse), tagastatakse saadud seadistus struktureeritud andmetena;
käsklused: kõik seadistuskäsklused, mis on seadmes käivitatud selle soovitud olekusse viimiseks.

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

Selles postituses käsitletakse palju keerulisi kontseptsioone, kuid loodame, et lõpuks mõistate paremini, miks ettevõtte kliendid nõuavad faktide kogumist, andmete normaliseerimist ja tsüklite seadistamist automatiseerimisplatvormile. Miks vajavad nad neid täiustusi? Paljud organisatsioonid viivad praegu läbi digitaalset transformatsiooni, et muuta oma IT-keskkonnad paindlikumaks ja konkurentsivõimelisemaks. Hea või halb, kuid paljud võrgutehnikud muutuvad võrgurakendajateks – kas isikliku huvi või juhtkonna nõudmisel.

Organisatsioonid mõistavad, et üksikute võrgumallide automatiseerimine ei lahenda killustatuse probleemi ja tõhustab tegevust vaid teatud piirini. Red Hat Ansible Automation Platform pakub rangeid ja normeeritud andmemudeleid ressursside jaoks, et programmeerida alusandmete haldamist võrgu seadmes. See tähendab, et kasutajad loobuvad järk-järgult individuaalsetest seadistamisviisidest, eelistades kaasaegsemaid meetodeid, mis keskenduvad tehnoloogiatele (nt IP-aadressid, VLAN, LLDP jne), mitte konkreetsetele tootja rakendustele.

Kas see tähendab, et usaldusväärsete ja testitud komandode ning konfiguratsioonide päevad on loetud? Absoluutselt mitte. Oodatavad võrgupoodid ei ole igas olukorras ja mitte iga müüja jaoks rakendatavad, seega vajavad võrgutehnikud komandode ja konfiguratsioonide mooduleid teatud rakenduste jaoks. Ressursimoodulite eesmärk on lihtsustada suurte Jinja mallide kasutamist ja normaliseerida struktureerimata seadme konfiguratsioonid struktureeritud JSON-formaati. Ressursimoodulitega on olemasolevatel võrkudel lihtsam oma konfiguratsioonid struktureeritud võtme-väärtuse paarideks muuta, mis esindavad loetavat tõe allikat. Struktureeritud võtme-väärtuse paaride kasutamine võimaldab liikuda seadmete eraldi käivitamisest ja töötamisest sõltumatute struktureeritud andmetega, viies võrgud esiplaanile „infrastruktuur koodina“ lähenemise kaudu.

Millised ressursimoodulid tulevad Ansible Engine 2.9-sse?

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

Oleme eraldanud 7 kategooriat ja igale neist on määratud teatud võrguressursid:

Märkus: rasvaste tähtedega esitatud ressursid on planeeritud ja ellu viidud Ansible 2.9-s.
Korporatiivsete klientide ja kogukonna tagasiside põhjal oli loogiline keskenduda kõigepealt modulitele, mis on seotud võrgu topoloogia protokollide, virtualiseerimise ja liidestega.
Järgmised ressursimoodulid on välja töötatud Ansible Networki meeskonna poolt ja vastavad Red Hati toetatud platvormidele:

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

exos_lldp_global — Extreme Networksilt.
nxos_bfd_interfaces — Ciscolt.
nxos_telemetry — Ciscolt.

Nagu näete, sobitub ressursimoodulite kontseptsioon meie platvormipõhise strateegiaga. See tähendab, et integreerime vajalikud võimekused ja funktsioonid otse Ansible'i, 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 andnud tööriista Module Builder.

Plaanimine Ansible 2.10 ja hiljem

Pärast Ansible 2.9 väljaandmist keskendume järgmistele Ansible 2.10 ressursside moodulitele, mida saab kasutada võrgu topoloogia ja poliitika edasiseks kohandamiseks, näiteks ACL, OSPF ja BGP. Arenduskava on endiselt kohandatav, seega kui teil on kommentaare, andke sellest teada Ansible Network'i kogukonnas.