NĂ« numrin e ardhshĂ«m tĂ« Red Hat Ansible Engine 2.9 ju pret pĂ«rmirĂ«sime mbresĂ«lĂ«nse, disa prej tĂ« cilave pĂ«rshkruhen nĂ« kĂ«tĂ« artikull. Si zakonisht, ne kemi zhvilluar pĂ«rmirĂ«simet e Ansible Network nĂ« mĂ«nyrĂ« tĂ« hapur, me mbĂ«shtetje nga komuniteti. Bashkohuni â hidhni njĂ« vĂ«shtrim nĂ« dhe shqyrtoni planin e zhvillimit pĂ«r nĂ« faqen wiki pĂ«r .
Siç shpallëm kohët e fundit, tani përfshin Ansible Tower, Ansible Engine dhe të gjithë përmbajtjen e Ansible Network. Tani, shumica e platformave të njohura rrjetore realizohen përmes modulave Ansible. Për shembull:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Lista e plotë e platformave që mbështeten plotësisht nga Red Hat përmes abonimit Ansible Automation, .
ĂfarĂ« kemi mĂ«suar
Në katër vitet e fundit kemi mësuar shumë rreth zhvillimit të një platforme për automatizimin e rrjetit. Po ashtu, kemi mësuar se si artefaktet e platformës aplikohen në playbooks dhe role Ansible nga ana e përdoruesve të fundit. Dhe ja çfarë kemi zbuluar:
- Organizatat automatizojnë pajisje nga një ose më shumë ofrues të ndryshëm.
- Automatizimi është një fenomen jo vetëm teknik, por edhe kulturor.
- Automatizimi masiv i rrjeteve është më i komplikuar se sa duket, për shkak të parimeve themelore arkitektonike të dizajnimit të automatizimit.
Kur diskutuam planet tona afatgjata për zhvillim më shumë se një vit më parë, klientët tanë korporatë kërkuan të ardhmen:
- Grumbullimi i fakteve duhet të standardizohet më mirë dhe të pajtohet me procesin e automatizimit për çdo pajisje.
- Përditësimi i konfigurimeve në pajisje gjithashtu duhet të standardizohet dhe të pajtohet, që modulet Ansible të trajtojnë pjesën e dytë të ciklit pas grumbullimit të fakteve.
- Kërkohen metoda të rrepta dhe të mbështetura për të shndërruar konfigurimin e pajisjes në të dhëna të strukturuara. Bazuar në këtë, burimi i së vërtetës mund të transferohet nga pajisja rrjetore.
Përmirësimet e fakteve
Grumbullimi i fakteve nga pajisjet rrjetore me Ansible shpesh ndodh nĂ« mĂ«nyrĂ« tĂ« rastĂ«sishme. Platformave rrjetore u mungojnĂ« mundĂ«si tĂ« ndryshme pĂ«r grumbullimin e fakteve, por ato kanĂ« pothuajse asnjĂ« â ose madje asnjĂ« â funksionalitet pĂ«r analizimin dhe standardizimin e prezantimit tĂ« tĂ« dhĂ«nave nĂ« çifte çelĂ«s-vlerĂ«. Lexoni Ken Celenza rreth vĂ«shtirĂ«sive dhe mundimeve qĂ« lidhen me analizimin dhe standardizimin e tĂ« dhĂ«nave tĂ« fakteve.
Ndoshta keni vënë re se si kemi punuar mbi rolin Ansible Network Engine. Natyrisht, pas 24 mijë shkarkimeve, roli Network Engine u bë shpejt një nga rolet më të njohura të Ansible në Ansible Galaxy për skenarët e automatizimit të rrjetit. Para se të transferonim shumë prej këtij përmbajtjeje në Ansible 2.8, për t'u përgatitur për nevojat në Ansible 2.9, ky rol Ansible ofroi grupin e parë të mjeteve për ndihmë në analizimin e komandave, menaxhimin e ekipeve dhe mbledhjen e të dhënave për pajisjet rrjetore.
Nëse jeni të njohur me përdorimin e Network Engine, ky është një mënyrë shumë efikase për mbledhjen, analizimin dhe standardizimin e të dhënave të fakteve për përdorim në Ansible. Disavantazhi i këtij roli është se duhet të krijoni një sërë parserash për çdo platformë dhe për të gjithë aktivitetin rrjetor. Për të kuptuar sa e komplikuar është të krijosh, shpërndash dhe mbash parsera, shikoni nga djemtë e Cisco.
Me fjalë të thjeshta, për automatizimin në shkallë të gjerë është shumë e rëndësishme të përfitoni fakte nga pajisjet dhe t'i normalizoni ato në çifte çelës-vlerë, por është e vështirë të arrini këtë kur keni shumë furnizues dhe platforma rrjetesh.
Ădo moduli i fakteve tĂ« rrjetit nĂ« Ansible 2.9 tani mund tĂ« analizojĂ« konfigurimin e pajisjes rrjetore dhe tĂ« kthejĂ« tĂ« dhĂ«na tĂ« strukturuara â pa biblioteka shtesĂ«, role Ansible ose parsera tĂ« personalizuar.
Duke filluar nga Ansible 2.9 me çdo publikim të një moduli të ri rrjeti, moduli i fakteve përmirësohet për të ofruar të dhëna mbi këtë seksion të konfigurimit. Pra, zhvillimi i fakteve dhe moduleve tani ndodh në një ritëm të përbashkët dhe gjithmonë do të kenë një strukturë të përbashkët të të dhënave.
Konfigurimi i burimeve në pajisjen rrjetore mund të nxirret dhe të transformohet në të dhëna të strukturuara në dy mënyra. Të dyja mënyrat mund të mbledhin dhe transformojnë një listë të caktuar burimesh duke përdorur fjalinë e re gather_network_resources. Emrat e burimeve përputhen me emrat e moduleve, dhe kjo është shumë e përshtatshme.
Gjatë mbledhjes së fakteve:
Me anë të fjalës kyç gather_facts mund të nxirret konfigurimi aktual i pajisjes në fillim të playbook-ut dhe pastaj ta përdorni atë gjatë tërë playbook-ut. Specifikoni burimet e veçanta që dëshironi të nxirrni nga pajisja.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueMund tĂ« keni vĂ«nĂ« re diçka tĂ« re nĂ« kĂ«to shembuj, dmth â gather_facts: true tani tani Ă«shtĂ« e disponueshme pĂ«r mbledhjen native tĂ« tĂ« dhĂ«nave pĂ«r pajisje rrjetĂ«sh.
Përdorimi i modulit të të dhënave rrjetore direkt:
- emri: mbledh të dhënat për konfigurimin e interfaces
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesPlaybook-u kthen të dhënat e mëposhtme në lidhje me interface-in:
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: Ethernet1Vini re si Ansible nxjerr konfigurimin native nga pajisja Arista dhe e transformon atë në të dhëna të strukturuara, për t'u përdorur si çift standard çelës-vlerë për detyra dhe operacione të mëvonshme.
Të dhënat e interface-it mund të shtohen në variablat e ruajtura të Ansible dhe të përdoren menjëherë ose më vonë si input për modulin e burimit eos_interfaces pa përpunim ose transformim shtesë.
Modulet e burimeve
Pra, kemi nxjerrë të dhënat, normalizuar informacionin, e kemi regjistruar atë në një skemë të standardizuar për struktura të dhënash dhe kemi marrë një burim të gatshëm të së vërtetës. Hurra! Kjo është sigurisht e shkëlqyer, por ne ende duhet ndonjëherë të transformojmë çiftet çelës-vlerë përsëri në konfigurimin specifik që pret platforma specifike e pajisjes. Tani na nevojiten modul për platforma të caktuara për të kryer këto kërkesa të reja për mbledhje të të dhënave dhe normalizim.
ĂfarĂ« Ă«shtĂ« njĂ« modul burimi? Seksionet e konfigurimit tĂ« pajisjes mund tĂ« paraqitet si burime tĂ« ofruara nga kjo pajisje. ModulĂ«t e burimeve rrjetore janĂ« qĂ«llimisht tĂ« kufizuar nĂ« njĂ« burim dhe mund tĂ« rreshtohen si tulla pĂ«r tĂ« krijuar shĂ«rbime komplekse rrjetore. Si rezultat, kĂ«rkesat dhe specifikimet pĂ«r modulĂ«t e burimeve thjeshtohen natyrshĂ«m, pasi moduli i burimit mund tĂ« lexojĂ« dhe tĂ« konfiguroni njĂ« shĂ«rbim tĂ« caktuar rrjeti nĂ« pajisjen rrjet.
Për të shpjeguar se çfarë bën moduli i burimit, le të shohim një shembull playbook-u që tregon një operacion idempotent duke përdorur të dhënat e reja të burimit të rrjetit dhe modulin eos_l3_interface.
- emri: shembuj i fakteve që shtyhen në pajisje.
hosts: arista
gather_facts: false
tasks:
- emri: merr fakte arista eos
eos_facts:
gather_subset: min
gather_network_resources: l3_interfaces
- emri: sigurohet që informacioni i adresës IP të jetë i saktë
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
register: result
- emri: sigurohet që konfigurimi nuk ka ndryshuar
assert:
that: not result.changedSiç e shihni, të dhënat e mbledhura nga pajisja dërgohen drejtpërdrejt në modulin përkatës të burimeve pa transformim. Kur ekzekutohet playbooku, ai nxjerr vlerat nga pajisja dhe i krahason ato me ato të pritura. Në këtë shembull, vlerat e marra përputhen me ato të pritura (dmth, kryhet kontrolli i devijimeve të konfigurimit) dhe jepet një mesazh nëse është ndryshuar konfigurimi.
Mënyra më e mirë për të zbuluar devijimin e konfigurimit është të ruani faktet në variabla të ruajtura Ansible dhe t'i përdorni periodicisht ato së bashku me modulin e burimeve në mënyrë verifikimi. Kjo është një metodë e thjeshtë për të parë nëse dikush ka ndryshuar vlerat manualisht. Në shumicën e rasteve, organizatat lejojnë ndryshime dhe konfigurim manual, ndonëse shumë operacione kryhen përmes Ansible Automation.
ĂfarĂ« i ndan modulet e reja tĂ« burimeve nga ato tĂ« mĂ«parshmet?
Për një inxhinier të automatizimit të rrjetit, ekzistojnë 3 dallime kryesore të moduleve të burimeve në Ansible 2.9 nga versionet e mëparshme.
1) Për një burim të caktuar rrjeti (i cili mund të përshkruhet gjithashtu si një seksion konfigurimi), modulet dhe faktet do të zhvillohen në të gjitha sistemet e operative të mbështetura të rrjetit njëherësh. Ne besojmë se, nëse Ansible mbështet konfigurimin e burimit në një platformë rrjeti, ne duhet ta mbështesim atë kudo. Kjo e thjeshton përdorimin e modulit të burimeve, sepse inxhinieri i automatizimit të rrjetit tani mund të konfigurojë burimin (siç është LLDP) në të gjitha sistemet operative të rrjetit me modulet natyrale dhe të mbështetura.
2) Modulet e burimeve tani përfshijnë vlerën e gjendjes.
bashkuar: konfigurimi është i bashkuar me konfigurimin e ofruar (në parazgjedhje);zëvendësuar: konfigurimi i burimit do të zëvendësohet me konfigurimin e ofruar;të mbivendosur: konfigurimi i burimit do të zëvendësohet me konfigurimin e ofruar; instancat e tepërta të burimeve do të hiqen;deleted: konfigurimi i burimit do të hiqet/rikthehet në parazgjedhje.
3) Modulet e burimeve tani përfshijnë vlera të qëndrueshme të kthimit. Kur moduli i burimit rrjetor bën (ose propozon) ndryshimet e nevojshme në pajisjen rrjetore, ai kthen të njëjtat çifte çelësi-vlerë në playbook.
para: konfigurimi në pajisje në formën e të dhënave të strukturuara përpara detyrës;pas: nëse pajisja është ndryshuar (ose mund të ndryshojë, nëse përdoret mënyra e verifikimit), konfigurimi i rezultuar do të kthehet në formën e të dhënave të strukturuara;komanda: çdo komandë konfigurationsh e ekzekutuar në pajisje për ta sjellë atë në gjendjen e dëshiruar.
ĂfarĂ« do tĂ« thotĂ« tĂ« gjitha kĂ«to? Pse Ă«shtĂ« e rĂ«ndĂ«sishme?
Ky postim pĂ«rshkruan shumĂ« koncepte tĂ« komplikuara, por shpresojmĂ« qĂ« nĂ« fund do tĂ« kuptoni mĂ« mirĂ« se çfarĂ« kĂ«rkojnĂ« klientĂ«t korporativĂ« pĂ«r mbledhjen e fakteve, normalizimin e tĂ« dhĂ«nave dhe ciklin e konfigurimit pĂ«r platformĂ«n e automatizimit. Por pse kanĂ« nevojĂ« pĂ«r kĂ«to pĂ«rmirĂ«sime? Aktualisht, shumĂ« organizata po angazhohen nĂ« transformimin digjital pĂ«r ta bĂ«rĂ« mjedisin e tyre IT mĂ« fleksibĂ«l dhe konkurrues. MirĂ« apo keq, shumĂ« inxhinierĂ« rrjetesh po bĂ«hen zhvillues rrjetesh â nga interesi i tyre ose me urdhĂ«r tĂ« drejtorĂ«ve.
Organizatat kuptojnë se automatizimi i modeleve të veçanta rrjetore nuk zgjidh problemin e fragmentimit dhe rrit efikasitetin vetëm deri në një pikë të caktuar. Platforma Red Hat Ansible Automation Platform ofron modele të rrepta dhe normalizuese të të dhënave të burimeve për të menaxhuar programatikisht të dhënat baza në pajisjen rrjetore. Kështu, përdoruesit gradualisht po heqin dorë nga mënyrat individuale të konfigurimit në favor të metodave më moderne me theks tek teknologjitë (p.sh. adresat IP, VLAN, LLDP etj.), dhe jo nga realizimi i konkret i shitësit.
A do të thotë kjo se ditët e moduleve të besueshëm dhe të provuar të komandave dhe configurimeve kanë kaluar? Aspak. Modulet e pritshme të burimeve të rrjetit nuk do të aplikohen në të gjitha rastet dhe për çdo ofrues, kështu që modulet e komandave dhe configurimeve do të nevojiten ende nga inxhinierët e rrjetit për realizime të caktuara. Qëllimi i moduleve të burimeve është të thjeshtojë modelet e mëdha Jinja dhe të normalizojë configurimet e pa strukturizuara të pajisjeve në një format të strukturuar JSON. Me modulet e burimeve, rrjetet ekzistuese do të kenë më të lehtë të transformojnë konfigurimin e tyre në çifte kyç-vlerë të strukturuara, të cilat do të përbëjnë një burim të vërtetë të lexueshëm. Duke përdorur çifte të strukturuara kyç-vlerë, mund të kaloni nga ekzekutimi i konfigurimeve në çdo pajisje në punën me të dhëna të strukturuara të pavarura dhe të vendosni rrjetet në qendër të qasjes "infrastrukturë si kod".
Cilat module burimesh do të shfaqen në Ansible Engine 2.9?
Para se të flasim në detaje për atë që do të përmbajë Ansible 2.9, le të kujtojmë se si e kemi ndarë të gjithë volumet e punës.
Ne kemi identifikuar 7 kategori dhe secilës i kemi caktuar disa burime rrjeti:
Shënim: burimet e shënuara me gegë janë planifikuar dhe implementuar në Ansible 2.9.
Bashkëngjitur përmes feedback-ut nga klientët korporatë dhe nga komuniteti, ishte e arsyeshme të merrej fillimisht me modulet që lidhen me protokollet topologjike të rrjetit, virtualizimin dhe ndërfaqet.
Modulet e mëposhtme të burimeve janë zhvilluar nga ekipi i Ansible Network dhe përputhen me platformat që mbështet Red Hat:
Modulet e mëposhtme janë zhvilluar nga komuniteti Ansible:
exos_lldp_globalâ nga Extreme Networks.nxos_bfd_interfacesâ nga Cisco.Siç mund ta shihni, koncepti i moduleve tĂ« burimeve pĂ«rputhet me strategjinĂ« tonĂ« pĂ«r orientim ndaj platformave. Kjo do tĂ« thotĂ« qĂ« ne pĂ«rfshijmĂ« cilĂ«sitĂ« dhe funksionet e nevojshme nĂ« Ansible vetĂ«, pĂ«r tĂ« mbĂ«shtetur standardizimin nĂ« zhvillimin e moduleve tĂ« rrjetit, dhe gjithashtu pĂ«r tĂ« thjeshtuar punĂ«n e pĂ«rdoruesve nĂ« nivelin e roleve dhe playbook-eve tĂ« Ansible. PĂ«r tĂ« zgjeruar zhvillimin e moduleve tĂ« burimeve, ekipi i Ansible ka lĂ«shuar mjetin Module Builder.â nga Cisco.
Planet për Ansible 2.10 dhe më tej
Pas lëshimit të Ansible 2.9, ne do të merremi me grupin tjetër të moduleve të burimeve për Ansible 2.10, të cilat do të mund të përdoren për konfigurimin e mëtejshëm të topologjisë dhe politikës së rrjetit, për shembull
ACL, OSPF dhe BGP. Plani i zhvillimit mund të korrigjohet ende, prandaj, nëse keni komente, na njoftoni në .
Burimet dhe fillimi i punës
Burimi: habr.com
