Prihajajoča izdaja Red Hat Ansible Engine 2.9 prinaša vznemirljive izboljšave, od katerih so nekatere obravnavane v tem članku. Kot vedno smo odprto razvijali izboljšave Ansible Network s podporo skupnosti. Pridružite se nam - poglejte in preuči razvojni načrt za na wiki strani za .
Kot smo nedavno objavili, zdaj vključuje Ansible Tower, Ansible Engine in vso vsebino Ansible Network. Danes so najbolj priljubljene omrežne platforme implementirane prek modulov Ansible. Na primer:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Brin Junos
- VyOS
Za popoln seznam platform, ki jih Red Hat v celoti podpira prek naročnine na Ansible Automation, .
Kaj smo se naučili
V zadnjih štirih letih smo se veliko naučili o razvoju platforme za avtomatizacijo omrežja. Tudi tega smo se naučili kot končni uporabniki uporabljajo artefakte platforme v knjigah in vlogah Ansible. In to smo ugotovili:
- Organizacije avtomatizirajo naprave ne samo enega, ampak številnih prodajalcev.
- Avtomatizacija ni le tehnični pojav, ampak tudi kulturni.
- Avtomatizacija omrežij v velikem obsegu je težje, kot se zdi zaradi temeljnih arhitekturnih načel načrtovanja avtomatizacije.
Ko smo pred več kot enim letom razpravljali o naših dolgoročnih načrtih rasti, so naše poslovne stranke zahtevale naslednje:
- Zbiranje dejstev je treba bolje standardizirati in uskladiti s poteki dela avtomatizacije v vseh napravah.
- Posodabljanje konfiguracij v napravi mora biti tudi standardizirano in dosledno, tako da moduli Ansible obravnavajo drugo polovico cikla po zbiranju dejstev.
- Potrebujemo stroge in podprte metode za pretvorbo konfiguracije naprave v strukturirane podatke. Na tej podlagi se lahko vir resnice premakne iz omrežne naprave.
Izboljšave dejstev
Zbiranje dejstev iz omrežnih naprav z uporabo Ansible se pogosto zgodi naključno. Spletne platforme imajo različne stopnje zmožnosti zbiranja dejstev, vendar imajo malo ali nič funkcionalnosti za razčlenjevanje in standardiziranje predstavitve podatkov v parih ključ-vrednost. Preberi Ken Celenza o tem, kako težko in boleče je lahko analizirati in standardizirati dejanske podatke.
Morda ste opazili, da delamo na vlogi Ansible Network Engine. Seveda je 24K prenosov kasneje vloga Network Engine hitro postala ena najbolj priljubljenih vlog Ansible v Ansible Galaxy za scenarije avtomatizacije omrežja. Preden smo velik del tega premaknili v Ansible 2.8, da bi se pripravili na tisto, kar bo potrebno v Ansible 2.9, je ta vloga Ansible zagotovila prvi niz orodij za pomoč pri razčlenjevanju ukazov, upravljanju ukazov in zbiranju podatkov za omrežne naprave.
Če znate uporabljati Network Engine, je to zelo učinkovit način za zbiranje, razčlenjevanje in standardiziranje podatkov o dejstvih za uporabo v Ansible. Pomanjkljivost te vloge je, da morate ustvariti cel kup razčlenjevalcev za vsako platformo in za vse omrežne aktivnosti. Če želite razumeti, kako težko je ustvariti, poslati in vzdrževati razčlenjevalnike, si oglejte od fantov iz Cisca.
Na kratko, pridobivanje dejstev iz naprav in njihova normalizacija v pare ključ-vrednost je bistveno za avtomatizacijo v velikem obsegu, vendar je to težko doseči, če imate veliko prodajalcev in omrežnih platform.
Vsak modul omrežnih dejstev v Ansible 2.9 lahko zdaj analizira konfiguracijo omrežne naprave in vrne strukturirane podatke – brez dodatnih knjižnic, vlog Ansible ali razčlenjevalnikov po meri.
Od Ansible 2.9 je vsakič, ko je izdan posodobljen omrežni modul, izboljšan modul dejstev, da zagotovi podatke o tem delu konfiguracije. To pomeni, da se razvoj dejstev in modulov zdaj odvija z enako hitrostjo in vedno bodo imeli skupno strukturo podatkov.
Konfiguracijo virov v omrežni napravi je mogoče pridobiti in pretvoriti v strukturirane podatke na dva načina. Na oba načina lahko zbirate in preoblikujete določen seznam virov z uporabo nove ključne besede gather_network_resources. Imena virov se ujemajo z imeni modulov, kar je zelo priročno.
Med zbiranjem dejstev:
Uporaba ključne besede gather_facts trenutno konfiguracijo naprave lahko pridobite na začetku priročnika in jo nato uporabite v celotnem priročniku. Določite posamezne vire, ki jih želite pridobiti iz naprave.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueMorda ste v teh primerih opazili nekaj novega, in sicer - gather_facts: true je zdaj na voljo za izvorno zbiranje dejstev za omrežne naprave.
Neposredna uporaba modula podatkov o omrežju:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesPriročnik 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: Ethernet1Opazite, kako Ansible pridobi izvorno konfiguracijo iz naprave Arista in jo pretvori v strukturirane podatke za uporabo kot standardne pare ključ-vrednost za nadaljnja opravila in operacije.
Dejstva vmesnika je mogoče dodati shranjenim spremenljivkam Ansible in uporabiti takoj ali pozneje kot vhod v modul virov eos_interfaces brez dodatne obdelave ali pretvorbe.
Moduli virov
Torej smo izluščili dejstva, normalizirali podatke, jih umestili v standardiziran notranji diagram strukture podatkov in imamo že pripravljen vir resnice. Hura! To je seveda super, vendar moramo še vedno nekako pretvoriti pare ključ-vrednost nazaj v specifično konfiguracijo, ki jo pričakuje določena platforma naprave. Zdaj potrebujemo module, specifične za platformo, da izpolnimo te nove zahteve glede zbiranja dejstev in normalizacije.
Kaj je modul virov? Konfiguracijske razdelke naprave si lahko predstavljate kot vire, ki jih zagotavlja ta naprava. Moduli omrežnih virov so namerno omejeni na en sam vir in jih je mogoče zložiti kot gradnike za konfiguracijo kompleksnih omrežnih storitev. Posledično so zahteve in specifikacije za modul virov naravno poenostavljene, saj lahko modul virov bere и konfigurirati določeno omrežno storitev v omrežni napravi.
Za razlago, kaj počne modul virov, si oglejmo primer priročnika, ki prikazuje idempodentno operacijo z uporabo novih dejstev o omrežnih virih 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 lahko vidite, se podatki, zbrani iz naprave, prenesejo neposredno v ustrezen modul virov brez pretvorbe. Ko se zažene, playbook pridobi vrednosti iz naprave in jih primerja s pričakovanimi vrednostmi. V tem primeru so vrnjene vrednosti takšne, kot so pričakovane (to pomeni, preverja odstopanja od konfiguracije) in poroča, ali se je konfiguracija spremenila.
Idealen način za zaznavanje konfiguracijskega premika je shranjevanje dejstev v shranjene spremenljivke Ansible in njihovo občasno uporabo z modulom virov v načinu pregleda. To je preprosta metoda za ugotavljanje, ali je nekdo ročno spremenil vrednosti. V večini primerov organizacije dovoljujejo spremembe in konfiguracijo ročno, čeprav se številne operacije izvajajo prek Ansible Automation.
Kako se novi moduli virov razlikujejo od prejšnjih?
Za inženirja za avtomatizacijo omrežja obstajajo 3 glavne razlike med moduli virov v Ansible 2.9 in prejšnjih različicah.
1) Za dani omrežni vir (ki ga lahko razumemo tudi kot konfiguracijski del) se bodo moduli in dejstva razvijali v vseh podprtih omrežnih operacijskih sistemih hkrati. Menimo, da če Ansible podpira konfiguracijo virov na eni omrežni platformi, bi jo morali podpirati povsod. To poenostavlja uporabo modulov virov, ker lahko inženir za avtomatizacijo omrežja zdaj konfigurira vir (kot je LLDP) v vseh omrežnih operacijskih sistemih z izvornimi in podprtimi moduli.
2) Moduli virov zdaj vključujejo vrednost stanja.
merged: konfiguracija je združena s podano konfiguracijo (privzeto);replaced: Konfiguracija vira bo zamenjana s podano konfiguracijo;overridden: Konfiguracija vira bo zamenjana s podano konfiguracijo; nepotrebni primerki virov bodo izbrisani;deleted: Konfiguracija vira bo izbrisana/obnovljena na privzeto.
3) Moduli virov zdaj vključujejo stabilne povratne vrednosti. Ko modul omrežnih virov izvede (ali predlaga) potrebne spremembe v omrežni napravi, vrne iste pare ključ-vrednost v priročnik.
before: konfiguracija na napravi v obliki strukturiranih podatkov pred nalogo;after: če se je naprava spremenila (ali se lahko spremeni, če je uporabljen preskusni način), bo nastala konfiguracija vrnjena kot strukturirani podatki;commands: Vsi konfiguracijski ukazi se izvajajo v napravi, da jo spravijo v želeno stanje.
Kaj vse to pomeni? Zakaj je pomembno?
Ta objava zajema veliko zapletenih konceptov, vendar upamo, da boste na koncu bolje razumeli, kaj odjemalci podjetij zahtevajo v resnici zbiranje, normalizacija podatkov in konfiguracija zanke za platformo za avtomatizacijo. Toda zakaj potrebujejo te izboljšave? Številne organizacije si zdaj prizadevajo za digitalno preobrazbo, da bi postala njihova okolja IT bolj prožna in konkurenčna. V dobrem ali slabem, mnogi omrežni inženirji postanejo omrežni razvijalci bodisi iz lastnega interesa ali po naročilu vodstva.
Organizacije ugotavljajo, da avtomatizacija posameznih omrežnih predlog ne reši problema silosov in le do določene mere poveča učinkovitost. Platforma za avtomatizacijo Red Hat Ansible zagotavlja stroge in normativne podatkovne modele virov za programsko upravljanje osnovnih podatkov v omrežni napravi. To pomeni, da uporabniki postopoma opuščajo individualne metode konfiguracije v korist sodobnejših metod s poudarkom na tehnologijah (na primer naslovi IP, VLAN, LLDP itd.), ne pa na implementacijo določenega proizvajalca.
Ali to pomeni, da so zanesljivim in preverjenim ukaznim modulom in konfiguracijam šteti dnevi? V nobenem primeru. Pričakovani moduli omrežnih virov ne bodo uporabni v vseh primerih ali za vsakega prodajalca, zato bodo omrežni inženirji še vedno potrebovali ukazne in konfiguracijske module za določene izvedbe. Namen modulov virov je poenostaviti velike predloge Jinja in normalizirati nestrukturirane konfiguracije naprav v strukturiran format JSON. Z moduli virov bo obstoječim omrežjem lažje preoblikovati svojo konfiguracijo v strukturirane pare ključ-vrednost, ki predstavljajo lahko berljiv vir resnice. Z uporabo strukturiranih parov ključ-vrednost se lahko premaknete z izvajanja konfiguracij na vsaki napravi na delo z neodvisnimi strukturiranimi podatki in postavite omrežja v ospredje pristopa infrastrukture kot kode.
Kateri moduli virov bodo prišli v Ansible Engine 2.9?
Preden vam podrobno povemo, kaj se bo zgodilo v Ansible 2.9, se spomnimo, kako smo razdelili celoten obseg dela.
Identificirali smo 7 kategorij in vsaki dodelili posebne omrežne vire:
Opomba: Viri v krepkem tisku so bili načrtovani in implementirani v Ansible 2.9.
Na podlagi povratnih informacij poslovnih strank in skupnosti je bilo logično, da se najprej lotimo tistih modulov, povezanih s protokoli topologije omrežja, virtualizacijo in vmesniki.
Naslednje module virov je razvila skupina Ansible Network in ustrezajo platformam, ki jih podpira Red Hat:
Naslednje module je razvila skupnost Ansible:
exos_lldp_global- iz Extreme Networks.nxos_bfd_interfaces- iz podjetja Cisconxos_telemetry- iz podjetja Cisco
Kot lahko vidite, koncept modulov virov ustreza naši strategiji, osredotočeni na platformo. To pomeni, da v sam Ansible vključimo potrebne zmožnosti in funkcije za podporo standardizacije pri razvoju omrežnih modulov in tudi za poenostavitev dela uporabnikov na ravni vlog Ansible in playbooks. Da bi razširili razvoj modulov virov, je ekipa Ansible izdala orodje Module Builder.
Načrti za Ansible 2.10 in naprej
Ko bo Ansible 2.9 izdan, bomo delali na naslednjem nizu modulov virov za Ansible 2.10, ki jih je mogoče uporabiti za nadaljnjo konfiguracijo omrežne topologije in politike, npr. . Razvojni načrt je še mogoče prilagoditi, tako da če imate pripombe, jih sporočite na .
Viri in začetek
Vir: www.habr.com