La venonta eldono de Red Hat Ansible Engine 2.9 alportas ekscitajn plibonigojn, iuj el kiuj estas kovritaj en ĉi tiu artikolo. Kiel ĉiam, ni disvolvis plibonigojn de Ansible Network malkaŝe, kun komunuma subteno. Aliĝu al ni - rigardu
Kiel ni lastatempe anoncis,
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Junipero Junos
- VyOS
Por kompleta listo de platformoj, kiuj estas plene subtenataj de Red Hat per abono de Ansible Automation,
Kion ni lernis
Dum la pasintaj kvar jaroj, ni lernis multon pri evoluigado de reto-aŭtomatiga platformo. Ni ankaŭ lernis tion kiom platformartefaktoj estas uzitaj en Ansible-ludlibroj kaj roloj fare de finuzantoj. Kaj jen kion ni eksciis:
- Organizoj aŭtomatigas aparatojn de ne nur unu, sed multaj vendistoj.
- Aŭtomatigo estas ne nur teknika fenomeno, sed ankaŭ kultura.
- Aŭtomatigi retojn skale estas pli malfacila ol ĝi ŝajnas pro la fundamentaj arkitekturaj principoj de aŭtomatiga dezajno.
Kiam ni diskutis pri niaj longdaŭraj kreskplanoj antaŭ pli ol unu jaro, niaj kompaniaj klientoj petis la jenon:
- Faktkolekto devas esti pli bone normigita kaj akordigita kun aŭtomatigaj laborfluoj tra ĉiuj aparatoj.
- Ĝisdatigi agordojn sur la aparato ankaŭ devas esti normigita kaj konsekvenca por ke Ansible-moduloj traktu la duan duonon de la ciklo post kolektado de faktoj.
- Ni bezonas rigorajn kaj subtenatajn metodojn por konverti aparatan agordon en strukturitajn datumojn. Sur ĉi tiu bazo, la fonto de vero povas esti movita de la reto-aparato.
Faktaj plibonigoj
Kolekti faktojn de retaj aparatoj uzante Ansible ofte okazas hazarde. Ret-bazitaj platformoj havas diversajn gradojn da fakto-kolektaj kapabloj, sed ili havas malmulte aŭ neniun funkciecon por analizado kaj normigado de la reprezentado de datenoj en ŝlosil-valoraj paroj. Legu
Vi eble rimarkis, ke ni laboras pri la rolo de Ansible Network Engine. Kompreneble, 24K elŝutas poste, la rolo de Network Engine rapide fariĝis unu el la plej popularaj Ansible-roloj en Ansible Galaxy por retaj aŭtomatigaj scenaroj. Antaŭ ol ni movis multon de ĉi tio en Ansible 2.8 por prepari por tio, kio bezonus en Ansible 2.9, ĉi tiu Ansible-rolo disponigis la unuan aron da iloj por helpi analizi komandojn, administri komandojn kaj kolekti datumojn por retaj aparatoj.
Se vi scias kiel uzi Retan Motoron, ĉi tio estas tre efika maniero kolekti, analizi kaj normigi faktojn por uzi en Ansible. La malavantaĝo de ĉi tiu rolo estas, ke vi devas krei tutan aron da analiziloj por ĉiu platformo kaj por ĉiu reto-agado. Por kompreni kiom malfacile estas krei, sendi kaj konservi analizilojn, rigardu
En resumo, akiri faktojn de aparatoj kaj normaligi ilin en ŝlosil-valorajn parojn estas esenca por aŭtomatigo ĉe skalo, sed atingi ĉi tion estas malfacila kiam vi havas multajn vendistojn kaj retajn platformojn.
Ĉiu reto-fakta modulo en Ansible 2.9 nun povas analizi la agordon de reto-aparato kaj resendi strukturitajn datumojn - sen pliaj bibliotekoj, Ansible-roloj aŭ kutimaj analiziloj.
Ekde Ansible 2.9, ĉiufoje kiam ĝisdatigita retmodulo estas liberigita, la fakta modulo estas plibonigita por provizi datumojn pri ĉi tiu sekcio de la agordo. Tio estas, la disvolviĝo de faktoj kaj moduloj nun okazas samrapide, kaj ili ĉiam havos komunan datumstrukturon.
La agordo de resursoj sur reta aparato povas esti prenita kaj konvertita en strukturitajn datenojn en du manieroj. Ambaŭmaniere, vi povas kolekti kaj transformi specifan liston de rimedoj uzante novan ŝlosilvorton gather_network_resources
. La nomoj de rimedoj kongruas kun la nomoj de moduloj, kio estas tre oportuna.
Dum kolektado de faktoj:
Uzante ŝlosilvorton gather_facts
vi povas retrovi la nunan aparatan agordon komence de la ludlibro, kaj poste uzi ĝin tra la tuta ludlibro. Indiku la individuajn rimedojn por esti prenitaj de la aparato.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: True
Vi eble rimarkis ion novan en ĉi tiuj ekzemploj, nome - gather_facts: true
nun disponeblas por denaska fakkolekto por retaj aparatoj.
Uzante la retan faktomodulon rekte:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
La ludlibro resendas la sekvajn faktojn pri la interfaco:
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: Ethernet1
Rimarku kiel Ansible prenas la indiĝenan agordon de la Arista aparato kaj transformas ĝin en strukturitajn datumojn por uzi kiel normajn ŝlosilvalorajn parojn por kontraŭfluaj taskoj kaj operacioj.
Interfacfaktoj povas esti aldonitaj al Ansible konservitaj variabloj kaj uzataj tuj aŭ poste kiel enigo al rimedmodulo eos_interfaces
sen plia prilaborado aŭ konvertiĝo.
Rimedaj Moduloj
Do, ni ĉerpis la faktojn, normaligis la datumojn, ĝustigis ilin en normigita interna datumstrukturdiagramo kaj ricevis pretan fonton de vero. Hura! Ĉi tio estas bonega, kompreneble, sed ni ankoraŭ bezonas iel konverti la ŝlosil-valorajn parojn reen al la specifa agordo, kiun la specifa aparato-platformo atendas. Ni nun bezonas platform-specifajn modulojn por plenumi ĉi tiujn novajn postulojn pri fakto-kolektado kaj normaligo.
Kio estas rimedmodulo? Vi povas pensi pri la agordaj sekcioj de aparato kiel rimedoj provizitaj de tiu aparato. Retaj rimedmoduloj estas intencite limigitaj al ununura rimedo kaj povas esti stakitaj kiel konstrubriketoj por agordi kompleksajn retajn servojn. Kiel rezulto, la postuloj kaj specifo por rimedmodulo estas nature simpligitaj, ĉar la rimedmodulo povas legi и agordi specifan retan servon sur reta aparato.
Por klarigi kion faras rimedmodulo, ni rigardu ekzemplan ludlibron, kiu montras idempodentan operacion uzante novajn retajn rimedfaktojn kaj modulon. 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.changed
Kiel vi povas vidi, la datumoj kolektitaj de la aparato estas transdonitaj rekte al la responda rimeda modulo sen konvertiĝo. Kiam estas lanĉita, la ludlibro prenas valorojn de la aparato kaj komparas ilin kun atendataj valoroj. En ĉi tiu ekzemplo, la valoroj redonitaj estas kiel atenditaj (tio estas, ĝi kontrolas por agordaj devioj) kaj raportas ĉu la agordo ŝanĝiĝis.
La ideala maniero por detekti agordan drivon estas stoki faktojn en Ansible konservitaj variabloj kaj periode uzi ilin kun la rimedmodulo en inspekta reĝimo. Ĉi tio estas simpla metodo por vidi ĉu iu mane ŝanĝis la valorojn. Plejofte, organizoj permesas ŝanĝojn kaj agordon permane, kvankam multaj operacioj estas faritaj per Ansible Automation.
Kiel la novaj rimedmoduloj diferencas de la antaŭaj?
Por retaŭtomatiga inĝeniero, ekzistas 3 ĉefaj diferencoj inter rimedmoduloj en Ansible 2.9 kaj antaŭaj versioj.
1) Por antaŭfiksita retrimedo (kiu ankaŭ povas esti opiniita kiel agorda sekcio), moduloj kaj faktoj evoluos tra ĉiuj subtenataj retaj operaciumoj samtempe. Ni pensas, ke se Ansible subtenas rimedan agordon sur unu retoplatformo, ni devus subteni ĝin ĉie. Tio simpligas la uzon de rimedmoduloj ĉar retaŭtomatigo-inĝeniero nun povas agordi rimedon (kiel ekzemple LLDP) sur ĉiuj retaj operaciumoj kun indiĝenaj kaj subtenataj moduloj.
2) Rimedaj moduloj nun inkluzivas ŝtatan valoron.
merged
: la agordo estas kunfandita kun la provizita agordo (defaŭlte);replaced
: La rimeda agordo estos anstataŭigita per la provizita agordo;overridden
: La rimeda agordo estos anstataŭigita per la provizita agordo; nenecesaj rimedokazaĵoj estos forigitaj;deleted
: La rimeda agordo estos forigita/restarigita defaŭlte.
3) Rimedaj moduloj nun inkluzivas stabilajn revenvalorojn. Kiam la reto-rimeda modulo faris (aŭ proponis) la necesajn ŝanĝojn al la reta aparato, ĝi resendas la samajn ŝlosil-valorajn parojn al la ludlibro.
before
: agordo sur la aparato en formo de strukturitaj datumoj antaŭ la tasko;after
: se la aparato ŝanĝiĝis (aŭ eble ŝanĝiĝos se testareĝimo estas uzata), la rezulta agordo estos resendita kiel strukturitaj datumoj;commands
: Ĉiuj agordaj komandoj funkcias sur la aparato por alporti ĝin en la deziratan staton.
Kion ĉio ĉi signifas? Kial ĝi estas grava?
Ĉi tiu afiŝo kovras multajn kompleksajn konceptojn, sed ni esperas, ke finfine vi havos pli bonan komprenon pri tio, kion entreprenaj klientoj petas fakte kolekton, datumnormaligon kaj buklan agordon por aŭtomatiga platformo. Sed kial ili bezonas ĉi tiujn plibonigojn? Multaj organizoj nun traktas ciferecan transformon por fari siajn IT-mediojn pli lertaj kaj konkurencivaj. Por pli bone aŭ malbone, multaj retaj inĝenieroj fariĝas retaj programistoj aŭ pro propra intereso aŭ laŭ ordono de administrado.
Organizoj rimarkas, ke aŭtomatigi individuajn retajn ŝablonojn ne solvas la problemon de siloj kaj nur certagrade pliigas efikecon. La Red Hat Ansible Automation Platform disponigas rigorajn kaj normigajn rimedojn datummodelojn por programe administri la subestajn datumojn sur reta aparato. Tio estas, uzantoj iom post iom forlasas individuajn agordajn metodojn en favoro de pli modernaj metodoj kun emfazo sur teknologioj (ekzemple, IP-adresoj, VLANoj, LLDP, ktp.), prefere ol sur specifa vendista efektivigo.
Ĉu ĉi tio signifas, ke la tagoj de fidindaj kaj pruvitaj komandmoduloj kaj agordo estas nombritaj? En neniu kazo. La atendataj retaj rimedmoduloj ne estos uzeblaj en ĉiuj kazoj aŭ por ĉiu vendisto, do la komando- kaj agordaj moduloj ankoraŭ estos bezonataj de retaj inĝenieroj por certaj efektivigoj. La celo de rimedmoduloj estas simpligi grandajn Jinja-ŝablonojn kaj normaligi nestrukturitajn aparatajn agordojn en strukturitan JSON-formaton. Kun rimedmoduloj, estos pli facile por ekzistantaj retoj transformi sian agordon en strukturitajn ŝlosil-valorajn parojn, kiuj reprezentas facile legeblan fonton de vero. Uzante strukturitajn ŝlosil-valorajn parojn, vi povas moviĝi de funkciado de agordoj sur ĉiu aparato al labori kun sendependaj strukturitaj datumoj kaj alporti retojn al la avangardo de infrastruktura-kiel-koda aliro.
Kiuj rimedmoduloj venos en Ansible Engine 2.9?
Antaŭ ol ni rakontos al vi detale, kio okazos en Ansible 2.9, ni memoru kiel ni dividis la tutan amplekson de laboro.
Ni identigis 7 kategoriojn kaj asignis specifajn retajn rimedojn al ĉiu:
Noto: Rimedoj en grasa skribo estis planitaj kaj efektivigitaj en Ansible 2.9.
Surbaze de sugestoj de entreprenaj klientoj kaj la komunumo, estis logike unue trakti tiujn modulojn ligitajn al retaj topologiaj protokoloj, virtualigo kaj interfacoj.
La sekvaj rimedmoduloj estis evoluigitaj de la teamo de Ansible Network kaj respondas al la platformoj subtenataj de Red Hat:
La sekvaj moduloj estas evoluigitaj fare de la Ansible-komunumo:
exos_lldp_global
- de Ekstremaj Retoj.nxos_bfd_interfaces
- de Cisconxos_telemetry
- de Cisco
Kiel vi povas vidi, la koncepto de rimedmoduloj konvenas al nia platform-centra strategio. Tio estas, ni inkluzivas la necesajn kapablojn kaj funkciojn en Ansible mem por subteni normigon en la disvolviĝo de retaj moduloj, kaj ankaŭ por simpligi la laboron de uzantoj je la nivelo de roloj kaj ludlibroj de Ansible. Por vastigi la evoluon de rimedmoduloj, la Ansible-teamo publikigis la Module Builder-ilon.
Planoj por Ansible 2.10 kaj poste
Post kiam Ansible 2.9 estos liberigita, ni laboros pri la sekva aro de rimedmoduloj por Ansible 2.10, kiu povas esti uzata por plue agordi retan topologion kaj politikon, ekz.
Rimedoj kaj komenci
fonto: www.habr.com