Red Hat Ansible Engine 2.9 eelseisev väljalase toob kaasa põnevaid täiustusi, millest mõnda käsitletakse selles artiklis. Nagu alati, oleme Ansible Networki täiustusi arendanud avalikult ja kogukonna toel. Liituge meiega – vaadake ja tutvuda arengukavaga wiki lehel .
Nagu me hiljuti teatasime, sisaldab nüüd Ansible Towerit, Ansible Engine'i ja kogu Ansible Networki sisu. Tänapäeval rakendatakse kõige populaarsemaid võrguplatvorme Ansible moodulite kaudu. Näiteks:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Kadakas Junos
- VyOS
Täieliku loendi platvormidest, mida Red Hat Ansible Automationi tellimuse kaudu täielikult toetab, .
Mida me õppisime
Viimase nelja aasta jooksul oleme palju õppinud võrgu automatiseerimise platvormi arendamise kohta. Seda õppisime ka kui platvormi artefakte kasutavad Ansible mänguraamatud ja lõppkasutajad rollides. Ja siin on see, mida me teada saime:
- Organisatsioonid ei automatiseeri mitte ainult ühe, vaid paljude müüjate seadmeid.
- Automatiseerimine pole mitte ainult tehniline, vaid ka kultuuriline nähtus.
- Võrkude mastaapne automatiseerimine on automatiseerimise projekteerimise põhiliste arhitektuuriliste põhimõtete tõttu keerulisem, kui tundub.
Kui arutasime üle aasta tagasi oma pikaajalisi kasvuplaane, küsisid meie ärikliendid järgmist:
- Faktide kogumine tuleb paremini standardida ja viia vastavusse automatiseerimise töövoogudega kõigis seadmetes.
- Seadme konfiguratsioonide värskendamine peab samuti olema standardiseeritud ja järjepidev, et Ansible moodulid saaksid pärast faktide kogumist hakkama tsükli teise poolega.
- Vajame rangeid ja toetatud meetodeid seadme konfiguratsiooni teisendamiseks struktureeritud andmeteks. Selle põhjal saab tõe allika võrguseadmest teisaldada.
Fakti parandused
Võrguseadmetest Ansible'i abil faktide kogumine toimub sageli juhuslikult. Veebipõhistel platvormidel on erineva tasemega faktide kogumise võimalused, kuid neil on vähe või üldse mitte ühtegi funktsiooni võtme-väärtuste paarides olevate andmete parsimiseks ja esituse standardiseerimiseks. Lugege Ken Celenza, kui raske ja valus võib olla faktiliste andmete analüüsimine ja standardimine.
Võib-olla olete märganud, et töötame Ansible Network Engine'i rolli kallal. Loomulikult on võrgumootori rollist 24 2.8 allalaadimist hiljem kiiresti saanud üks populaarsemaid Ansible rolle Ansible Galaxy võrgu automatiseerimise stsenaariumide jaoks. Enne kui me suure osa sellest Ansible 2.9-sse teisaldasime, et valmistuda Ansible XNUMX jaoks vajalikuks, andis see Ansible roll esimese tööriistakomplekti, mis aitas käske sõeluda, käske hallata ja võrguseadmete jaoks andmeid koguda.
Kui teate, kuidas võrgumootorit kasutada, on see väga tõhus viis faktiandmete kogumiseks, sõelumiseks ja standardiseerimiseks Ansible'is kasutamiseks. Selle rolli puuduseks on see, et iga platvormi ja kogu võrgutegevuse jaoks peate looma terve hulga parsereid. Et mõista, kui keeruline on parserite loomine, tarnimine ja hooldamine, vaadake Cisco meestelt.
Lühidalt, faktide hankimine seadmetest ja nende normaliseerimine võtme-väärtuste paarideks on mastaapse automatiseerimise jaoks hädavajalik, kuid selle saavutamine on keeruline, kui teil on palju tarnijaid ja võrguplatvorme.
Iga võrgufakti moodul versioonis Ansible 2.9 saab nüüd analüüsida võrguseadme konfiguratsiooni ja tagastada struktureeritud andmeid – ilma täiendavate teekide, Ansible rollide või kohandatud parseriteta.
Alates versioonist Ansible 2.9 täiustatakse iga värskendatud võrgumooduli väljalaskmisel faktimoodulit, et pakkuda andmeid konfiguratsiooni selle jaotise kohta. See tähendab, et faktide ja moodulite arendamine toimub nüüd samas tempos ja neil on alati ühine andmestruktuur.
Võrguseadme ressursside konfiguratsiooni saab hankida ja struktureeritud andmeteks teisendada kahel viisil. Mõlemal viisil saate uue märksõna abil koguda ja teisendada konkreetse ressursside loendi gather_network_resources. Ressursinimed vastavad moodulite nimedele, mis on väga mugav.
Fakte kogudes:
Märksõna kasutamine gather_facts saate vaadata praeguse seadme konfiguratsiooni käsiraamatu alguses ja seejärel kasutada seda kogu käsiraamatus. Määrake üksikud ressursid, mida seadmest alla laadida.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueVõib-olla olete nendes näidetes märganud midagi uut, nimelt - gather_facts: true on nüüd saadaval võrguseadmete natiivsete faktide kogumiseks.
Võrgufaktide mooduli otse kasutamine:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesMänguraamat tagastab liidese kohta järgmised 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: Ethernet1Pange tähele, kuidas Ansible hangib Arista seadmest algse konfiguratsiooni ja muudab selle struktureeritud andmeteks, mida kasutatakse standardsete võtme-väärtuste paaridena järgnevate ülesannete ja toimingute jaoks.
Liidese fakte saab lisada Ansible salvestatud muutujatele ja kasutada kohe või hiljem ressursimooduli sisendina eos_interfaces ilma täiendava töötlemise või muundamiseta.
Ressursimoodulid
Niisiis, oleme välja võtnud faktid, normaliseerinud andmed, sobitanud need standardiseeritud sisemise andmestruktuuri diagrammi ja meil on valmis tõeallikas. Hurraa! See on muidugi suurepärane, kuid siiski peame võtme-väärtuse paarid kuidagi tagasi teisendama konkreetse seadmeplatvormi ootuspärasesse konfiguratsiooni. Nüüd vajame nende uute faktide kogumise ja normaliseerimise nõuete täitmiseks platvormipõhiseid mooduleid.
Mis on ressursimoodul? Võite mõelda seadme konfiguratsioonisektsioonidele kui selle seadme pakutavatele ressurssidele. Võrguressursside moodulid on tahtlikult piiratud ühe ressursiga ja neid saab keeruliste võrguteenuste konfigureerimiseks laduda nagu ehitusplokke. Selle tulemusena on ressursimooduli nõuded ja spetsifikatsioonid loomulikult lihtsustatud, kuna ressursimoodul oskab lugeda и konfigureerida võrguseadmes konkreetne võrguteenus.
Et selgitada, mida ressursimoodul teeb, vaatame näiteraamatut, mis näitab idempodentlikku operatsiooni, kasutades uusi võrguressursside fakte ja moodulit 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.changedNagu näha, kantakse seadmest kogutud andmed teisendamata otse vastavasse ressursimoodulisse. Käivitamisel hangib mänguraamat seadmest väärtused ja võrdleb neid eeldatavate väärtustega. Selles näites on tagastatud väärtused ootuspärased (see tähendab, et see kontrollib konfiguratsiooni kõrvalekaldeid) ja annab teada, kas konfiguratsioon on muutunud.
Ideaalne viis konfiguratsiooni triivi tuvastamiseks on salvestada faktid Ansible'i salvestatud muutujatesse ja kasutada neid perioodiliselt koos ressursimooduliga kontrollirežiimis. See on lihtne meetod, et näha, kas keegi on väärtusi käsitsi muutnud. Enamikul juhtudel lubavad organisatsioonid muudatusi ja konfigureerimist käsitsi, kuigi paljud toimingud tehakse Ansible Automationi kaudu.
Mille poolest erinevad uued ressursimoodulid eelmistest?
Võrguautomaatika inseneri jaoks on Ansible 3 ja varasemate versioonide ressursimoodulite vahel kolm peamist erinevust.
1) Teatud võrguressursi (mida võib pidada ka konfiguratsiooniosa) jaoks arenevad moodulid ja faktid kõigis toetatud võrguoperatsioonisüsteemides samaaegselt. Arvame, et kui Ansible toetab ressursside konfigureerimist ühel võrguplatvormil, peaksime seda toetama kõikjal. See lihtsustab ressursimoodulite kasutamist, sest võrguautomaatika insener saab nüüd konfigureerida ressurssi (nt LLDP) kõigis algsete ja toetatud moodulitega võrguoperatsioonisüsteemides.
2) Ressursimoodulid sisaldavad nüüd olekuväärtust.
merged: konfiguratsioon liidetakse pakutava konfiguratsiooniga (vaikimisi);replaced: ressursi konfiguratsioon asendatakse pakutud konfiguratsiooniga;overridden: ressursi konfiguratsioon asendatakse pakutud konfiguratsiooniga; mittevajalikud ressursside eksemplarid kustutatakse;deleted: Ressursi konfiguratsioon kustutatakse/taastatakse vaikimisi.
3) Ressursimoodulid sisaldavad nüüd stabiilseid tagastusväärtusi. Kui võrguressursi moodul on võrguseadmes vajalikud muudatused teinud (või välja pakkunud), tagastab see esitusraamatusse samad võtme-väärtuste paarid.
before: konfiguratsioon seadmes struktureeritud andmete kujul enne ülesannet;after: kui seade on muutunud (või võib muutuda, kui kasutatakse testrežiimi), tagastatakse saadud konfiguratsioon struktureeritud andmetena;commands: mis tahes konfiguratsioonikäsud käivitatakse seadmes, et viia see soovitud olekusse.
Mida see kõik tähendab? Miks see oluline on?
See postitus hõlmab palju keerulisi kontseptsioone, kuid loodame, et lõpuks saate paremini aru, mida ettevõtte kliendid tegelikult nõuavad automatiseerimisplatvormi jaoks kogumist, andmete normaliseerimist ja silmuse konfigureerimist. Aga miks nad neid parandusi vajavad? Paljud organisatsioonid tegelevad praegu digitaalse ümberkujundamisega, et muuta oma IT-keskkonda paindlikumaks ja konkurentsivõimelisemaks. Paremal või halvemal juhul saavad paljud võrguinsenerid võrguarendajateks kas omakasu või juhtkonna korraldusel.
Organisatsioonid mõistavad, et üksikute võrgumallide automatiseerimine ei lahenda silode probleemi ja suurendab efektiivsust vaid teatud määral. Red Hat Ansible Automation Platform pakub rangeid ja normatiivseid ressursside andmemudeleid, et hallata programmiliselt võrguseadmes olevaid alusandmeid. See tähendab, et kasutajad loobuvad järk-järgult individuaalsetest konfigureerimismeetoditest, eelistades kaasaegsemaid meetodeid, keskendudes tehnoloogiatele (nt IP-aadressid, VLAN-id, LLDP jne), mitte konkreetsele müüja juurutamisele.
Kas see tähendab, et töökindlate ja end tõestanud käsumoodulite ja konfiguratsiooni päevad on loetud? Mitte mingil juhul. Eeldatavad võrguressursi moodulid ei ole rakendatavad kõigil juhtudel ega iga müüja jaoks, seega vajavad võrguinsenerid teatud rakenduste jaoks siiski käsu- ja konfiguratsioonimooduleid. Ressursimoodulite eesmärk on lihtsustada suuri Jinja malle ja normaliseerida struktureerimata seadmete konfiguratsioonid struktureeritud JSON-vormingusse. Ressursimoodulite abil on olemasolevatel võrkudel lihtsam muuta oma konfiguratsiooni struktureeritud võtme-väärtuse paarideks, mis kujutavad endast hõlpsasti loetavat tõeallikat. Struktureeritud võtme-väärtuse paare kasutades saate liikuda igas seadmes konfiguratsioonide käitamiselt sõltumatute struktureeritud andmetega töötamisele ja tuua võrgud infrastruktuuri-koodina lähenemisviisi esirinnas.
Millised ressursimoodulid tulevad Ansible Engine 2.9-sse?
Enne kui räägime teile üksikasjalikult, mis Ansible 2.9-s juhtub, meenutagem, kuidas jagasime kogu töö ulatuse.
Tuvastasime 7 kategooriat ja määrasime igaühele konkreetsed võrguressursid:
Märkus. Paksus kirjas ressursid kavandati ja rakendati Ansible 2.9-s.
Ettevõtlusklientidelt ja kogukonnalt saadud tagasiside põhjal oli loogiline esmalt käsitleda neid mooduleid, mis on seotud võrgu topoloogiaprotokollide, virtualiseerimise ja liidestega.
Järgmised ressursimoodulid töötas välja Ansible Networki meeskond ja need vastavad Red Hati toetatud platvormidele:
Järgmised moodulid on välja töötanud Ansible kogukond:
exos_lldp_global- Extreme Networksist.nxos_bfd_interfaces- Ciscostnxos_telemetry- Ciscost
Nagu näete, sobib ressursimoodulite kontseptsioon meie platvormikeskse strateegiaga. See tähendab, et me kaasame Ansiblesse endasse vajalikud võimalused ja funktsioonid, et toetada võrgumoodulite arendamisel standardimist ning samuti lihtsustada kasutajate tööd Ansible rollide ja mänguraamatute tasemel. Ressursimoodulite arendamise laiendamiseks andis Ansible meeskond välja tööriista Module Builder.
Ansible 2.10 ja uuemate versioonide plaanid
Kui Ansible 2.9 välja tuleb, töötame järgmise Ansible 2.10 ressursimoodulite komplekti kallal, mida saab kasutada võrgu topoloogia ja poliitika edasiseks konfigureerimiseks, nt. . Arengukava saab veel korrigeerida, seega kui teil on märkusi, andke sellest teada .
Ressursid ja alustamine
Allikas: www.habr.com