Versiunea viitoare a Red Hat Ansible Engine 2.9 aduce îmbunătățiri interesante, dintre care unele sunt discutate în acest articol. Ca întotdeauna, am dezvoltat în mod deschis îmbunătățirile Ansible Network, cu sprijinul comunității. Alăturați-vă nouă - aruncați o privire la și studiază planul de dezvoltare pentru pe pagina wiki pentru .
După cum am anunțat recent, acum include Ansible Tower, Ansible Engine și tot conținutul Ansible Network. În zilele noastre, cele mai populare platforme de rețea sunt implementate prin modulele Ansible. De exemplu:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Junosul Junos
- VyOS
Pentru o listă completă a platformelor care sunt pe deplin acceptate de Red Hat prin abonamentul Ansible Automation, .
Ce am învățat
În ultimii patru ani, am învățat multe despre dezvoltarea unei platforme de automatizare a rețelei. Am învățat și asta ca Artefactele platformei sunt folosite în manualele și roluri Ansible de către utilizatorii finali. Și iată ce am aflat:
- Organizațiile automatizează dispozitivele nu doar de la unul, ci de la mulți furnizori.
- Automatizarea nu este doar un fenomen tehnic, ci și cultural.
- Automatizarea rețelelor la scară este mai dificilă decât pare datorită principiilor arhitecturale fundamentale ale proiectării automatizării.
Când am discutat despre planurile noastre de creștere pe termen lung în urmă cu un an, clienții noștri corporativi au cerut următoarele:
- Colectarea faptelor trebuie să fie mai bine standardizată și aliniată cu fluxurile de lucru de automatizare pe toate dispozitivele.
- Actualizarea configurațiilor pe dispozitiv trebuie, de asemenea, să fie standardizată și consecventă, astfel încât modulele Ansible să gestioneze a doua jumătate a ciclului după colectarea faptelor.
- Avem nevoie de metode riguroase și acceptate pentru a converti configurația dispozitivului în date structurate. Pe această bază, sursa adevărului poate fi mutată de pe dispozitivul de rețea.
Îmbunătățiri ale faptelor
Colectarea datelor de pe dispozitivele de rețea folosind Ansible se întâmplă adesea la întâmplare. Platformele bazate pe web au diferite grade de capabilități de culegere a faptelor, dar au puține sau deloc funcționalități pentru analizarea și standardizarea reprezentării datelor în perechi cheie-valoare. Citit Ken Celenza despre cât de dificil și dureros poate fi să analizezi și să standardizezi datele faptice.
Poate ați observat că lucrăm la rolul Ansible Network Engine. Desigur, 24K descărcări mai târziu, rolul Network Engine a devenit rapid unul dintre cele mai populare roluri Ansible din Ansible Galaxy pentru scenariile de automatizare a rețelei. Înainte de a muta o mare parte din acest lucru în Ansible 2.8 pentru a ne pregăti pentru ceea ce ar fi necesar în Ansible 2.9, acest rol Ansible a oferit primul set de instrumente pentru a ajuta la analiza comenzilor, gestionarea comenzilor și colectarea datelor pentru dispozitivele de rețea.
Dacă știți cum să utilizați Network Engine, aceasta este o modalitate foarte eficientă de a colecta, analiza și standardiza datele de fapt pentru utilizare în Ansible. Dezavantajul acestui rol este că trebuie să creați o mulțime de analizoare pentru fiecare platformă și pentru toată activitatea din rețea. Pentru a înțelege cât de dificil este să creați, să expediați și să întrețineți analizatoare, aruncați o privire la de la băieții de la Cisco.
Pe scurt, obținerea de date de pe dispozitive și normalizarea lor în perechi cheie-valoare este esențială pentru automatizarea la scară, dar realizarea acestui lucru este dificilă atunci când aveți mulți furnizori și platforme de rețea.
Fiecare modul de fapte de rețea din Ansible 2.9 poate analiza acum configurația unui dispozitiv de rețea și poate returna date structurate - fără biblioteci suplimentare, roluri Ansible sau analizoare personalizate.
De la Ansible 2.9, de fiecare dată când este lansat un modul de rețea actualizat, modulul de fapt este îmbunătățit pentru a furniza date despre această secțiune a configurației. Adică, dezvoltarea faptelor și modulelor are loc acum în același ritm și vor avea întotdeauna o structură de date comună.
Configurația resurselor de pe un dispozitiv de rețea poate fi preluată și convertită în date structurate în două moduri. În ambele moduri, puteți colecta și transforma o anumită listă de resurse folosind un nou cuvânt cheie gather_network_resources. Numele resurselor se potrivesc cu numele modulelor, ceea ce este foarte convenabil.
În timpul adunării faptelor:
Folosind un cuvânt cheie gather_facts puteți prelua configurația curentă a dispozitivului la începutul playbook-ului și apoi o puteți utiliza pe parcursul întregului playbook. Specificați resursele individuale care vor fi preluate de pe dispozitiv.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueEste posibil să fi observat ceva nou în aceste exemple, și anume - gather_facts: true este acum disponibil pentru colectarea datelor native pentru dispozitivele de rețea.
Folosind direct modulul de fapte de rețea:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesManualul de joc returnează următoarele informații despre interfață:
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: Ethernet1Observați cum Ansible preia configurația nativă de pe dispozitivul Arista și o transformă în date structurate pentru a fi utilizate ca perechi cheie-valoare standard pentru sarcini și operațiuni din aval.
Faptele de interfață pot fi adăugate la variabilele stocate Ansible și utilizate imediat sau mai târziu ca intrare într-un modul de resurse eos_interfaces fără prelucrare sau conversie suplimentară.
Module de resurse
Deci, am extras faptele, am normalizat datele, le-am încadrat într-o diagramă standardizată a structurii de date interne și am primit o sursă de adevăr gata făcută. Ura! Acest lucru este grozav, desigur, dar trebuie totuși să convertim cumva perechile cheie-valoare înapoi la configurația specifică la care se așteaptă platforma dispozitivului specific. Acum avem nevoie de module specifice platformei pentru a îndeplini aceste noi cerințe de colectare a faptelor și normalizare.
Ce este un modul de resurse? Vă puteți gândi la secțiunile de configurare ale unui dispozitiv ca fiind resurse furnizate de acel dispozitiv. Modulele de resurse de rețea sunt limitate în mod intenționat la o singură resursă și pot fi stivuite ca niște blocuri pentru a configura servicii complexe de rețea. Ca rezultat, cerințele și specificațiile pentru un modul de resurse sunt în mod natural simplificate, deoarece modulul de resurse poate citi и configurați un anumit serviciu de rețea pe un dispozitiv de rețea.
Pentru a explica ce face un modul de resursă, să ne uităm la un exemplu de manual de joc care arată o operațiune idempodent folosind date și module noi privind resursele de rețea 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.changedDupă cum puteți vedea, datele colectate de pe dispozitiv sunt transferate direct în modulul de resurse corespunzător fără conversie. Când este lansat, playbook-ul preia valorile de pe dispozitiv și le compară cu cele așteptate. În acest exemplu, valorile returnate sunt cele așteptate (adică verifică abaterile de configurare) și raportează dacă configurația s-a schimbat.
Modul ideal de a detecta deviația de configurare este de a stoca faptele în variabilele stocate Ansible și de a le folosi periodic cu modulul de resurse în modul de inspecție. Aceasta este o metodă simplă pentru a vedea dacă cineva a schimbat manual valorile. În cele mai multe cazuri, organizațiile permit modificări și configurare manual, deși multe operațiuni sunt efectuate prin Ansible Automation.
Cum diferă noile module de resurse de cele anterioare?
Pentru un inginer de automatizare a rețelei, există 3 diferențe principale între modulele de resurse din Ansible 2.9 și versiunile anterioare.
1) Pentru o anumită resursă de rețea (care poate fi considerată și ca o secțiune de configurare), modulele și faptele vor evolua în toate sistemele de operare de rețea acceptate simultan. Credem că, dacă Ansible acceptă configurarea resurselor pe o singură platformă de rețea, ar trebui să o susținem peste tot. Acest lucru simplifică utilizarea modulelor de resurse deoarece un inginer de automatizare a rețelei poate configura acum o resursă (cum ar fi LLDP) pe toate sistemele de operare de rețea cu module native și acceptate.
2) Modulele de resurse includ acum o valoare de stare.
merged: configurația este îmbinată cu configurația furnizată (implicit);replaced: Configurația resursei va fi înlocuită cu configurația furnizată;overridden: Configurația resursei va fi înlocuită cu configurația furnizată; instanțele de resurse inutile vor fi șterse;deleted: Configurația resurselor va fi ștearsă/restaurată la valorile implicite.
3) Modulele de resurse includ acum valori de returnare stabile. Când modulul de resurse de rețea a făcut (sau a propus) modificările necesare dispozitivului de rețea, returnează aceleași perechi cheie-valoare în manualul de joc.
before: configurare pe dispozitiv sub formă de date structurate înainte de sarcină;after: dacă dispozitivul s-a schimbat (sau se poate schimba dacă se utilizează modul de testare), configurația rezultată va fi returnată ca date structurate;commands: Orice comenzi de configurare rulează pe dispozitiv pentru a-l aduce în starea dorită.
Ce înseamnă toate acestea? De ce este important?
Această postare acoperă o mulțime de concepte complexe, dar sperăm că, în cele din urmă, veți avea o mai bună înțelegere a ceea ce solicită clienții întreprinderii, de fapt, colectarea, normalizarea datelor și configurarea buclei pentru o platformă de automatizare. Dar de ce au nevoie de aceste îmbunătățiri? Multe organizații urmăresc acum transformarea digitală pentru a-și face mediile IT mai agile și mai competitive. La bine și la rău, mulți ingineri de rețea devin dezvoltatori de rețea fie din interes propriu, fie la cererea conducerii.
Organizațiile realizează că automatizarea șabloanelor individuale de rețea nu rezolvă problema silozurilor și doar crește eficiența într-o anumită măsură. Platforma Red Hat Ansible Automation oferă modele de date riguroase și normative pentru a gestiona în mod programatic datele subiacente pe un dispozitiv de rețea. Adică, utilizatorii abandonează treptat metodele de configurare individuale în favoarea unor metode mai moderne, cu accent pe tehnologii (de exemplu, adrese IP, VLAN-uri, LLDP etc.), mai degrabă decât pe o implementare specifică a furnizorului.
Înseamnă asta că zilele modulelor și configurației de comandă fiabile și dovedite sunt numărate? În niciun caz. Modulele de resurse de rețea așteptate nu vor fi aplicabile în toate cazurile sau pentru fiecare furnizor, astfel încât modulele de comandă și configurare vor fi în continuare necesare de către inginerii de rețea pentru anumite implementări. Scopul modulelor de resurse este de a simplifica șabloanele Jinja mari și de a normaliza configurațiile nestructurate ale dispozitivelor într-un format JSON structurat. Cu modulele de resurse, va fi mai ușor pentru rețelele existente să își transforme configurația în perechi cheie-valoare structurate care reprezintă o sursă de adevăr ușor de citit. Folosind perechi cheie-valoare structurate, puteți trece de la rularea configurațiilor pe fiecare dispozitiv la lucrul cu date structurate independente și aduceți rețelele în prim-planul abordării infrastructurii ca cod.
Ce module de resurse vor veni în Ansible Engine 2.9?
Înainte de a vă spune în detaliu ce se va întâmpla în Ansible 2.9, să ne amintim cum am împărțit întregul domeniu de activitate.
Am identificat 7 categorii și i-am atribuit fiecăreia resurse specifice de rețea:
Notă: Resursele cu caractere aldine au fost planificate și implementate în Ansible 2.9.
Pe baza feedback-ului din partea clienților întreprinderii și a comunității, era logic să abordăm mai întâi acele module legate de protocoalele de topologie de rețea, virtualizare și interfețe.
Următoarele module de resurse au fost dezvoltate de echipa Ansible Network și corespund platformelor suportate de Red Hat:
Următoarele module sunt dezvoltate de comunitatea Ansible:
exos_lldp_global- de la Extreme Networks.nxos_bfd_interfaces- de la Cisconxos_telemetry- de la Cisco
După cum puteți vedea, conceptul de module de resurse se încadrează în strategia noastră centrată pe platformă. Adică, includem capabilitățile și funcțiile necesare în Ansible însuși pentru a sprijini standardizarea în dezvoltarea modulelor de rețea și, de asemenea, pentru a simplifica munca utilizatorilor la nivelul rolurilor și manualelor Ansible. Pentru a extinde dezvoltarea modulelor de resurse, echipa Ansible a lansat instrumentul Module Builder.
Planuri pentru Ansible 2.10 și versiunile ulterioare
Odată ce Ansible 2.9 este lansat, vom lucra la următorul set de module de resurse pentru Ansible 2.10, care pot fi folosite pentru a configura în continuare topologia și politica rețelei, de ex. . Planul de dezvoltare poate fi în continuare ajustat, așa că dacă aveți comentarii, vă rugăm să-l raportați .
Resurse și început
Sursa: www.habr.com