Būsimas „Red Hat Ansible Engine 2.9“ leidimas atneš įdomių patobulinimų, kai kurie iš jų aptariami šiame straipsnyje. Kaip visada, „Ansible Network“ patobulinimus kūrėme atvirai, padedami bendruomenės. Prisijunk prie mūsų – pažiūrėk ir išstudijuoti plėtros planą wiki puslapyje .
Kaip neseniai paskelbėme, dabar apima Ansible Tower, Ansible Engine ir visą Ansible Network turinį. Šiuo metu populiariausios tinklo platformos yra įdiegtos per Ansible modulius. Pavyzdžiui:
- „Arista EOS“
- „Cisco IOS“
- Cisco IOS XR
- Cisco NX-OS
- Kadagys Junos
- VyOS
Norėdami gauti visą sąrašą platformų, kurias visiškai palaiko Red Hat per Ansible Automation prenumeratą, .
Ko mes išmokome
Per pastaruosius ketverius metus daug sužinojome apie tinklo automatizavimo platformos kūrimą. Mes taip pat to išmokome kaip platformos artefaktus galutiniai vartotojai naudoja Ansible žaidimų knygelėse ir vaidmenyse. Ir štai ką mes sužinojome:
- Organizacijos automatizuoja ne tik vieno, bet ir daugelio pardavėjų įrenginius.
- Automatika yra ne tik techninis, bet ir kultūrinis reiškinys.
- Tinklų automatizavimas dideliu mastu yra sudėtingesnis nei atrodo dėl pagrindinių automatizavimo projektavimo architektūrinių principų.
Kai daugiau nei prieš metus aptarėme savo ilgalaikius augimo planus, mūsų verslo klientai paprašė:
- Faktų rinkimas turi būti geriau standartizuotas ir suderintas su automatizavimo darbo eigomis visuose įrenginiuose.
- Įrenginio konfigūracijų atnaujinimas taip pat turi būti standartizuotas ir nuoseklus, kad surinkę faktus Ansible moduliai atliktų antrąją ciklo pusę.
- Mums reikia griežtų ir palaikomų metodų, kaip įrenginio konfigūraciją konvertuoti į struktūrinius duomenis. Šiuo pagrindu tiesos šaltinis gali būti perkeltas iš tinklo įrenginio.
Faktų patobulinimai
Faktų rinkimas iš tinklo įrenginių naudojant Ansible dažnai vyksta atsitiktinai. Žiniatinklio platformos turi įvairaus laipsnio faktų rinkimo galimybių, tačiau jos turi mažai arba visai neturi funkcijų analizuoti ir standartizuoti duomenų pateikimą raktų ir reikšmių porose. Skaityti Kenas Celenza apie tai, kaip sunku ir skausminga gali būti analizuoti ir standartizuoti faktinius duomenis.
Galbūt pastebėjote, kad dirbame su Ansible Network Engine vaidmeniu. Žinoma, vėliau, 24 2.8 atsisiuntimų, tinklo variklio vaidmuo greitai tapo vienu iš populiariausių Ansible Galaxy vaidmenų tinklo automatizavimo scenarijuose. Prieš perkeldami daugumą į Ansible 2.9, kad pasiruoštume tai, ko reikės Ansible XNUMX versijoje, šis Ansible vaidmuo suteikė pirmąjį įrankių rinkinį, padedantį analizuoti komandas, valdyti komandas ir rinkti duomenis tinklo įrenginiams.
Jei žinote, kaip naudoti tinklo variklį, tai labai efektyvus būdas rinkti, analizuoti ir standartizuoti faktų duomenis, skirtus naudoti Ansible. Šio vaidmens trūkumas yra tas, kad kiekvienai platformai ir visai tinklo veiklai reikia sukurti visą krūvą analizatorių. Norėdami suprasti, kaip sunku sukurti, išsiųsti ir prižiūrėti analizatorius, pažiūrėkite iš „Cisco“ vaikinų.
Trumpai tariant, faktų gavimas iš įrenginių ir jų normalizavimas į pagrindinių verčių poras yra labai svarbus automatizavimui dideliu mastu, tačiau tai pasiekti sunku, kai turite daug pardavėjų ir tinklo platformų.
Kiekvienas Ansible 2.9 tinklo faktų modulis dabar gali analizuoti tinklo įrenginio konfigūraciją ir grąžinti struktūrizuotus duomenis – be papildomų bibliotekų, Ansible vaidmenų ar pasirinktinių analizatorių.
Nuo Ansible 2.9 kiekvieną kartą, kai išleidžiamas atnaujintas tinklo modulis, faktų modulis yra patobulintas, kad būtų pateikti duomenys apie šią konfigūracijos skyrių. Tai reiškia, kad faktų ir modulių kūrimas dabar vyksta tuo pačiu tempu, ir jie visada turės bendrą duomenų struktūrą.
Tinklo įrenginio išteklių konfigūraciją galima gauti ir konvertuoti į struktūrinius duomenis dviem būdais. Abiem būdais galite rinkti ir transformuoti konkretų išteklių sąrašą naudodami naują raktinį žodį gather_network_resources. Išteklių pavadinimai sutampa su modulių pavadinimais, o tai labai patogu.
Renkant faktus:
Naudojant raktinį žodį gather_facts Dabartinę įrenginio konfigūraciją galite nuskaityti vadovo pradžioje ir naudoti ją visoje žaidimų knygelėje. Nurodykite atskirus išteklius, kuriuos reikia gauti iš įrenginio.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueGalbūt šiuose pavyzdžiuose pastebėjote kažką naujo, būtent - gather_facts: true dabar galima rinkti vietinius faktus tinklo įrenginiams.
Tiesiogiai naudojant tinklo faktų modulį:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesVadovėlyje pateikiami šie faktai apie sąsają:
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: Ethernet1Atkreipkite dėmesį, kaip Ansible nuskaito savąją konfigūraciją iš „Arista“ įrenginio ir paverčia ją struktūriniais duomenimis, kad būtų galima naudoti kaip standartines raktų ir verčių poras tolesniems darbams ir operacijoms.
Sąsajos faktai gali būti pridėti prie Ansible saugomų kintamųjų ir naudojami iš karto arba vėliau kaip įvestis į išteklių modulį eos_interfaces be papildomo apdorojimo ar konvertavimo.
Išteklių moduliai
Taigi, mes ištraukėme faktus, normalizavome duomenis, sutalpinome juos į standartizuotą vidinės duomenų struktūros diagramą ir gavome paruoštą tiesos šaltinį. Sveika! Tai, žinoma, puiku, bet vis tiek turime kažkaip konvertuoti raktų ir reikšmių poras į konkrečią konfigūraciją, kurios tikisi konkreti įrenginio platforma. Dabar mums reikia konkrečios platformos modulių, kad atitiktume šiuos naujus faktų rinkimo ir normalizavimo reikalavimus.
Kas yra išteklių modulis? Įrenginio konfigūracijos skyrius galite laikyti to įrenginio teikiamais ištekliais. Tinklo išteklių moduliai yra sąmoningai apriboti vienu ištekliu ir gali būti sukrauti kaip sudedamieji blokai, siekiant konfigūruoti sudėtingas tinklo paslaugas. Dėl to išteklių modulio reikalavimai ir specifikacijos yra natūraliai supaprastinti, nes išteklių modulis gali skaityti и konfigūruoti konkrečią tinklo paslaugą tinklo įrenginyje.
Norėdami paaiškinti, ką veikia išteklių modulis, pažvelkime į pavyzdinę knygą, kurioje parodyta idempodentiška operacija naudojant naujus tinklo išteklių faktus ir modulį. 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.changedKaip matote, iš įrenginio surinkti duomenys be konvertavimo perduodami tiesiai į atitinkamą išteklių modulį. Paleidus žaidimo knygelę, ji nuskaito reikšmes iš įrenginio ir palygina jas su laukiamomis. Šiame pavyzdyje grąžintos vertės yra tokios, kokios tikėtasi (ty patikrinama, ar nėra konfigūracijos nukrypimų) ir pranešama, ar konfigūracija pasikeitė.
Idealus būdas aptikti konfigūracijos poslinkį yra saugoti faktus Ansible saugomuose kintamuosiuose ir periodiškai naudoti juos su išteklių moduliu tikrinimo režimu. Tai paprastas būdas patikrinti, ar kas nors rankiniu būdu nepakeitė reikšmių. Daugeliu atvejų organizacijos leidžia keisti ir konfigūruoti rankiniu būdu, nors daugelis operacijų atliekamos naudojant Ansible Automation.
Kuo nauji išteklių moduliai skiriasi nuo ankstesnių?
Tinklo automatizavimo inžinieriui yra 3 pagrindiniai Ansible 2.9 ir ankstesnių versijų išteklių modulių skirtumai.
1) Tam tikram tinklo ištekliui (kuris taip pat gali būti laikomas konfigūracijos skyriumi) moduliai ir faktai vystysis visose palaikomose tinklo operacinėse sistemose vienu metu. Manome, kad jei Ansible palaiko išteklių konfigūraciją vienoje tinklo platformoje, turėtume ją palaikyti visur. Tai supaprastina išteklių modulių naudojimą, nes tinklo automatizavimo inžinierius dabar gali konfigūruoti išteklius (pvz., LLDP) visose tinklo operacinėse sistemose su vietiniais ir palaikomais moduliais.
2) Išteklių moduliuose dabar yra būsenos reikšmė.
merged: konfigūracija sujungiama su pateikta konfigūracija (numatytasis);replaced: išteklių konfigūracija bus pakeista pateikta konfigūracija;overridden: išteklių konfigūracija bus pakeista pateikta konfigūracija; bus ištrinti nereikalingi išteklių egzemplioriai;deleted: išteklių konfigūracija bus ištrinta / atkurta pagal numatytuosius nustatymus.
3) Išteklių moduliuose dabar yra stabilios grąžinimo reikšmės. Kai tinklo išteklių modulis atlieka (arba pasiūlo) reikiamus tinklo įrenginio pakeitimus, jis grąžina tas pačias raktų ir reikšmių poras į aprašą.
before: konfigūracija įrenginyje struktūrinių duomenų forma prieš užduotį;after: jei įrenginys pasikeitė (arba gali pasikeisti, jei naudojamas bandymo režimas), gauta konfigūracija bus grąžinta kaip struktūriniai duomenys;commands: Įrenginyje paleidžiamos visos konfigūracijos komandos, kad būtų galima įjungti norimą būseną.
Ką visa tai reiškia? Kodėl tai svarbu?
Šis įrašas apima daug sudėtingų sąvokų, tačiau tikimės, kad galų gale geriau suprasite, ko įmonės klientai iš tikrųjų prašo rinkti, normalizuoti duomenis ir automatizavimo platformos kilpos konfigūraciją. Bet kodėl jiems reikia šių patobulinimų? Daugelis organizacijų šiuo metu vykdo skaitmeninę transformaciją, kad jų IT aplinka taptų lankstesnė ir konkurencingesnė. Gerai ar blogai, daugelis tinklo inžinierių tampa tinklo kūrėjais iš savo interesų arba vadovybės nurodymu.
Organizacijos suvokia, kad atskirų tinklo šablonų automatizavimas silosų problemos neišsprendžia ir tik tam tikru mastu padidina efektyvumą. „Red Hat Ansible Automation Platform“ teikia griežtus ir normatyvinius išteklių duomenų modelius, kad būtų galima programiškai valdyti pagrindinius tinklo įrenginio duomenis. Tai reiškia, kad vartotojai palaipsniui atsisako individualių konfigūravimo metodų ir pasirenka modernesnius metodus, daugiausia dėmesio skiriant technologijoms (pavyzdžiui, IP adresams, VLAN, LLDP ir kt.), o ne konkretaus tiekėjo įgyvendinimui.
Ar tai reiškia, kad patikimų ir patikrintų komandų modulių ir konfigūracijos dienos yra suskaičiuotos? Jokiu būdu. Numatomi tinklo išteklių moduliai nebus taikomi visais atvejais arba ne kiekvienam tiekėjui, todėl komandų ir konfigūracijos modulių vis tiek reikės tinklo inžinieriams tam tikriems diegimams. Išteklių modulių paskirtis – supaprastinti didelius Jinja šablonus ir normalizuoti nestruktūrizuotas įrenginių konfigūracijas į struktūrinį JSON formatą. Naudojant išteklių modulius, esamiems tinklams bus lengviau paversti savo konfigūraciją į struktūrizuotas raktų ir verčių poras, kurios yra lengvai skaitomas tiesos šaltinis. Naudodami struktūrizuotas raktų ir verčių poras galite pereiti nuo konfigūracijų vykdymo kiekviename įrenginyje prie darbo su nepriklausomais struktūrizuotais duomenimis ir paversti tinklus infrastruktūros kaip kodo metodo priešakyje.
Kokie išteklių moduliai bus įtraukti į Ansible Engine 2.9?
Prieš išsamiai papasakodami, kas nutiks Ansible 2.9, prisiminkime, kaip paskirstėme visą darbo apimtį.
Mes nustatėme 7 kategorijas ir kiekvienai priskyrėme konkrečius tinklo išteklius:
Pastaba: pusjuodžiu šriftu pažymėti ištekliai buvo suplanuoti ir įgyvendinti Ansible 2.9.
Remiantis įmonių klientų ir bendruomenės atsiliepimais, buvo logiška pirmiausia spręsti tuos modulius, susijusius su tinklo topologijos protokolais, virtualizacija ir sąsajomis.
Šiuos išteklių modulius sukūrė „Ansible Network“ komanda ir jie atitinka „Red Hat“ palaikomas platformas:
Ansible bendruomenė sukūrė šiuos modulius:
exos_lldp_global- iš Extreme Networks.nxos_bfd_interfaces- iš Cisconxos_telemetry- iš Cisco
Kaip matote, išteklių modulių koncepcija atitinka mūsų platformą orientuotą strategiją. Tai reiškia, kad į Ansible įtraukiame reikiamas galimybes ir funkcijas, kad palaikytume standartizavimą kuriant tinklo modulius, taip pat supaprastintume vartotojų darbą Ansible vaidmenų ir žaidimų knygelių lygmenyje. Siekdama išplėsti išteklių modulių kūrimą, Ansible komanda išleido įrankį Module Builder.
Planai Ansible 2.10 ir naujesnėms versijoms
Kai bus išleista Ansible 2.9, mes dirbsime su kitu Ansible 2.10 išteklių modulių rinkiniu, kurį bus galima naudoti toliau konfigūruojant tinklo topologiją ir politiką, pvz. . Plėtros planas dar gali būti koreguojamas, todėl turinčius pastabų prašome pranešti el .
Ištekliai ir pradžia
Šaltinis: www.habr.com