🥇The Inside Playbook. Mrežne funkcije u novom Ansible Engine 2.9

U nadolazećem izdanju Red Hat Ansible Engine 2.9 očekuju vas impresivna poboljšanja, od kojih su neka opisana u ovom članku. Kao i obično, razvijali smo poboljšanja Ansible Network otvoreno, uz podršku zajednice. Pridružite se — zavirite na tablicu zadataka na GitHubu i istražite plan razvoja za izdanje Red Hat Ansible Engine 2.9 na wiki stranici za Ansible Network.

Kao što smo nedavno objavili, Red Hat Ansible Automation Platform sada uključuje Ansible Tower, Ansible Engine i sav sadržaj Ansible Network. Sada se većina popularnih mrežnih platformi implementira putem Ansible modula. Na primjer:

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

Cijeli popis platformi koje Red Hat potpuno podržava putem Ansible Automation pretplate objavljen je ovdje.

Što smo naučili

U posljednje četiri godine puno smo naučili o razvoju platforme za automatizaciju mreže. Također smo saznali o tome, kao kako se artefakti platforme koriste u Ansible playbookovima i rolama od strane krajnjih korisnika. I evo što smo otkrili:

Organizacije ne automatiziraju samo uređaje jednog, već mnogih dobavljača.
Automatizacija nije samo tehnička pojava, već i kulturna.
Opsežna automatizacija mreža složenija je nego što se čini, zbog temeljnih arhitektonskih načela dizajniranja automatizacije.

Kada smo razgovarali o našim dugoročnim razvojnim planovima prije više od godine dana, naši klijenti iz korporativnog sektora tražili su sljedeće:

Prikupljanje podataka treba bolje standardizirati i uskladiti s radnim procesom automatizacije za bilo koje uređaje.
Ažuriranje konfiguracija na uređaju također treba standardizirati i uskladiti, tako da Ansible moduli obrađuju drugu polovicu ciklusa nakon prikupljanja podataka.
Potrebne su stroge i podržane metode pretvaranja konfiguracije uređaja u strukturirane podatke. Na toj osnovi izvor istine može se premjestiti s mrežnog uređaja.

Poboljšanja podataka

Prikupljanje podataka s mrežnih uređaja pomoću Ansible-a često se događa nasumično. Mrežne platforme su različito opremljene mogućnostima prikupljanja podataka, no gotovo da nemaju — ili čak uopće nemaju — funkcije za parsiranje i standardizaciju prikaza podataka u parovima ključ-vrijednost. Pročitajte post Kena Selenzu (Ken Celenza) o tome koliko može biti teško i mučno analizirati i standardizirati podatke.

Možda ste primijetili kako smo radili na Ansible Network Engine ulozi. Naravno, nakon 24 tisuće preuzimanja, Network Engine uloga brzo je postala jedna od najpopularnijih Ansible uloga u Ansible Galaxy za automatizacijske skripte za mreže. Prije nego što smo puno toga prenijeli u Ansible 2.8, kako bismo se pripremili za ono što će biti potrebno u Ansible 2.9, ova Ansible uloga omogućila je prvi set alata za pomoć u analiziranju komandi, upravljanju timovima i prikupljanju podataka za mrežne uređaje.

Ako ste upoznati s korištenjem Network Engine-a, to je vrlo učinkovit način prikupljanja, analiziranja i standardizacije podataka za upotrebu u Ansible-u. Nedostatak ove uloge je to što morate izraditi cijeli niz parsera za svaku platformu i za svu mrežnu aktivnost. Da biste shvatili koliko je teško izraditi, isporučiti i održavati parsere, pogledajte više od 1200 parsera od ekipe iz Cisca.

U nekoliko riječi, za masovnu automatizaciju vrlo je važno dobiti činjenice s uređaja i normalizirati ih u parove ključ-vrijednost, ali to je teško postići kada imate mnogo dobavljača i mrežnih platformi.

Svaki modul mrežnih činjenica u Ansible 2.9 sada može analizirati konfiguraciju mrežnog uređaja i vraćati strukturirane podatke — bez dodatnih biblioteka, Ansible uloga ili prilagođenih parsera.

Počevši od Ansible 2.9, pri svakom izdanju ažuriranog mrežnog modula, modul činjenica se poboljšava kako bi pružio podatke o ovom dijelu konfiguracije. To znači da se razvoj činjenica i modula sada odvija istom brzinom, a uvijek će imati istu strukturu podataka.

Konfiguraciju resursa na mrežnom uređaju možete izvući i pretvoriti u strukturirane podatke na dva načina. Oba načina omogućavaju prikupljanje i pretvaranje određenog popisa resursa pomoću nove ključne riječi gather_network_resources. Imena resursa odgovaraju imenima modula, što je vrlo praktično.

Tijekom prikupljanja činjenica:

S pomoću ključne riječi gather_facts možete izvući trenutnu konfiguraciju uređaja na početku playbook-a, a zatim je koristiti tijekom cijelog playbook-a. Odredite pojedinačne resurse koje treba izvući s uređaja.

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

Možda ste primijetili nešto novo u ovim primjerima, naime — gather_facts: true sada dostupno za nativno prikupljanje činjenica za mrežne uređaje.

Korištenje modula za mrežne činjenice izravno:

- name: prikupljanje činjenica o konfiguraciji sučelja
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

Playbook vraća sljedeće činjenice o sučelju:

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

Obratite pažnju kako Ansible izvlači nativnu konfiguraciju s Arista uređaja i pretvara je u strukturirane podatke, kako bi se koristili kao standardni parovi ključ-vrijednost za sljedeće zadatke i operacije.

Činjenice o sučelju mogu se dodati u pohranjene varijable Ansible i koristiti odmah ili kasnije kao ulaz za modul resursa eos_interfaces bez dodatnog liječenja ili transformacije.

Moduli resursa

Dakle, izvukli smo činjenice, normalizirali podatke, uvrstili ih u standardiziranu internu shemu podataka i dobili gotov izvor istine. Hura! To je, naravno, sjajno, ali još uvijek nam treba neki način da transformiramo parove ključ-vrijednost natrag u specifičnu konfiguraciju koju očekuje određena platforma uređaja. Sada su nam potrebni moduli za specifične platforme kako bismo zadovoljili ove nove zahtjeve za prikupljanje činjenica i normalizaciju.

Što je modul resursa? Odjeljci konfiguracije uređaja mogu se smatrati resursima koje ovaj uređaj pruža. Moduli mrežnih resursa namjerno su ograničeni na jedan resurs, a mogu se složiti poput kocaka za konfiguraciju složenih mrežnih usluga. Kao rezultat, zahtjevi i specifikacija za modul resursa prirodno se pojednostavljuju, jer modul resursa može čitati i konfigurirati određenu mrežnu uslugu na mrežnom uređaju.

Da bismo objasnili što radi modul resursa, pogledajmo primjer playbooka koji prikazuje idempotentnu operaciju s korištenjem novih činjenica mrežnog resursa i modula eos_l3_interface.

- name: primjer činjenica koje se vraćaju na uređaj.
  hosts: arista
  gather_facts: false
  tasks:
  - name: dohvatiti arista eos činjenice
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

  - name: osigurati da su informacije o IP adresi tačne
    eos_l3_interfaces:
      config: "{{ ansible_network_resources['l3_interfaces'] }}"
      register: result

  - name: osigurati da se konfiguracija nije promenila
    assert:
      that: not result.changed

Kao što vidite, podaci prikupljeni sa uređaja prenose se direktno u odgovarajući modul resursa bez transformacije. Kada se pokrene playbook, izvlače se vrednosti sa uređaja i porede sa očekivanim. U ovom primeru dobijene vrednosti odgovaraju očekivanim (tj. izvršava se provera odstupanja konfiguracije) i prikazuje se poruka da li se konfiguracija promenila.

Idealni način za otkrivanje odstupanja konfiguracije je čuvanje činjenica u sačuvanim Ansible promenljivama i povremeno korišćenje istih sa modulom resursa u režimu provere. Ovo je jednostavan način da se vidi da li je neko ručno promenio vrednosti. U većini slučajeva organizacije dopuštaju ručne izmene i konfiguraciju, iako se mnoge operacije izvode putem Ansible automatizacije.

Kako se novi moduli resursa razlikuju od prethodnih?

Za inženjera mrežne automatizacije postoje 3 glavne razlike između modula resursa u Ansible 2.9 i prethodnih verzija.

1) Za određeni mrežni resurs (koji se takođe može zamisliti kao deo konfiguracije) moduli i činjenice će se razvijati u svim podržanim mrežnim operativnim sistemima simultano. Smatramo da, ako Ansible podržava konfiguraciju resursa na jednoj mrežnoj platformi, trebamo je podržati svuda. Ovo pojednostavljuje korišćenje modula resursa, jer inženjer mrežne automatizacije sada može da konfiguriše resurs (npr. LLDP) u svim mrežnim operativnim sistemima sa nativnim i podržanim modulima.

2) Moduli resursa sada uključuju vrednost stanja.

merged: konfiguracija je spojena sa pruženom konfiguracijom (podrazumevano);
replaced: konfiguracija resursa će biti zamenjena pruženom konfiguracijom;
overridden: konfiguracija resursa će biti zamenjena pruženom konfiguracijom; suvišne instance resursa će biti uklonjene;
deleted: konfiguracija resursa će biti uklonjena/obnovljena prema podrazumevanju.

3) Moduli resursa sada uključuju stabilne vraćene vrijednosti. Kada modul mrežnog resursa izvrši (ili predloži) potrebne promjene na mrežnom uređaju, vraća iste parove ključ-vrijednost u playbook.

before: konfiguracija na uređaju u obliku strukturiranih podataka do zadatka;
nakon: ako se uređaj promijenio (ili bi mogao da se promijeni, ako se koristi način provjere), konačna konfiguracija će biti vraćena u obliku strukturiranih podataka;
komande: sve komande konfiguracije pokrenute na uređaju kako bi se doveo u željeno stanje.

Što to sve znači? Zašto je to važno?

Ovaj post opisuje mnoge složene koncepcije, ali se nadamo da ćete na kraju bolje razumjeti što korporativni klijenti traže u vezi s prikupljanjem činjenica, normalizacijom podataka i konfiguracijskim ciklusom za platformu automatizacije. Ali zašto su im potrebna ova poboljšanja? Mnoge organizacije trenutno prolaze kroz digitalnu transformaciju kako bi učinile svoja IT okruženja fleksibilnijima i konkurentnijima. To je dobro ili loše, ali mnogi mrežni inženjeri postaju mrežni programeri — iz vlastitog zanimanja ili po nalogu rukovoditelja.

Organizacije shvaćaju da automatizacija pojedinačnih mrežnih predložaka ne rješava problem razdvojenosti i povećava efikasnost samo do određenog nivoa. Red Hat Ansible Automation Platform pruža rigorozne i normirane modele podataka o resursima za programsko upravljanje osnovnim podacima na mrežnom uređaju. To jest, korisnici postupno odustaju od individualnih načina konfiguracije u korist modernijih metoda s naglaskom na tehnologiji (npr. IP adrese, VLAN, LLDP itd.), umjesto na konkretnoj implementaciji dobavljača.

Znači li to da su dani pouzdanih i provjerenih modula za upravljanje i konfiguraciju odbrojani? Ni slučajno. Očekivani moduli mrežnih resursa neće se primjenjivati u svim slučajevima i za svakog dobavljača, tako da će moduli za upravljanje i konfiguraciju još uvijek biti potrebni mrežnim inženjerima za određene implementacije. Cilj modula resursa je pojednostaviti velike Jinja predloške i normalizirati nestrukturirane konfiguracije uređaja u strukturirani JSON format. Uz module resursa, postojećim mrežama bit će lakše pretvoriti svoje konfiguracije u strukturirane parove ključ-vrijednost, koji će predstavljati lako čitljiv izvor istine. Korištenjem strukturiranih parova ključ-vrijednost, moguće je prijeći s pokretanja konfiguracija na svakom uređaju na rad s neovisnim strukturiranim podacima i staviti mreže u fokus s pristupom „infrastruktura kao kod“.

Koji će se moduli resursa pojaviti u Ansible Engine 2.9?

Prije nego što detaljno objasnimo što će biti u Ansible 2.9, prisjetimo se kako smo podijelili sav obim posla.

Izdvojili smo 7 kategorija i svakoj dodijelili određene mrežne resurse:

Napomena: resursi istaknuti podebljano planirani su i implementirani u Ansible 2.9.
Na temelju povratnih informacija od korporativnih klijenata i zajednice, logično je bilo prvo se posvetiti onim modulima koji su povezani s protokolima topologije mreže, virtualizacijom i sučeljima.
Sljedeći moduli resursa razvijeni su od strane Ansible Network tima i odgovaraju platformama koje podržava Red Hat:

Sljedeći moduli razvijeni su od strane Ansible zajednice:

exos_lldp_global — od Extreme Networks.
nxos_bfd_interfaces — od Cisco
nxos_telemetry — od Cisco

Kao što vidite, koncept modula resursa uklapa se u našu strategiju orijentacije na platforme. Dakle, uključujemo potrebne mogućnosti i funkcije direktno u Ansible kako bismo podržali standardizaciju prilikom razvoja mrežnih modula, a također olakšali rad korisnicima na razini uloga i Ansible playbooka. Kako bismo proširili razvoj modula resursa, Ansible tim je lansirao alat Module Builder.

Planovi za Ansible 2.10 i dalje

Nakon objavljivanja Ansible 2.9, usredotočit ćemo se na sljedeći set modula resursa za Ansible 2.10, koji će se moći koristiti za daljnje prilagodbe topologije i politike mreže, poput ACL, OSPF i BGPPlan razvoja još uvijek se može prilagoditi, pa ako imate komentare, obavijestite nas u Ansible Network zajednici.