În următoarea versiune Red Hat Ansible Engine 2.9 veți găsi îmbunătățiri impresionante, dintre care unele sunt descrise în acest articol. Ca de obicei, am dezvoltat îmbunătățirile pentru Ansible Network într-un mod deschis, cu sprijinul comunității. Alăturați-vă — vizitați și explorați planul de dezvoltare pentru pe pagina wiki pentru .
Așa cum am anunțat recent, include acum Ansible Tower, Ansible Engine și tot conținutul Ansible Network. În prezent, majoritatea platformelor de rețea populare sunt implementate prin module Ansible. De exemplu:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Lista completă a platformelor care sunt pe deplin suportate de Red Hat prin abonamentul Ansible Automation .
Ce am învățat
În ultimii patru ani, am învățat multe despre dezvoltarea unei platforme pentru automatizarea rețelei. De asemenea, am realizat că cum artefactele platformei sunt aplicate în playbook-uri și roluri Ansible din partea utilizatorilor finali. Iată ce am descoperit:
- Organizațiile automatizează nu doar dispozitive ale unui singur furnizor, ci de la mai mulți.
- Automatizarea nu este doar un fenomen tehnic, ci și unul cultural.
- Automatizarea la scară largă a rețelelor este mai complexă decât pare, din cauza principiilor arhitecturale fundamentale de proiectare a automatizării.
Când am discutat despre planurile noastre pe termen lung de dezvoltare acum mai bine de un an, clienții noștri corporativi au solicitat următoarele:
- Colectarea de date trebuie să fie mai bine standardizată și aliniată cu fluxul de lucru de automatizare pentru orice dispozitiv.
- Actualizarea configurațiilor pe dispozitive trebuie de asemenea standardizată și aliniată, astfel încât modulele Ansible să poată gestiona a doua jumătate a ciclului după colectarea datelor.
- Sunt necesare metode stricte și susținute de transformare a configurației dispozitivului în date structurate. Pe această bază, sursa de adevăr poate fi mutată de pe dispozitivele de rețea.
Îmbunătățirile datelor
Colectarea datelor de la dispozitivele de rețea cu Ajutorul Ansible se face adesea la întâmplare. Platformele de rețea sunt dotate în diferite măsuri cu capacități de colectare a datelor, dar au aproape lipsă — sau chiar deloc — funcții pentru analizarea și standardizarea prezentării datelor în perechi cheie-valoare. Citiți Ken Celenza despre cât de dificil și frustrant poate fi să analizați și să standardizați datele de date.
Este posibil să fi observat cum am lucrat la rolul Ansible Network Engine. Natural, după 24 de mii de descărcări, rolul Network Engine a devenit rapid unul dintre cele mai populare roluri Ansible în Ansible Galaxy pentru scripturile de automatizare a rețelei. Înainte de a transfera multe dintre acestea în Ansible 2.8, pentru a ne pregăti pentru ceea ce va fi necesar în Ansible 2.9, acest rol Ansible a oferit primul set de instrumente pentru ajutarea la parsarea comenzilor, gestionarea echipelor și colectarea datelor pentru dispozitivele de rețea.
Dacă aveți cunoștințe despre utilizarea Network Engine, aceasta este o metodă foarte eficientă de a colecta, parsa și standardiza datele pentru a fi utilizate în Ansible. Dezavantajul acestui rol este că trebuie să creați o mulțime de parse-uri pentru fiecare platformă și activitate de rețea. Pentru a înțelege cât de complicat este să creați, să livrați și să întrețineți parse-uri, aruncați o privire asupra de la oamenii de la Cisco.
Pe scurt, pentru automatizarea la scară largă, este foarte important să obțineți faptele de la dispozitive și să le normalizați în perechi cheie-valoare, dar este dificil să faceți acest lucru când aveți mulți furnizori și platforme de rețea.
Fiecare modul de fapte de rețea în Ansible 2.9 poate acum să analizeze configurația dispozitivului de rețea și să returneze date structurate - fără biblioteci suplimentare, roluri Ansible sau parse-uri personalizate.
Începând cu Ansible 2.9, cu fiecare lansare a unui modul de rețea actualizat, modulul de fapte este îmbunătățit pentru a oferi date despre această secțiune a configurației. Cu alte cuvinte, dezvoltarea faptelor și a modulelor are acum loc cu același ritm și va avea întotdeauna o structură comună de date.
Configurația resurselor pe un dispozitiv de rețea poate fi extrasă și transformată în date structurate în două moduri. Ambele moduri pot colecta și transforma o listă specifică de resurse utilizând noul cuvânt cheie gather_network_resources. Numele resurselor corespund numelui modulelor, ceea ce este foarte convenabil.
În timpul colectării faptelor:
Utilizând cuvântul cheie gather_facts puteți extrage configurația curentă a dispozitivului la începutul playbook-ului, apoi să o utilizați pe parcursul întregului playbook. Specificați resursele individuale care trebuie extrase de pe dispozitiv.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueAți putea observa ceva nou în aceste exemple, și anume — gather_facts: true acum este disponibil pentru colectarea nativă a faptelor pentru dispozitivele de rețea.
Utilizarea modulului de fapte de rețea direct:
- name: colectează faptele configurației interfeței
eos_facts:
gather_subset: min
gather_network_resources:
- interfețePlaybook-ul returnează următoarele fapte despre interfață:
ansible_facts:
ansible_network_resources:
interfețe:
- 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 extrage configurația nativă de pe dispozitivul Arista și o transformă în date structurate pentru a fi utilizate sub formă de perechi standard cheie-valoare pentru sarcini și operațiuni ulterioare.
Faptele interfețelor pot fi adăugate în variabilele salvate Ansible și utilizate imediat sau ulterior ca date de intrare pentru modulul de resursă eos_interfaces fără procesare sau transformare suplimentară.
Module de resurse
Așadar, am extras faptele, am normalizat datele, le-am introdus într-o schemă internă standardizată a structurii de date și am obținut o sursă de adevăr gata. Ura! Este, desigur, minunat, dar avem în continuare nevoie să transformăm perechile cheie-valoare în configurația specifică a platformei dispozitivului. Acum avem nevoie de module pentru platforme specifice pentru a satisface aceste noi cerințe de colectare a faptelor și normalizare.
Ce este un modul de resurse? Secțiunile configurației dispozitivului pot fi considerate drept resurse furnizate de acest dispozitiv. Modulele de resurse de rețea sunt intenționat limitate la o resursă și pot fi îngemănate, ca niște cărămizi, pentru a configura servicii de rețea complexe. Ca rezultat, cerințele și specificațiile pentru modulul de resurse se simplifică în mod natural, deoarece modulul de resurse poate citi și configura un serviciu de rețea specific pe un dispozitiv de rețea.
Pentru a explica ce face un modul de resurse, să ne uităm la un exemplu de playbook care arată o operațiune idempotentă folosind noile fapte ale resursei de rețea și modulul eos_l3_interface.
- name: exemplu de fapte transmise direct înapoi dispozitivului.
hosts: arista
gather_facts: false
tasks:
- name: obțineți faptele eos de la arista
eos_facts:
gather_subset: min
gather_network_resources: l3_interfaces
- name: asigurați-vă că informațiile despre adresa IP sunt corecte
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
register: result
- name: verificați că configurația nu s-a schimbat
assert:
that: not result.changedAșa cum puteți vedea, datele colectate de pe dispozitiv sunt transmise direct modulului corespunzător de resurse fără transformare. Atunci când rulați playbook-ul, se extrag valorile de pe dispozitiv și se compară cu cele așteptate. În acest exemplu, valorile obținute corespund celor așteptate (adică se efectuează o verificare a abaterilor de la configurație) și se emite un mesaj cu privire la schimbarea configurației.
Calea ideală de a detecta abaterile de la configurație este de a păstra faptele în variabilele stocate Ansible și a le utiliza periodic împreună cu modulul de resurse în modul de verificare. Aceasta este o metodă simplă de a vedea dacă cineva a modificat valorile manual. În cele mai multe cazuri, organizațiile permit modificări și configurații manual, deși multe operațiuni sunt realizate prin Ansible Automation.
Ce diferențiază modulele de resurse noi față de cele anterioare?
Pentru un inginer de automatizare a rețelelor, există 3 diferențe principale ale modulelor de resurse în Ansible 2.9 față de versiunile anterioare.
1) Pentru un anumit resursă de rețea (care poate fi, de asemenea, considerată o secțiune de configurație), modulele și faptele se vor dezvolta simultan în toate sistemele de operare de rețea suportate. Credem că, dacă Ansible susține configurația resursei pe o platformă de rețea, ar trebui să o susțină peste tot. Acest lucru simplifică utilizarea modulelor de resurse, deoarece inginerul de automatizare a rețelelor poate acum să configureze resursa (de exemplu, LLDP) în toate sistemele de operare de rețea cu module nativ suportate.
2) Modulele de resurse includ acum valoarea de stare.
fuzionat: configurația este fuzionată cu configurația furnizată (implicit);înlocuit: configurația resursei va fi înlocuită cu configurația furnizată;suprimat: configurația resursei va fi înlocuită cu configurația furnizată; instanțele suplimentare ale resurselor vor fi eliminate;deleted: configurația resursei va fi ștearsă/restaurată implicit.
3) Modulele de resurse includ acum valori returnate stabile. Când modulul resursei de rețea a efectuat (sau a propus) modificările necesare pe dispozitivul de rețea, acesta returnează aceleași perechi cheie-valoare în playbook.
before: configurația dispozitivului sub formă de date structurate înainte de sarcină;după: dacă dispozitivul s-a schimbat (sau poate să se schimbe, dacă se utilizează modul de verificare), configurația obținută va fi returnată sub formă de date structurate;comenzi: orice comenzi de configurare executate pe dispozitiv pentru a-l aduce în starea dorită.
Ce înseamnă toate acestea? De ce este important?
Această postare descrie multe concepte complexe, dar sperăm că, în cele din urmă, veți înțelege mai bine ce cer clienții corporativi în ceea ce privește colectarea de fapte, normalizarea datelor și configurarea ciclului pentru platforma de automatizare. Dar de ce au nevoie de aceste îmbunătățiri? În prezent, multe organizații se angajează în transformarea digitală pentru a face mediile lor IT mai flexibile și competitive. Fie că este bine sau rău, mulți ingineri de rețea devin dezvoltatori de rețea — din propriul interes sau la îndemnul conducătorilor.
Organizațiile înțeleg că automatizarea șabloanelor individuale de rețea nu rezolvă problema fragmentării și sporește eficiența doar până la un anumit grad. Platforma Red Hat Ansible Automation Platform oferă modele de date stricte și normalizatoare pentru a gestiona programatic datele de bază pe dispozitivul de rețea. Adică utilizatorii abandonează treptat metodele individuale de configurare în favoarea unor metode mai moderne, axate pe tehnologii (de exemplu, adrese IP, VLAN, LLDP etc.), și nu pe implementarea specifică a furnizorului.
Înseamnă asta că zilele modulelor de comandă și configurație de încredere și verificate sunt numărate? Cu siguranță nu. Modulele de resurse de rețea planificate nu vor fi aplicabile în toate cazurile și nu pentru fiecare furnizor, așa că modulele de comandă și configurație vor fi în continuare necesare inginerilor de rețea pentru anumite implementări. Scopul modulelor de resurse este de a simplifica șabloanele mari Jinja și de a normaliza configurațiile neorganizate ale dispozitivelor într-un format JSON structurat. Cu modulele de resurse, rețelele existente vor avea mai multă ușurință în a-și transforma configurația în perechi cheie-valoare structurate, care vor reprezenta o sursă de adevăr ușor de citit. Utilizând perechi cheie-valoare structurate, se poate trece de la rularea configurațiilor pe fiecare dispozitiv la lucrul cu date structurate independente și aduce rețelele în prim-plan în abordarea „infrastructură ca cod”.
Ce module de resurse vor apărea în Ansible Engine 2.9?
Îbefore să discutăm detaliat despre ce va fi în Ansible 2.9, să ne amintim cum am împărțit întreaga muncă.
Am identificat 7 categorii și fiecărei categorii i-am atribuit anumite resurse de rețea:
Notă: resursele evidențiate cu bold au fost planificate și implementate în Ansible 2.9.
Pe baza feedback-ului de la clienți corporativi și din comunitate, era logic să ne axăm mai întâi pe acele module care se leagă de protocoalele de topologie a rețelei, virtualizare și interfețe.
Următoarele module de resurse au fost dezvoltate de echipa Ansible Network și sunt compatibile cu platformele susținute de Red Hat:
Următoarele module au fost dezvoltate de comunitatea Ansible:
exos_lldp_global— de la Extreme Networks.nxos_bfd_interfaces— de la Cisco.nxos_telemetry— de la Cisco.
După cum vedeți, conceptul modulelor de resurse se integrează în strategia noastră de orientare pe platforme. Asta înseamnă că includem funcționalitățile și capabilitățile necesare direct în Ansible, pentru a susține standardizarea în dezvoltarea modulelor de rețea, dar și pentru a simplifica munca utilizatorilor la nivel de roluri și playbook-uri Ansible. Pentru a extinde dezvoltarea modulelor de resurse, echipa Ansible a lansat instrumentul Module Builder.
Planuri pentru Ansible 2.10 și mai departe
După lansarea Ansible 2.9, ne vom concentra asupra următorului set de module de resurse pentru Ansible 2.10, care vor putea fi utilizate pentru configurarea suplimentară a topologiei și politicii rețelei, cum ar fi Planul de dezvoltare poate fi ajustat, așa că, dacă aveți comentarii, vă rugăm să le comunicați în .
Resurse și începuturi
Sursa: habr.com
