Ang paparating na paglabas ng Red Hat Ansible Engine 2.9 ay nagdudulot ng mga kapana-panabik na pagpapabuti, ang ilan sa mga ito ay tinalakay sa artikulong ito. Gaya ng nakasanayan, bukas kaming bumuo ng mga pagpapahusay ng Ansible Network, na may suporta sa komunidad. Sumali sa amin - tingnan at pag-aralan ang plano sa pagpapaunlad para sa sa pahina ng wiki para sa .
Tulad ng aming inihayag kamakailan, kasama na ngayon ang Ansible Tower, Ansible Engine at lahat ng nilalaman ng Ansible Network. Sa ngayon, ang pinakasikat na networking platform ay ipinapatupad sa pamamagitan ng Ansible modules. Halimbawa:
- Arista EOS
- Ang iOS IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Para sa kumpletong listahan ng mga platform na ganap na sinusuportahan ng Red Hat sa pamamagitan ng Ansible Automation subscription, .
Kung ano ang natutunan natin
Sa nakalipas na apat na taon, marami kaming natutunan tungkol sa pagbuo ng network automation platform. Natutunan din namin yan bilang ginagamit ang mga artifact ng platform sa mga Ansible na playbook at mga tungkulin ng mga end user. At narito ang aming nalaman:
- Ang mga organisasyon ay nag-o-automate ng mga device mula sa hindi lamang isa, ngunit maraming vendor.
- Ang automation ay hindi lamang isang teknikal na kababalaghan, kundi pati na rin sa kultura.
- Ang pag-automate ng mga network sa sukat ay mas mahirap kaysa sa tila dahil sa mga pangunahing prinsipyo ng arkitektura ng disenyo ng automation.
Noong tinalakay namin ang aming mga pangmatagalang plano sa paglago sa nakalipas na isang taon, hiniling ng aming mga corporate client ang sumusunod:
- Ang pagkolekta ng katotohanan ay kailangang maging mas mahusay na na-standardize at naaayon sa mga automation ng workflow sa lahat ng device.
- Ang pag-update ng mga configuration sa device ay kailangan ding maging standardized at pare-pareho para mahawakan ng Ansible modules ang ikalawang kalahati ng cycle pagkatapos mangolekta ng mga katotohanan.
- Kailangan namin ng mahigpit at suportadong pamamaraan para sa pag-convert ng configuration ng device sa structured data. Sa batayan na ito, ang pinagmulan ng katotohanan ay maaaring ilipat mula sa network device.
Mga pagpapabuti ng katotohanan
Ang pagkolekta ng mga katotohanan mula sa mga network device gamit ang Ansible ay kadalasang nangyayari nang random. Ang mga platform na nakabatay sa web ay may iba't ibang antas ng mga kakayahan sa pangangalap ng katotohanan, ngunit mayroon silang kaunti o walang functionality para sa pag-parse at pag-standardize ng representasyon ng data sa mga pares ng key-value. Basahin Ken Celenza kung gaano kahirap at masakit na pag-aralan at i-standardize ang makatotohanang data.
Maaaring napansin mo kaming nagtatrabaho sa tungkulin ng Ansible Network Engine. Natural, 24K na pag-download sa ibang pagkakataon, ang tungkulin ng Network Engine ay mabilis na naging isa sa mga pinakasikat na tungkulin ng Ansible sa Ansible Galaxy para sa mga sitwasyon ng automation ng network. Bago namin ilipat ang karamihan nito sa Ansible 2.8 upang maghanda para sa kung ano ang kakailanganin sa Ansible 2.9, ang tungkuling ito ng Ansible ay nagbigay ng unang hanay ng mga tool upang makatulong sa pag-parse ng mga command, pamamahala ng mga command, at pagkolekta ng data para sa mga network device.
Kung alam mo kung paano gamitin ang Network Engine, isa itong napakahusay na paraan upang mangolekta, mag-parse, at mag-standardize ng fact data para sa paggamit sa Ansible. Ang kawalan ng tungkuling ito ay kailangan mong lumikha ng isang buong grupo ng mga parser para sa bawat platform at para sa lahat ng aktibidad sa network. Upang maunawaan kung gaano kahirap gumawa, magpadala, at magpanatili ng mga parser, tingnan mula sa mga lalaki sa Cisco.
Sa madaling sabi, ang pagkuha ng mga katotohanan mula sa mga device at pag-normalize ang mga ito sa mga key-value pairs ay mahalaga para sa automation sa sukat, ngunit ang pagkamit nito ay mahirap kapag marami kang vendor at network platform.
Ang bawat network fact module sa Ansible 2.9 ay maaari na ngayong suriin ang configuration ng isang network device at ibalik ang structured na data - nang walang karagdagang mga library, Ansible na tungkulin o custom na parser.
Dahil ang Ansible 2.9, sa tuwing may ilalabas na na-update na module ng network, ang fact module ay pinapabuti upang magbigay ng data tungkol sa seksyong ito ng configuration. Iyon ay, ang pagbuo ng mga katotohanan at mga module ay nangyayari na ngayon sa parehong bilis, at sila ay palaging magkakaroon ng isang karaniwang istraktura ng data.
Ang configuration ng mga mapagkukunan sa isang network device ay maaaring makuha at ma-convert sa structured data sa dalawang paraan. Sa parehong paraan, maaari kang mangolekta at magbago ng isang partikular na listahan ng mga mapagkukunan gamit ang isang bagong keyword gather_network_resources. Ang mga pangalan ng mapagkukunan ay tumutugma sa mga pangalan ng module, na napakaginhawa.
Habang nagtitipon ng mga katotohanan:
Gamit ang isang keyword gather_facts maaari mong makuha ang kasalukuyang configuration ng device sa simula ng playbook, at pagkatapos ay gamitin ito sa buong playbook. Tukuyin ang mga indibidwal na mapagkukunan na kukunin mula sa device.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueMaaaring may napansin kang bago sa mga halimbawang ito, ibig sabihin - gather_facts: true ay available na ngayon para sa native fact collection para sa network device.
Direktang paggamit ng network fact module:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesIbinabalik ng playbook ang mga sumusunod na katotohanan tungkol sa interface:
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: Ethernet1Pansinin kung paano kinukuha ng Ansible ang native na configuration mula sa Arista device at ginagawa itong structured na data upang magamit bilang karaniwang mga pares ng key-value para sa mga downstream na gawain at pagpapatakbo.
Maaaring idagdag ang mga katotohanan ng interface sa mga variable na naka-imbak ng Ansible at agad na gamitin o mas bago bilang input sa isang resource module eos_interfaces nang walang karagdagang pagproseso o conversion.
Mga Resource Module
Kaya, kinuha namin ang mga katotohanan, ginawang normal ang data, iniakma ang mga ito sa isang standardized na panloob na diagram ng istruktura ng data at nakatanggap ng isang handa na pinagmumulan ng katotohanan. Hooray! Mahusay ito, siyempre, ngunit kailangan pa rin nating i-convert ang mga pares ng key-value pabalik sa partikular na configuration na inaasahan ng partikular na platform ng device. Kailangan namin ngayon ng mga module na partikular sa platform upang matugunan ang mga bagong kinakailangan sa pangangalap ng katotohanan at normalisasyon na ito.
Ano ang resource module? Maaari mong isipin ang mga seksyon ng configuration ng isang device bilang mga mapagkukunang ibinibigay ng device na iyon. Ang mga module ng mapagkukunan ng network ay sadyang limitado sa isang mapagkukunan at maaaring isalansan tulad ng mga bloke ng gusali upang i-configure ang mga kumplikadong serbisyo ng network. Bilang resulta, ang mga kinakailangan at detalye para sa isang resource module ay natural na pinasimple, dahil ang resource module ay nakakabasa. ΠΈ i-configure ang isang partikular na serbisyo ng network sa isang network device.
Upang ipaliwanag kung ano ang ginagawa ng isang resource module, tingnan natin ang isang halimbawang playbook na nagpapakita ng isang idempodent na operasyon gamit ang mga bagong network resource facts at module. 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.changedTulad ng nakikita mo, ang data na nakolekta mula sa device ay direktang inililipat sa kaukulang resource module nang walang conversion. Kapag inilunsad, kinukuha ng playbook ang mga halaga mula sa device at inihahambing ang mga ito sa mga inaasahan. Sa halimbawang ito, ang mga ibinalik na halaga ay tulad ng inaasahan (iyon ay, sinusuri nito ang mga paglihis ng configuration) at nag-uulat kung nagbago ang configuration.
Ang mainam na paraan upang matukoy ang pag-anod ng configuration ay ang pag-imbak ng mga katotohanan sa mga naka-imbak na variable ng Ansible at pana-panahong gamitin ang mga ito kasama ng resource module sa inspection mode. Ito ay isang simpleng paraan upang makita kung ang isang tao ay manu-manong binago ang mga halaga. Sa karamihan ng mga kaso, pinapayagan ng mga organisasyon ang mga pagbabago at pagsasaayos nang manu-mano, bagama't maraming operasyon ang ginagawa sa pamamagitan ng Ansible Automation.
Paano naiiba ang mga bagong module ng mapagkukunan mula sa mga nauna?
Para sa isang network automation engineer, mayroong 3 pangunahing pagkakaiba sa pagitan ng mga resource module sa Ansible 2.9 at mga nakaraang bersyon.
1) Para sa isang ibinigay na mapagkukunan ng network (na maaari ding ituring bilang isang seksyon ng pagsasaayos), ang mga module at katotohanan ay magbabago sa lahat ng suportadong mga operating system ng network nang sabay-sabay. Sa tingin namin, kung sinusuportahan ng Ansible ang pagsasaayos ng mapagkukunan sa isang platform ng network, dapat namin itong suportahan kahit saan. Pinapasimple nito ang paggamit ng mga resource module dahil ang isang network automation engineer ay maaari na ngayong mag-configure ng resource (gaya ng LLDP) sa lahat ng network operating system na may native at suportadong mga module.
2) Ang mga module ng mapagkukunan ay may kasama na ngayong halaga ng estado.
merged: ang pagsasaayos ay pinagsama sa ibinigay na pagsasaayos (default);replaced: Ang pagsasaayos ng mapagkukunan ay papalitan ng ibinigay na pagsasaayos;overridden: Ang pagsasaayos ng mapagkukunan ay papalitan ng ibinigay na pagsasaayos; tatanggalin ang mga hindi kinakailangang mapagkukunan;deleted: Ang pagsasaayos ng mapagkukunan ay tatanggalin/ibabalik sa default.
3) Kasama na ngayon sa mga resource module ang mga stable na return value. Kapag ginawa (o iminungkahi) ng network resource module ang mga kinakailangang pagbabago sa network device, ibinabalik nito ang parehong key-value pairs sa playbook.
before: configuration sa device sa anyo ng structured data bago ang gawain;after: kung nagbago ang device (o maaaring magbago kung ginamit ang test mode), ibabalik ang resultang configuration bilang structured data;commands: Ang anumang mga command sa pagsasaayos ay tumatakbo sa device upang dalhin ito sa nais na estado.
Ano ang ibig sabihin ng lahat ng ito? Bakit ito mahalaga?
Sinasaklaw ng post na ito ang maraming kumplikadong konsepto, ngunit umaasa kami na sa huli ay magkakaroon ka ng mas mahusay na pag-unawa sa kung ano ang hinihingi ng mga kliyente ng enterprise sa katunayan ng pagkolekta, pag-normalize ng data, at pagsasaayos ng loop para sa isang automation platform. Ngunit bakit kailangan nila ang mga pagpapahusay na ito? Maraming organisasyon ang nagsasagawa na ngayon ng digital transformation para gawing mas maliksi at mapagkumpitensya ang kanilang mga IT environment. Para sa mas mabuti o mas masahol pa, maraming network engineer ang nagiging network developer para sa sariling interes o sa utos ng management.
Napagtatanto ng mga organisasyon na ang pag-automate ng mga indibidwal na template ng network ay hindi malulutas ang problema ng mga silos at pinatataas lamang ang kahusayan sa isang tiyak na lawak. Ang Red Hat Ansible Automation Platform ay nagbibigay ng mahigpit at normatibong mga modelo ng data ng mapagkukunan upang maprograma na pamahalaan ang pinagbabatayan ng data sa isang network device. Ibig sabihin, unti-unting inabandona ng mga user ang mga indibidwal na paraan ng pagsasaayos sa pabor sa mas modernong mga pamamaraan na may diin sa mga teknolohiya (halimbawa, mga IP address, VLAN, LLDP, atbp.), sa halip na sa isang partikular na pagpapatupad ng vendor.
Nangangahulugan ba ito na ang mga araw ng maaasahan at napatunayang command module at configuration ay binibilang? Sa anumang kaso. Ang inaasahang network resource modules ay hindi magiging applicable sa lahat ng kaso o para sa bawat vendor, kaya ang command at configuration module ay kakailanganin pa rin ng mga network engineer para sa ilang partikular na pagpapatupad. Ang layunin ng mga resource module ay pasimplehin ang malalaking template ng Jinja at gawing normal ang mga hindi nakabalangkas na configuration ng device sa isang structured na JSON na format. Sa mga resource module, magiging mas madali para sa mga kasalukuyang network na ibahin ang kanilang configuration sa structured key-value pairs na kumakatawan sa isang madaling basahin na pinagmulan ng katotohanan. Sa pamamagitan ng paggamit ng mga structured key-value pairs, maaari kang lumipat mula sa pagpapatakbo ng mga configuration sa bawat device patungo sa pagtatrabaho sa independiyenteng structured data at dalhin ang mga network sa unahan ng isang diskarte sa imprastraktura-bilang-code.
Anong mga resource module ang darating sa Ansible Engine 2.9?
Bago namin sabihin sa iyo nang detalyado kung ano ang mangyayari sa Ansible 2.9, tandaan natin kung paano natin hinati ang buong saklaw ng trabaho.
Natukoy namin ang 7 kategorya at nagtalaga ng mga partikular na mapagkukunan ng network sa bawat isa:
Tandaan: Ang mga mapagkukunan sa bold ay binalak at ipinatupad sa Ansible 2.9.
Batay sa feedback mula sa mga customer ng enterprise at sa komunidad, makatuwirang harapin muna ang mga module na iyon na nauugnay sa mga protocol ng topology ng network, virtualization, at mga interface.
Ang mga sumusunod na resource module ay binuo ng Ansible Network team at tumutugma sa mga platform na sinusuportahan ng Red Hat:
Ang mga sumusunod na module ay binuo ng Ansible na komunidad:
exos_lldp_global- mula sa Extreme Networks.nxos_bfd_interfaces- mula sa Cisconxos_telemetry- mula sa Cisco
Gaya ng nakikita mo, ang konsepto ng mga resource module ay umaangkop sa aming platform-centric na diskarte. Ibig sabihin, isinama namin ang mga kinakailangang kakayahan at function sa Ansible mismo upang suportahan ang standardisasyon sa pagbuo ng mga module ng network, at para din gawing simple ang gawain ng mga user sa antas ng mga tungkulin at playbook ng Ansible. Upang palawakin ang pagbuo ng mga module ng mapagkukunan, inilabas ng koponan ng Ansible ang tool na Tagabuo ng Module.
Mga Plano para sa Ansible 2.10 at higit pa
Kapag nai-release na ang Ansible 2.9, gagawa kami ng susunod na hanay ng mga resource module para sa Ansible 2.10, na magagamit upang higit pang i-configure ang topology at patakaran ng network, hal. . Ang plano sa pag-unlad ay maaari pa ring ayusin, kaya kung mayroon kang mga komento, mangyaring iulat ito sa .
Mga mapagkukunan at pagsisimula
Pinagmulan: www.habr.com