V prihajajočem izdaji Red Hat Ansible Engine 2.9 vas čakajo osupljiva izboljšanja, nekatere od teh pa so opisane v tem članku. Kot ponavadi smo izboljšave Ansible Network razvijali odprto ob podpori skupnosti. Pridružite se — pokukajte v in raziščite načrt razvoja za na wiki strani za .
Kot smo nedavno napovedali, sedaj vključuje Ansible Tower, Ansible Engine in vso vsebino Ansible Network. Trenutno večina priljubljenih omrežnih platform deluje prek Ansible modulov. Na primer:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Celoten seznam platform, ki jih Red Hat v celoti podpira prek naročnine Ansible Automation, .
Česar smo se naučili
V zadnjih štirih letih smo se veliko naučili o razvoju platforme za avtomatizacijo omrežij. Prav tako smo se naučili, kako kako se artefakti platforme uporabljajo v Ansible načrtih in vlogah s strani končnih uporabnikov. In to, kar smo ugotovili:
- Organizacije avtomatizirajo naprave številnih dobaviteljev, ne le enega.
- Avtomatizacija ni le tehnična, temveč tudi kulturna stvar.
- Obsežna avtomatizacija omrežij je težja, kot se zdi, zaradi temeljnih arhitekturnih načel oblikovanja avtomatizacije.
Ko smo pred več kot letom razpravljali o naših dolgoročnih načrtih razvoja, so naši korporativni kupci zahtevali naslednje:
- Zbiranje dejstev je treba bolje standardizirati in uskladiti z delovnimi procesi avtomatizacije za vse naprave.
- Posodabljanje konfiguracij na napravi je treba prav tako standardizirati in uskladiti, da lahko Ansible moduli obdelujejo drugo polovico cikla po zbiranju dejstev.
- Potrebne so stroge in podprte metode pretvarjanja konfiguracije naprave v strukturirane podatke. Na tej podlagi se lahko vir resnice premakne z omrežne naprave.
Izboljšave dejstev
Zbiranje dejstev z omrežnih naprav z Ansible pogosto poteka na slepo. Omrežne platforme so različno opremljene z močmi za zbiranje dejstev, vendar skoraj nimajo — ali pa sploh nimajo — funkcij za razčlenjevanje in standardizacijo prikaza podatkov v parih ključ-vrednost. Preberite Kena Selenza (Ken Celenza) o tem, kako težko in mučno je lahko analizirati in standardizirati podatke dejstev.
Morda ste opazili, kako smo delali na vlogi Ansible Network Engine. Seveda je ta vloga Network Engine postala ena najbolj priljubljenih vlog Ansible v Ansible Galaxy za scenarije avtomatizacije omrežja, po 24 tisoč prenosih. Preden smo veliko tega prenesli v Ansible 2.8, da bi se pripravili na tisto, kar bo potrebno v Ansible 2.9, je ta vloga Ansible prva nabor orodij za pomoč pri analiziranju ukazov, upravljanju skupin in zbiranju podatkov za omrežne naprave.
Če poznate uporabo Network Engine, je to zelo učinkovit način za zbiranje, analizo in standardizacijo podatkov dejstev za uporabo v Ansible. Slaba stran te vloge je, da je potrebno ustvariti celo množico parserjev za vsako platformo in za vse omrežne aktivnosti. Da bi razumeli, kako zahtevno je ustvariti, dobaviti in vzdrževati parserje, si oglejte od fantov iz Cisco.
Na kratko, za obsežno avtomatizacijo je zelo pomembno pridobiti dejstva iz naprav in jih normalizirati v pare ključ-vrednost, toda to je težko doseči, ko imate veliko ponudnikov in omrežnih platform.
Vsak modul dejstev omrežja v Ansible 2.9 zdaj lahko analizira konfiguracijo omrežne naprave in vrne strukturirane podatke — brez dodatnih knjižnic, vlog Ansible ali lastnih parserjev.
Začelo se je z Ansible 2.9, pri vsakem izdaji posodobljenega omrežnega modula se modul dejstev izboljšuje, da zagotovi podatke o tem delu konfiguracije. To pomeni, da se razvoj dejstev in modulov zdaj odvija v enakem ritmu, in vedno bodo imeli skupno strukturo podatkov.
Konfiguracijo virov na omrežni napravi je mogoče izvleči in pretvoriti v strukturirane podatke na dva načina. Obe metodi omogočata zbiranje in pretvarjanje določenega seznama virov z novim ključnim besedilom gather_network_resources. Imena virov ustrezajo imenom modulov, kar je zelo priročno.
Med zbiranjem dejstev:
S pomočjo ključnega besedila gather_facts lahko izvlečete trenutno konfiguracijo naprave na začetku playbooka in jo nato uporabite skozi celoten playbook. Določite posamezne vire, ki jih je treba izvleči iz naprave.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueMorda ste opazili kaj novega v teh primerih, in sicer — gather_facts: true zdajemo na voljo za nativno zbiranje dejstev za omrežne naprave.
Uporaba modula omrežnih dejstev neposredno:
- ime: zberi dejstva o konfiguraciji vmesnika
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesPlevelbook vrne naslednja dejstva o vmesniku:
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: Ethernet1Upoštevajte, kako Ansible pridobiva nativno konfiguracijo z naprave Arista in jo pretvori v strukturirane podatke za uporabo kot standardne pare ključ-vrednost za nadaljnje naloge in operacije.
Dejstva o vmesnikih je mogoče dodati v shranjene spremenljivke Ansible in jih uporabiti takoj ali kasneje kot vhodne podatke za modul virov eos_interfaces brez dodatne obdelave ali pretvorbe.
Moduli virov
Torej, pridobili smo dejstva, normalizirali podatke, jih vpisali v standardizirano notranjo shemo strukture podatkov in dobili pripravljen vir resnice. Hura! To je seveda odlično, a še vedno moramo nekako pretvoriti pare ključ-vrednost nazaj v specifično konfiguracijo, ki jo pričakuje konkretna platforma naprave. Zdaj potrebujemo module za določene platforme, da zadovoljimo te nove zahteve za zbiranje dejstev in normalizacijo.
Kaj je modul virov? Odseke konfiguracije naprave si lahko predstavljamo kot vire, ki jih ta naprava zagotavlja. Moduli omrežnih virov so namenoma omejeni na en vir in jih je mogoče sestavljati, kot opeke, za prilagoditev zapletenih omrežnih storitev. Posledično se zahteve in specifikacije za modul virov naravno poenostavijo, saj modul virov lahko bere in konfiguracijo določenega omrežnega servisa na omrežni napravi.
Da pojasnimo, kaj počne modul virov, si poglejmo primer pllevelbooka, ki prikazuje idempotentno operacijo z uporabo novih dejstev omrežnega vira in modula 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.changedKot vidiš, zbrani podatki z naprave so neposredno preneseni v ustrezen modul virov brez pretvorbe. Ko se izvaja playbook, se vrednosti pridobijo z naprave in primerjajo s pričakovanimi. V tem primeru so pridobljene vrednosti skladne s pričakovanimi (to pomeni, da se preverja odstopanje konfiguracije) in izdano je sporočilo, ali se je konfiguracija spremenila.
Idealen način odkrivanja odstopanja konfiguracije je shranjevanje dejstev v spremenljivke Ansible in občasno njihova uporaba skupaj z modulom virov v načinu preverjanja. To je preprost način za opazovanje, ali je kdo ročno spremenil vrednosti. V večini primerov organizacije dovoljujejo ročne spremembe in konfiguracijo, čeprav se mnoge operacije izvajajo prek Ansible Automation.
Kaj se razlikuje na novih modulih virov v primerjavi s prejšnjimi?
Za inženirja omrežne avtomatizacije obstajajo 3 glavne razlike med moduli virov v Ansible 2.9 in prejšnjimi različicami.
1) Za določen omrežni vir (kar si lahko predstavljamo tudi kot del konfiguracije) se bodo moduli in dejstva razvijali v vseh podprtih omrežnih operacijskih sistemih hkrati. Menimo, da če Ansible podpira konfiguracijo vira na eni omrežni platformi, bi jo morali podpirati povsod. To poenostavi uporabo modulov virov, saj lahko inženir omrežne avtomatizacije zdaj nastavi vir (kot je LLDP) v vseh omrežnih operacijskih sistemih z naravnimi in podprtimi moduli.
2) Moduli virov zdaj vključujejo vrednost stanja.
merged: konfiguracija je združena z dano konfiguracijo (privzeto);replaced: konfiguracija virov bo zamenjana z dano konfiguracijo;: konfiguracija virov bo zamenjana z dano konfiguracijo; odvečna primerka virov bodo odstranjeni;: konfiguracija virov bo odstranjena/obnovljena po defaultu.deleted: konfiguracija virov bo odstranjena/obnovljena po privzetku.
3) Moduli virov zdaj vključujejo stabilne vrnjene vrednosti. Ko virov modul v omrežju izvede (ali predlaga) potrebne spremembe v omrežni napravi, vrne iste pare ključ-vrednost v playbook.
before: konfiguracija na napravi v obliki strukturiranih podatkov do naloge;po: če se je naprava spremenila (ali se lahko spremeni, če je vklopljen način preverjanja), bo rezultat konfiguracije vrnjen v obliki strukturiranih podatkov;ukazi: vse konfiguracijske ukaze, ki so izvajani na napravi, da jo pripeljejo v želeno stanje.
Kaj to vse pomeni? Zakaj je pomembno?
V tem prispevku je opisanih veliko zapletenih konceptov, a upamo, da boste na koncu bolje razumeli, kaj korporativni klienti zahtevajo glede zbiranja dejstev, normalizacije podatkov in konfiguracije cikla za platformo avtomatizacije. Ampak zakaj potrebujejo te izboljšave? Veliko organizacij trenutno izvaja digitalno transformacijo, da bi svoje IT okolje naredili bolj prilagodljivo in konkurenčno. Dobro ali slabo, mnogi omrežni inženirji postajajo omrežni razvijalci — iz lastnega zanimanja ali po nalogu vodstva.
Organizacije razumejo, da avtomatizacija posameznih omrežnih predlog ne rešuje težave razpršenosti in povečuje učinkovitost samo do določene meje. Platforma Red Hat Ansible Automation Platform nudi stroge in normativne modele podatkov virov za programatsko upravljanje osnovnih podatkov na omrežni napravi. To pomeni, da uporabniki postopoma opuščajo individualne načine konfiguracije v prid modernižiranjim metodam z osredotočenostjo na tehnologije (kot so IP naslovi, VLAN, LLDP ipd.), ne pa na konkretne izvedbe proizvajalca.
Ali to pomeni, da so dnevi zanesljivih in preverjenih modulov ukazov in konfiguracij šteti? Nedvomno ne. Pričakovani moduli omrežnih virov ne bodo uporabni v vseh primerih in ne za vsakega ponudnika, zato bodo moduli ukazov in konfiguracij še vedno potrebni omrežnim inženirjem za določene realizacije. Namen modulov virov je poenostaviti velike predloge Jinja in normalizirati nestrukturirane konfiguracije naprav v strukturiran JSON format. Z moduli virov bodo obstoječa omrežja lažje pretvorila svoje konfiguracije v strukturirane pare ključ-vrednost, ki bodo predstavljali enostavno berljiv vir resnice. S strukturiranimi pari ključ-vrednost se lahko preide od izvajanja konfiguracij na vsaki napravi k delu z neodvisnimi strukturiranimi podatki ter omrežja postavi v ospredje v pristopu „infrastruktura kot koda“.
Katere module virov bo prinesel Ansible Engine 2.9?
Preden podrobno opišemo, kaj bo v Ansible 2.9, si poglejmo, kako smo razdelili celoten obseg dela.
Opredelili smo 7 kategorij in vsaki dodelili določene omrežne vire:
Opomba: Viri, označeni s krepko, so bili načrtovani in izvedeni v Ansible 2.9.
Na podlagi povratnih informacij od podjetij in skupnosti je bilo smiselno najprej obravnavati tiste module, ki so povezani s protokoli omrežne topologije, virtualizacijo in vmesniki.
Naslednji moduli virov so razviti s strani ekipe Ansible Network in podpirajo platforme, ki jih navaja Red Hat:
Naslednji moduli so razviti s strani skupnosti Ansible:
exos_lldp_global— od Extreme Networks.nxos_bfd_interfaces— od Cisconxos_telemetry— od Cisco
Kot vidite, koncept modulov virov ustreza naši strategiji usmerjanja na platforme. To pomeni, da vključujemo potrebne možnosti in funkcije neposredno v Ansible, da podpiramo standardizacijo pri razvoju omrežnih modulov ter hkrati poenostavimo delo uporabnikov na ravni vlog in Ansible playbookov. Da bi razširili razvoj modulov virov, je ekipa Ansible izdala orodje Module Builder.
Načrti za Ansible 2.10 in naprej
Po izidu Ansible 2.9 se bomo osredotočili na naslednji nabor modulov virov za Ansible 2.10, ki jih bo mogoče uporabiti za dodatno prilagajanje topologije in politike omrežja, na primer Načrt razvoja je še vedno mogoče prilagoditi, zato, če imate komentarje, nam jih sporočite v .
Viri in začetek dela
Izvor: habr.com
