Publikimi i ardhshëm i Red Hat Ansible Engine 2.9 sjell përmirësime emocionuese, disa prej të cilave janë mbuluar në këtë artikull. Si gjithmonë, ne kemi zhvilluar përmirësime të rrjetit Ansible hapur, me mbështetjen e komunitetit. Bashkohuni me ne - hidhini një sy dhe studioni planin e zhvillimit për në faqen wiki për .
Siç kemi njoftuar së fundmi, tani përfshin Ansible Tower, Ansible Engine dhe të gjithë përmbajtjen e Ansible Network. Në ditët e sotme, platformat më të njohura të rrjeteve zbatohen përmes moduleve Ansible. Për shembull:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Për një listë të plotë të platformave që mbështeten plotësisht nga Red Hat përmes abonimit në Ansible Automation, .
Çfarë kemi mësuar
Gjatë katër viteve të fundit, ne kemi mësuar shumë rreth zhvillimit të një platforme automatizimi rrjeti. Këtë e mësuam edhe ne si Artefaktet e platformës përdoren në librat dhe rolet e Ansible nga përdoruesit fundorë. Dhe ja çfarë zbuluam:
- Organizatat po automatizojnë pajisje jo vetëm nga një, por nga shumë shitës.
- Automatizimi nuk është vetëm një fenomen teknik, por edhe kulturor.
- Automatizimi i rrjeteve në shkallë është më i vështirë sesa duket për shkak të parimeve themelore arkitekturore të projektimit të automatizimit.
Kur diskutuam planet tona afatgjata të rritjes mbi një vit më parë, klientët tanë të korporatave kërkuan sa vijon:
- Mbledhja e fakteve duhet të standardizohet më mirë dhe të përafrohet me flukset e punës së automatizimit në të gjitha pajisjet.
- Përditësimi i konfigurimeve në pajisje gjithashtu duhet të jetë i standardizuar dhe i qëndrueshëm në mënyrë që modulet Ansible të trajtojnë gjysmën e dytë të ciklit pas mbledhjes së fakteve.
- Ne kemi nevojë për metoda rigoroze dhe të mbështetura për konvertimin e konfigurimit të pajisjes në të dhëna të strukturuara. Mbi këtë bazë, burimi i së vërtetës mund të zhvendoset nga pajisja e rrjetit.
Përmirësimet e fakteve
Mbledhja e fakteve nga pajisjet e rrjetit që përdorin Ansible shpesh ndodh në mënyrë të rastësishme. Platformat e bazuara në ueb kanë shkallë të ndryshme të aftësive për mbledhjen e fakteve, por ato kanë pak ose aspak funksionalitet për analizimin dhe standardizimin e përfaqësimit të të dhënave në çiftet e vlerave kyçe. Lexoni Ken Celenza se sa e vështirë dhe e dhimbshme mund të jetë analizimi dhe standardizimi i të dhënave faktike.
Ju mund të keni vënë re që ne po punojmë në rolin Ansible Network Engine. Natyrisht, 24K shkarkime më vonë, roli i Motorit të Rrjetit është bërë shpejt një nga rolet më të njohura të Ansible në Ansible Galaxy për skenarët e automatizimit të rrjetit. Përpara se të transferonim shumë nga kjo në Ansible 2.8 për t'u përgatitur për atë që do të nevojitej në Ansible 2.9, ky rol Ansible siguroi grupin e parë të mjeteve për të ndihmuar në analizimin e komandave, menaxhimin e komandave dhe mbledhjen e të dhënave për pajisjet e rrjetit.
Nëse dini të përdorni Network Engine, kjo është një mënyrë shumë efikase për të mbledhur, analizuar dhe standardizuar të dhënat e fakteve për përdorim në Ansible. Disavantazhi i këtij roli është se ju duhet të krijoni një grup të tërë analizuesish për secilën platformë dhe për të gjithë aktivitetin e rrjetit. Për të kuptuar se sa e vështirë është krijimi, dërgimi dhe mirëmbajtja e analizuesve, hidhini një sy nga djemtë në Cisco.
Me pak fjalë, marrja e fakteve nga pajisjet dhe normalizimi i tyre në çifte me vlerë kyçe është thelbësore për automatizimin në shkallë, por arritja e kësaj është e vështirë kur keni shumë shitës dhe platforma rrjeti.
Çdo modul faktesh rrjeti në Ansible 2.9 tani mund të analizojë konfigurimin e një pajisjeje rrjeti dhe të kthejë të dhëna të strukturuara - pa biblioteka shtesë, role Ansible ose analizues të personalizuar.
Që nga Ansible 2.9, sa herë që lëshohet një modul i përditësuar i rrjetit, moduli i fakteve përmirësohet për të ofruar të dhëna për këtë seksion të konfigurimit. Kjo do të thotë, zhvillimi i fakteve dhe moduleve tani ndodh me të njëjtin ritëm dhe ato gjithmonë do të kenë një strukturë të përbashkët të dhënash.
Konfigurimi i burimeve në një pajisje rrjeti mund të merret dhe shndërrohet në të dhëna të strukturuara në dy mënyra. Në të dyja mënyrat, ju mund të mbledhni dhe transformoni një listë specifike burimesh duke përdorur një fjalë kyçe të re gather_network_resources. Emrat e burimeve përputhen me emrat e moduleve, gjë që është shumë e përshtatshme.
Gjatë mbledhjes së fakteve:
Duke përdorur një fjalë kyçe gather_facts mund të rikuperoni konfigurimin aktual të pajisjes në fillim të librit të luajtjes dhe më pas ta përdorni në të gjithë librin e luajtjes. Specifikoni burimet individuale që do të merren nga pajisja.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueJu mund të keni vënë re diçka të re në këta shembuj, domethënë - gather_facts: true tani është i disponueshëm për mbledhjen e fakteve vendase për pajisjet e rrjetit.
Duke përdorur drejtpërdrejt modulin e fakteve të rrjetit:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesPlaybook kthen faktet e mëposhtme në lidhje me ndërfaqen:
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 se si Ansible rimerr konfigurimin origjinal nga pajisja Arista dhe e transformon atë në të dhëna të strukturuara për t'i përdorur si çifte standarde të vlerave kyçe për detyrat dhe operacionet në rrjedhën e poshtme.
Faktet e ndërfaqes mund të shtohen në variablat e ruajtura në Ansible dhe të përdoren menjëherë ose më vonë si hyrje në një modul burimi eos_interfaces pa përpunim apo konvertim shtesë.
Modulet e Burimeve
Pra, ne nxorëm faktet, normalizuam të dhënat, i vendosëm ato në një diagram të standardizuar të strukturës së brendshme të të dhënave dhe morëm një burim të gatshëm të së vërtetës. Hora! Kjo është e shkëlqyeshme, sigurisht, por ne ende duhet t'i kthejmë disi çiftet e vlerës së çelësit në konfigurimin specifik që pret platforma specifike e pajisjes. Tani na duhen module specifike për platformën për të përmbushur këto kërkesa të reja për mbledhjen e fakteve dhe normalizimin.
Çfarë është një modul burimesh? Ju mund të mendoni për seksionet e konfigurimit të një pajisjeje si burime të ofruara nga ajo pajisje. Modulet e burimeve të rrjetit janë të kufizuara qëllimisht në një burim të vetëm dhe mund të grumbullohen si blloqe ndërtimi për të konfiguruar shërbimet komplekse të rrjetit. Si rezultat, kërkesat dhe specifikimet për një modul burimesh thjeshtohen natyrshëm, pasi moduli i burimeve mund të lexojë и konfiguroni një shërbim specifik rrjeti në një pajisje rrjeti.
Për të shpjeguar se çfarë bën një modul burimesh, le të shikojmë një shembull të librit të lojërave që tregon një operacion idempodent duke përdorur fakte dhe modul të ri të burimeve të rrjetit 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.changedSiç mund ta shihni, të dhënat e mbledhura nga pajisja transferohen drejtpërdrejt në modulin përkatës të burimit pa konvertim. Kur niset, libri i lojërave merr vlerat nga pajisja dhe i krahason ato me ato të pritura. Në këtë shembull, vlerat e kthyera janë siç priten (d.m.th., ai kontrollon për devijimet e konfigurimit) dhe raporton nëse konfigurimi ka ndryshuar.
Mënyra ideale për të zbuluar zhvendosjen e konfigurimit është ruajtja e fakteve në variablat e ruajtura në Ansible dhe përdorimi periodik i tyre me modulin e burimeve në modalitetin e inspektimit. Kjo është një metodë e thjeshtë për të parë nëse dikush i ka ndryshuar manualisht vlerat. Në shumicën e rasteve, organizatat lejojnë ndryshimet dhe konfigurimin me dorë, megjithëse shumë operacione kryhen përmes Ansible Automation.
Si ndryshojnë modulet e reja të burimeve nga ato të mëparshme?
Për një inxhinier të automatizimit të rrjetit, ekzistojnë 3 dallime kryesore midis moduleve të burimeve në Ansible 2.9 dhe versioneve të mëparshme.
1) Për një burim të caktuar rrjeti (i cili gjithashtu mund të mendohet si një seksion konfigurimi), modulet dhe faktet do të zhvillohen në të gjitha sistemet operative të rrjetit të mbështetur në të njëjtën kohë. Ne mendojmë se nëse Ansible mbështet konfigurimin e burimeve në një platformë rrjeti, ne duhet ta mbështesim atë kudo. Kjo thjeshton përdorimin e moduleve të burimeve, sepse një inxhinier i automatizimit të rrjetit tani mund të konfigurojë një burim (siç është LLDP) në të gjitha sistemet operative të rrjetit me module vendase dhe të mbështetur.
2) Modulet e burimeve tani përfshijnë një vlerë të gjendjes.
merged: konfigurimi është bashkuar me konfigurimin e dhënë (default);replaced: Konfigurimi i burimit do të zëvendësohet me konfigurimin e dhënë;overridden: Konfigurimi i burimit do të zëvendësohet me konfigurimin e dhënë; Instancat e burimeve të panevojshme do të fshihen;deleted: Konfigurimi i burimit do të fshihet/rikthehet në parazgjedhje.
3) Modulet e burimeve tani përfshijnë vlera të qëndrueshme kthimi. Kur moduli i burimeve të rrjetit ka bërë (ose propozuar) ndryshimet e nevojshme në pajisjen e rrjetit, ai kthen të njëjtat çifte të vlerave kyçe në librin e luajtjes.
before: konfigurimi në pajisje në formën e të dhënave të strukturuara përpara detyrës;after: nëse pajisja ka ndryshuar (ose mund të ndryshojë nëse përdoret modaliteti i testimit), konfigurimi që rezulton do të kthehet si të dhëna të strukturuara;commands: Çdo komandë konfigurimi ekzekutohet në pajisje për ta sjellë atë në gjendjen e dëshiruar.
Çfarë do të thotë e gjithë kjo? Pse është e rëndësishme?
Ky postim mbulon shumë koncepte komplekse, por shpresojmë që në fund të keni një kuptim më të mirë të asaj që klientët e ndërmarrjeve kërkojnë në fakt mbledhjen, normalizimin e të dhënave dhe konfigurimin e lakut për një platformë automatizimi. Por pse u duhen këto përmirësime? Shumë organizata tani po ndjekin transformimin dixhital për t'i bërë mjediset e tyre të TI-së më të shkathët dhe konkurrues. Për mirë ose për keq, shumë inxhinierë të rrjetit bëhen zhvillues të rrjetit ose për interes personal ose me urdhër të menaxhmentit.
Organizatat po kuptojnë se automatizimi i modeleve individuale të rrjetit nuk e zgjidh problemin e kapanoneve dhe vetëm rrit efikasitetin në një masë të caktuar. Platforma Red Hat Ansible Automation ofron modele rigoroze dhe normative të të dhënave të burimeve për të menaxhuar në mënyrë programore të dhënat themelore në një pajisje rrjeti. Kjo do të thotë, përdoruesit po braktisin gradualisht metodat individuale të konfigurimit në favor të metodave më moderne me theks në teknologji (për shembull, adresat IP, VLAN, LLDP, etj.), në vend të një zbatimi specifik të shitësit.
A do të thotë kjo se ditët e moduleve dhe konfigurimit të komandës të besueshme dhe të provuara janë të numëruara? Në asnjë rast. Modulet e pritshme të burimeve të rrjetit nuk do të jenë të zbatueshme në të gjitha rastet ose për çdo shitës, kështu që modulet e komandës dhe konfigurimit do t'u nevojiten ende inxhinierëve të rrjetit për disa implementime. Qëllimi i moduleve të burimeve është të thjeshtojnë shabllonet e mëdhenj Jinja dhe të normalizojnë konfigurimet e pastrukturuara të pajisjes në një format të strukturuar JSON. Me modulet e burimeve, do të jetë më e lehtë për rrjetet ekzistuese që të transformojnë konfigurimin e tyre në çifte të strukturuara çelës-vlerë që përfaqësojnë një burim të lehtë për t'u lexuar të së vërtetës. Duke përdorur çifte të strukturuara çelës-vlerë, mund të kaloni nga konfigurimet e ekzekutimit në secilën pajisje në punën me të dhëna të strukturuara të pavarura dhe t'i sillni rrjetet në ballë të një qasjeje infrastrukture si kod.
Cilat module burimesh do të vijnë në Ansible Engine 2.9?
Para se t'ju tregojmë në detaje se çfarë do të ndodhë në Ansible 2.9, le të kujtojmë se si e kemi ndarë të gjithë fushën e punës.
Ne identifikuam 7 kategori dhe caktuam burime specifike të rrjetit për secilën:
Shënim: Burimet me shkronja të zeza janë planifikuar dhe zbatuar në Ansible 2.9.
Bazuar në reagimet nga klientët e ndërmarrjeve dhe komuniteti, ishte logjike që fillimisht të trajtoheshin ato module që lidhen me protokollet e topologjisë së rrjetit, virtualizimin dhe ndërfaqet.
Modulet e mëposhtme të burimeve janë zhvilluar nga ekipi i Ansible Network dhe korrespondojnë me platformat e mbështetura nga Red Hat:
Modulet e mëposhtme janë zhvilluar nga komuniteti Ansible:
exos_lldp_global- nga Extreme Networks.nxos_bfd_interfaces- nga Cisconxos_telemetry- nga Cisco
Siç mund ta shihni, koncepti i moduleve të burimeve përshtatet në strategjinë tonë të përqendruar në platformën. Kjo do të thotë, ne përfshijmë aftësitë dhe funksionet e nevojshme në vetë Ansible 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 librave të lojërave Ansible. Për të zgjeruar zhvillimin e moduleve të burimeve, ekipi i Ansible lëshoi mjetin e Ndërtuesit të Moduleve.
Planet për Ansible 2.10 dhe më gjerë
Pasi të lëshohet Ansible 2.9, ne do të punojmë në grupin tjetër të moduleve të burimeve për Ansible 2.10, të cilat mund të përdoren për të konfiguruar më tej topologjinë dhe politikën e rrjetit, p.sh. . Plani i zhvillimit ende mund të rregullohet, kështu që nëse keni komente, ju lutemi raportoni atë .
Burimet dhe fillimi
Burimi: www.habr.com