
NĂ« versionin e ardhshĂ«m tĂ« Red Hat Ansible Engine 2.9 ju presin pĂ«rmirĂ«sime mbresĂ«lĂ«nĂ«se, disa prej tĂ« cilave janĂ« pĂ«rshkruar 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 studiojeni planin e zhvillimit pĂ«r nĂ« faqen wiki pĂ«r .
Siç e shpallëm së fundmi, tani përfshin Ansible Tower, Ansible Engine dhe të gjithë përmbajtjen e Ansible Network. Aktualisht shumica e platformave më të njohura të rrjetit realizohen përmes moduleve 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 të Ansible Automation, .
ĂfarĂ« kemi mĂ«suar
Gjatë katër viteve të fundit, ne kemi mësuar shumë rreth zhvillimit të një platforme për automatizimin e rrjetit. Gjithashtu, ne kemi mësuar se si artefaktet e platformës aplikohen në playbooks dhe rolet e Ansible nga përdoruesit përfundimtarë. Dhe ja çfarë kemi zbuluar:
- Organizatat automatizojnë pajisje nga jo një, por nga shumë ofrues.
- Automatizimi është një fenomen jo vetëm teknik, por gjithashtu kulturor.
- Automatizimi masiv i rrjetit është më i komplikuar seç duket, për shkak të parimeve themelore të arkitekturës së projektimit të automatizimit.
Kur diskutonim planet tona afatgjata të zhvillimit më shumë se një vit më parë, klientët tanë korporativ kërkuan të ardhmen e mëposhtme:
- Mbledhja e të dhënave duhet të standardizohet dhe të përshtatet më mirë me procesin e punës të automatizimit për çdo pajisje.
- Përmirësimi i konfigurimeve në pajisje gjithashtu duhet të standardizohet dhe të sinkronizohet, në mënyrë që modulët e Ansible të përpunojnë pjesën e dytë të ciklit pas mbledhjes së të dhënave.
- Kërkohen metoda të rrepta dhe të mbështetura për të konvertuar konfigurimin e pajisjes në të dhëna të strukturuara. Në këtë bazë, burimi i të vërtetës mund të zhvendoset nga pajisja e rrjetit.
Përmirësimet e të dhënave
Mbledhja e tĂ« dhĂ«nave nga pajisjet rrjetore me Ansible shpesh ndodh nĂ« mĂ«nyrĂ« tĂ« rastĂ«sishme. Platformat rrjetore, nĂ« shkallĂ« tĂ« ndryshme, janĂ« tĂ« pajisura me mundĂ«si mbledhjeje tĂ« tĂ« dhĂ«nave, por ato gati nuk kanĂ« â ose madje fare â funksione pĂ«r tĂ« parse dhe standardizuar paraqitjen e tĂ« dhĂ«nave nĂ« çifte çelĂ«s-vlerĂ«. Lexoni Ken Celenza flet pĂ«r vĂ«shtirĂ«sitĂ« dhe mundimet qĂ« ndodhin kur analizojmĂ« dhe standardizojmĂ« tĂ« dhĂ«nat e fakteve.
Mund t'ju ketë rënë në sy si kemi punuar mbi rolin Ansible Network Engine. Natyrshëm, pas 24,000 shkarkimeve, roli Network Engine shpejt u bë një nga rollet më të njohura në Ansible Galaxy për skenarët e automatizimit të rrjetit. Para se të transferonim shumicën e këtij në Ansible 2.8, për t'u përgatitur për atë që do të nevojitet në Ansible 2.9, ky rol Ansible ofroi një grup të parë mjetesh për ndihmë në përpunimin e komandave, menaxhimin e komandave dhe mbledhjen e të dhënave për pajisjet e rrjetit.
Nëse jeni të familjarizuar me përdorimin e Network Engine, është një mënyrë shumë efikase për mbledhjen, përpunimin 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ë parserësh për çdo platformë dhe për të gjithë aktivitetin e rrjetit. Për të kuptuar sa e vështirë është të krijoni, shpërndani dhe mbani parsera, shikoni nga djemtë e Cisco.
Në pak fjalë, për automatizimin në shkallë të gjerë është shumë e rëndësishme të merrni fakte nga pajisjet dhe t'i normalizoni ato në çifte çelës-vlerë, por arritja e kësaj është e vështirë kur keni shumë ofrues dhe platforma rrjeti.
Ădo modul faktet e rrjetit nĂ« Ansible 2.9 tani mund tĂ« analizojĂ« konfigurimin e pajisjeve rrjetit dhe tĂ« kthejĂ« tĂ« dhĂ«na tĂ« strukturuara â pa nevojĂ«n pĂ«r biblioteka shtesĂ«, role Ansible ose parserĂ« tĂ« personalizuar.
Duke filluar nga Ansible 2.9, me secilën lëshim të moduli të përditësuar rrjeti, moduli i faktit përmirësohet për të ofruar të dhëna rreth këtij seksioni të konfigurimit. Në këtë mënyrë, zhvillimi i faktit dhe moduleve tani ndodh në një ritëm të njëjtë, dhe ata gjithmonë do të kenë një strukturë të përbashkët të dhënash.
Konfigurimi i burimeve në pajisjen rrjet që mund të nxirret dhe të kthehet në të dhëna të strukturuara në dy mënyra. Të dyja mënyrat mund të përdoren për të mbledhur dhe transformuar një listë të caktuar burimesh me fjalën kyçe të re gather_network_resources. Emrat e burimeve përputhen me emrat e moduleve, dhe kjo është shumë praktike.
Gjatë mbledhjes së faktëve:
Me fjalën kyçe gather_facts mund të nxjerrësh konfigurimin aktual të pajisjes në fillim të playbook-ut dhe më pas ta përdorësh atë gjatë gjithë playbook-ut. Specifiko resurset individuale që duhen nxjerrë 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, konkretisht â gather_facts: true tani Ă«shtĂ« nĂ« dispozicion pĂ«r grumbullimin natyror tĂ« fakteve pĂ«r pajisjet rrjet.
Përdorimi i modulit të fakteve rrjet:
- name: mbledh fakte për konfigurimin e ndërfaqeve
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesPlaybook-u kthen fakte të tilla për 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 nxjerr konfigurimin natyror nga pajisja Arista dhe e kthen atë në të dhëna të strukturuara për ta përdorur si çelësa-vlera standarde për detyra dhe operacione të ardhshme.
Faktet e ndërfaqes mund të shtohen në variablat e ruajtura Ansible dhe të përdoren menjëherë ose më vonë si të dhëna hyrëse për modulin e burimit eos_interfaces pa përpunim shtesë ose konvertim.
Modulet e burimeve
Pra, ne kemi nxjerrë faktet, kemi normalizuar të dhënat, i kemi futur ato në një skemë të standardizuar të strukturës së të dhënave dhe kemi marrë një burim më të vërtetë. Hurra! Kjo, për të qenë e sigurt, është fantastike, por ne ende kemi nevojë për diçka për të konvertuar çiftet kyç-vlerë prapa në konfigurimin specifik që pritni nga një platformë specifike të pajisjes. Tani na duhen modulet për platforma të caktuara për të plotësuar këto kërkesa të reja për mbledhjen e faktit dhe normalizimin.
ĂfarĂ« Ă«shtĂ« njĂ« modul burimi? Seksionet e konfigurimit tĂ« pajisjes mund tĂ« pĂ«rfaqĂ«sohen si burime qĂ« ofron kjo pajisje. ModulĂ«t e burimeve rrjetore janĂ« qĂ«llimisht tĂ« kufizuar nĂ« njĂ« burim, dhe ata mund tĂ« vendosen si bricks pĂ«r tĂ« konfiguruar shĂ«rbime komplekse rrjetore. Si rezultat, kĂ«rkesat dhe specifikimi pĂ«r modulĂ«t e burimeve natyrshĂ«m thjeshtohen, pasi moduli i burimeve mund tĂ« lexojĂ« dhe konfiguro shi njĂ« shĂ«rbim tĂ« caktuar nĂ« pajisjen rrjetore.
Për të shpjeguar se çfarë bën moduli i burimeve, le të shqyrtojmë një shembull playbook-u që tregon një operacion idempotent duke përdorur faktet e reja të burimit rrjetor dhe modulit. eos_l3_interface.
- emri: shembulli i faktëve që dërgohen sërish në pajisje.
hosts: arista
gather_facts: false
tasks:
- emri: merr faktet eos të arista
eos_facts:
gather_subset: min
gather_network_resources: l3_interfaces
- emri: sigurohu që informacioni i adresës IP të jetë i saktë
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
register: rezultati
- emri: sigurohu që konfigurimi nuk është ndryshuar
assert:
that: not rezultati.changedSiç e shihni, të dhënat e mbledhura nga pajisja janë transferuar në mënyrë direkte në modulin e burimeve përkatës pa transformim. Gjatë ekzekutimit të playbook-ut, nxirren vlerat nga pajisja dhe krahasohen me ato të pritura. Në këtë shembull, vlerat e marra korrespondohen me ato të pritura (dmth, kontrollohet devijimi i konfigurimit) dhe jepet një mesazh nëse konfigurimi është ndryshuar.
Mënyra ideale për të identifikuar devijimin e konfigurimit është ruajtja e fakteve në variablat e ruajtura Ansible dhe përdorimi i tyre periodik me modul të burimeve në modalitetin e kontrollit. 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, edhe pse shumë operacione kryhen përmes Ansible Automation.
ĂfarĂ« e ndan modulĂ«n e re tĂ« burimeve nga ato tĂ« mĂ«parshmet?
Për inxhinierin e automatizimit të rrjetit, ekzistojnë 3 dallime kryesore të modulateve të burimeve në Ansible 2.9 nga versionet e mëparshme.
1) Për një burim të caktuar rrjeti (i cili mund të përfytyrohet gjithashtu si një seksion konfigurimi), modulat dhe faktet do të evoluojnë në të gjitha sistemet operative të rrjeteve që mbështeten njëkohësisht. Ne mendojmë se, nëse Ansible mbështet konfigurimin e burimit në një platformë rrjeti, ne duhet ta mbështesim kudo. Kjo e bën më të lehtë përdorimin e moduleve të burimeve, sepse inxhinieri i automatizimit të rrjetit tani mund të konfigurojë burimin (p.sh., LLDP) në të gjitha sistemet operative të rrjeteve me modula natyrore dhe të mbështetur.
2) Modulët e resurseve tani përfshijnë vlerën e gjendjes.
të bashkuara: konfigurimi është bashkuar me konfigurimin e ofruar (për defaut);zëvendësuar: konfigurimi i burimeve do të zëvendësohet me konfigurimin e dhënë;tejkaluar: konfigurimi i burimeve do të zëvendësohet me konfigurimin e dhënë; ekzemplarët e panevojshëm të burimeve do të fshihen;fshirë: konfigurimi i burimeve do të fshihet/rikthehet në përmbajtjen e defaut;

3) Modulët e burimeve tani përfshijnë vlera të stabilizuara të kthyera. Kur moduli i burimit të rrjetit bën (ose propozon) ndryshimet e nevojshme në pajisjen e rrjetit, ai kthen të njëjtat çifte çelës-vlerë në libër.
para: konfigurimi në pajisje në formën e të dhënave të strukturuara para detyrës;pas: nëse pajisja është ndryshuar (ose mund të ndryshohet, nëse përdoret moda e kontrollit), konfigurimi që rezulton do të kthehet në formën e të dhënave të strukturuara;komanda: çdo komandë konfigurimi, e cila është ekzekutuar 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?
Kyky tĂ« jetĂ« i ndĂ«rlikuar, ky postim pĂ«rshkruan shumĂ« koncepte tĂ« vĂ«shtira, por shpresojmĂ« qĂ« nĂ« fund tĂ« fundit do tĂ« kuptoni mĂ« mirĂ« se çfarĂ« kĂ«rkojnĂ« klientĂ«t korporatĂ« pĂ«r mbledhjen e tĂ« dhĂ«nave, normalizimin e tĂ« dhĂ«nave dhe konfigurimin e ciklit pĂ«r platformĂ«n e automatizimit. Por pse u duhen kĂ«to pĂ«rmirĂ«sime? Tani shumĂ« organizata janĂ« nĂ« transformimin digjital pĂ«r tĂ« bĂ«rĂ« mjediset e tyre IT mĂ« fleksibile dhe konkurruese. E mira Ă«shtĂ« ose e keqja Ă«shtĂ« se shumĂ« inxhinierĂ« rrjeti po bĂ«hen zhvillues rrjeti â nga interesimi i vet ose nĂ«n urdhrat e menaxherĂ«ve.
Organizatat kuptojnë se automatizimi i shablloneve të veçantë të rrjetit nuk zgjidh problemin e fragmentarizimit dhe rrit efikasitetin vetëm deri në një kufi të caktuar. Platforma Red Hat Ansible Automation Platform ofron modele të dhënash të rrepta dhe normalizuese të burimeve për të menaxhuar në mënyrë programore të dhënat themelore në pajisjen e rrjetit. Kjo do të thotë se përdoruesit gradualisht po heqin dorë nga mënyrat individuale të konfigurimit në favor të metodave më moderne me fokus në teknologji (p.sh. adresat IP, VLAN, LLDP, etj.), dhe jo mbi implementimin specifik të ofruesit.
A do të thotë kjo se ditët e moduleve të besueshëm dhe të verifikuar të komandave dhe konfigurimeve kanë mbaruar? Aspak. Moduloret e pritshme të burimeve rrjet do të zbatohen jo në të gjitha rastet dhe jo për çdo ofrues, kështu që moduloret e komandave dhe konfigurimeve do të jenë ende të nevojshme për inxhinierët e rrjetit për zbatime të caktuara. Qëllimi i moduleve të burimeve është të thjeshtojë modelet e mëdha Jinja dhe të normalizojë konfigurimet e pajisjeve të pa strukturuara 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 të strukturuara kyç-vlerë, të cilat do të përfaqësojnë një burim të vërtetë të lehtë për t'u lexuar. Duke përdorur çifte të strukturuara kyç-vlerë, mund të kaloni nga ekzekutimi i konfigurimeve në çdo pajisje në punimin me të dhëna të strukturuara të pavarura dhe ta vendosni rrjetin në qendër të qasjes "infrastrukturë si kod".
Cilat modulet e burimeve do të dalin në Ansible Engine 2.9?
Para se të flasim në detaje se çfarë do të ketë në Ansible 2.9, le të kujtojmë si e ndamë gjithë volumet e punës.
Ne kemi identifikuar 7 kategori dhe secilës i kemi caktuar burime të caktuara rrjeti:

Shënim: burimet e shkruara me shkronja të theksuara ishin të planifikuara dhe të realizuara në Ansible 2.9.
Bazuar në feedback-un nga klientët korporativë dhe komuniteti, ishte logjike që së pari të merreshim me 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 i përkasin platformave që mbështet 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ç e shihni, koncepti i moduleve të burimeve përputhet me strategjinë tonë të orientimit ndaj platformave. Kjo do të thotë se ne përfshijmë mundësitë dhe funksionalitetet e nevojshme brenda Ansible për të mbështetur standardizimin në zhvillimin e moduleve të rrjetit, si dhe për të thjeshtuar punën e përdoruesve në nivelet e roleve dhe playbook-eve të Ansible. Për të zgjeruar zhvillimin e moduleve të burimeve, ekipi i Ansible lëshoi një instrument Module Builder.
Planet për Ansible 2.10 dhe më tej
Pas daljes që Ansible 2.9, ne do të punojmë për grupin e ardhshëm të moduleve të burimeve për Ansible 2.10, të cilat do të përdoren për konfigurimin e mëtejshëm të topologjisë dhe politikës së rrjetit, siç janë . Plani i zhvillimit ende mund të rregullohet, kështu që, nëse keni komente, ju lutemi informoni .
Burimet dhe fillimi i punës
Burimi: habr.com
