De kommende release fan Red Hat Ansible Engine 2.9 bringt spannende ferbetterings, wêrfan guon wurde besprutsen yn dit artikel. Lykas altyd hawwe wy Ansible Network ferbetterings iepenlik ûntwikkele, mei stipe fan 'e mienskip. Doch mei ús - sjoch ris op en bestudearje it ûntwikkelingsplan foar op de wiki side foar .
As wy koartlyn oankundige, omfettet no Ansible Tower, Ansible Engine en alle Ansible Network-ynhâld. Tsjintwurdich wurde de meast populêre netwurkplatfoarms ymplementearre fia Ansible-modules. Bygelyks:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Foar in folsleine list mei platfoarms dy't folslein wurde stipe troch Red Hat fia Ansible Automation-abonnemint, .
Wat hawwe wy leard
Yn 'e ôfrûne fjouwer jier hawwe wy in protte leard oer it ûntwikkeljen fan in platfoarm foar netwurkautomatisaasje. Dat ha wy ek leard hoe platfoarm artefakten wurde brûkt yn Ansible playbooks en rollen troch ein brûkers. En hjir is wat wy fûnen:
- Organisaasjes automatisearje apparaten fan net allinich ien, mar in protte leveransiers.
- Automatisearring is net allinnich in technysk ferskynsel, mar ek in kultureel.
- It automatisearjen fan netwurken op skaal is dreger dan it liket troch de fûnemintele arsjitektoanyske prinsipes fan automatisearringsûntwerp.
Doe't wy mear as in jier lyn ús plannen foar groei op lange termyn besprutsen, fregen ús bedriuwskliïnten om it folgjende:
- Feitensammeling moat better standerdisearre wurde en ôfstimd mei automatisearringswurkflows oer alle apparaten.
- It bywurkjen fan konfiguraasjes op it apparaat moat ek standerdisearre en konsekwint wêze, sadat Ansible-modules de twadde helte fan 'e syklus behannelje nei it sammeljen fan feiten.
- Wy hawwe strange en stipe metoaden nedich foar it konvertearjen fan apparaatkonfiguraasje yn strukturearre gegevens. Op dizze basis kin de boarne fan wierheid wurde ferpleatst fan it netwurkapparaat.
Feit ferbetterings
It sammeljen fan feiten fan netwurkapparaten mei Ansible bart faak willekeurich. Web-basearre platfoarms hawwe ferskate mjitten fan feiten sammelje mooglikheden, mar se hawwe in bytsje of gjin funksjonaliteit foar parsing en standerdisearring fan de fertsjintwurdiging fan gegevens yn kaai-wearde pearen. Lêze Ken Celenza oer hoe lestich en pynlik it kin wêze om feitlike gegevens te analysearjen en te standardisearjen.
Jo hawwe miskien opfallen dat wy wurkje oan 'e rol fan Ansible Network Engine. Natuerlik, 24K downloads letter, is de Network Engine-rol gau ien fan 'e populêrste Ansible-rollen wurden yn Ansible Galaxy foar senario's foar netwurkautomatisearring. Foardat wy in protte fan dit ferpleatsen nei Ansible 2.8 om ta te rieden op wat nedich wêze soe yn Ansible 2.9, levere dizze Ansible-rol de earste set ark om kommando's te parsearjen, kommando's te behearjen en gegevens te sammeljen foar netwurkapparaten.
As jo witte hoe't jo Network Engine kinne brûke, is dit in heul effisjinte manier om feitgegevens te sammeljen, te parsearjen en te standerdisearjen foar gebrûk yn Ansible. It neidiel fan dizze rol is dat jo in hiele bosk parsers meitsje moatte foar elk platfoarm en foar alle netwurkaktiviteit. Om te begripen hoe lestich it is om parsers te meitsjen, te ferstjoeren en te ûnderhâlden, sjoch ris nei fan de jonges by Cisco.
Yn in notedop, it krijen fan feiten fan apparaten en it normalisearjen fan se yn kaai-wearde-pearen is essensjeel foar automatisearring op skaal, mar it berikken fan dit is lestich as jo in protte leveransiers en netwurkplatfoarms hawwe.
Elke netwurkfeitmodule yn Ansible 2.9 kin no de konfiguraasje fan in netwurkapparaat analysearje en struktureare gegevens weromjaan - sûnder ekstra biblioteken, Ansible-rollen of oanpaste parsers.
Sûnt Ansible 2.9, elke kear as in bywurke netwurkmodule wurdt frijlitten, wurdt de feitmodule ferbettere om gegevens oer dizze seksje fan 'e konfiguraasje te leverjen. Dat is, de ûntwikkeling fan feiten en modules komt no yn itselde tempo, en se sille altyd in mienskiplike gegevensstruktuer hawwe.
De konfiguraasje fan boarnen op in netwurkapparaat kin op twa manieren ophelle en omboud wurde yn strukturearre gegevens. Op beide manieren kinne jo in spesifike list mei boarnen sammelje en transformearje mei in nij kaaiwurd gather_network_resources. De boarnenammen komme oerien mei de modulenammen, wat heul handich is.
By it sammeljen fan feiten:
Mei help fan in kaaiwurd gather_facts jo kinne ophelje de hjoeddeiske apparaat konfiguraasje oan it begjin fan it toanielstik, en dan brûk it troch de hiele playbook. Spesifisearje de yndividuele boarnen dy't moatte wurde ophelle fan it apparaat.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueJo hawwe miskien wat nijs yn dizze foarbylden opmurken, nammentlik - gather_facts: true is no beskikber foar native feitensamling foar netwurkapparaten.
Mei de netwurkfeiten module direkt:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesIt playbook jout de folgjende feiten oer de ynterface werom:
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: Ethernet1Merk op hoe't Ansible de native konfiguraasje ophellet fan it Arista-apparaat en it transformeart yn strukturearre gegevens om te brûken as standert kaai-wearde-pearen foar downstream-taken en operaasjes.
Interface feiten kinne wurde tafoege oan Ansible opslein fariabelen en brûkt fuortendaliks of letter as ynfier nei in boarne module eos_interfaces sûnder ekstra ferwurking of konverzje.
Resource Modules
Dat, wy helle de feiten út, normalisearre de gegevens, passe se yn in standertisearre ynterne gegevensstruktuerdiagram en krigen in klearmakke boarne fan wierheid. Hoera! Dit is fansels geweldich, mar wy moatte de kaai-wearde-pearen noch op ien of oare manier konvertearje nei de spesifike konfiguraasje dy't it spesifike apparaatplatfoarm ferwachtet. Wy hawwe no platfoarm-spesifike modules nedich om te foldwaan oan dizze nije easken foar it sammeljen fan feiten en normalisaasje.
Wat is in boarne module? Jo kinne tinke oan de konfiguraasje-seksjes fan in apparaat as boarnen levere troch dat apparaat. Netwurkboarnemodules binne mei opsetsin beheind ta ien inkelde boarne en kinne wurde steapele as boublokken om komplekse netwurktsjinsten te konfigurearjen. As gefolch binne de easken en spesifikaasjes foar in boarnemodule natuerlik ferienfâldige, om't de boarnemodule lêze kin и konfigurearje in spesifike netwurktsjinst op in netwurkapparaat.
Om út te lizzen wat in boarne-module docht, litte wy nei in foarbyldspielboek sjen dat in ûnbidige operaasje toant mei nije netwurkboarnefeiten en 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.changedSa't jo sjen kinne, de gegevens sammele út it apparaat wurdt oerdroegen direkt nei de byhearrende boarne module sûnder konverzje. As it wurdt lansearre, hellet it playbook wearden op fan it apparaat en fergeliket se mei ferwachte. Yn dit foarbyld binne de weromjûne wearden lykas ferwachte (dat is, it kontrolearret op konfiguraasjeôfwikingen) en rapportearret oft de konfiguraasje is feroare.
De ideale manier om konfiguraasjedrift te detektearjen is om feiten te bewarjen yn Ansible opsleine fariabelen en periodyk te brûken mei de boarnemodule yn ynspeksjemodus. Dit is in ienfâldige metoade om te sjen oft immen de wearden mei de hân hat feroare. Yn 'e measte gefallen tastean organisaasjes wizigingen en konfiguraasje manuell ta, hoewol in protte operaasjes wurde útfierd fia Ansible Automation.
Hoe ferskille de nije boarnemodules fan 'e foarige?
Foar in yngenieur foar netwurkautomatisearring binne d'r 3 wichtichste ferskillen tusken boarnemodules yn Ansible 2.9 en eardere ferzjes.
1) Foar in opjûne netwurk boarne (dat kin ek wurde tocht as in konfiguraasje seksje), modules en feiten sille evolve oer alle stipe netwurk bestjoeringssystemen tagelyk. Wy tinke dat as Ansible boarnekonfiguraasje op ien netwurkplatfoarm stipet, wy it oeral moatte stypje. Dit simplifies it brûken fan boarne modules omdat in netwurk automatisearring yngenieur kin no konfigurearje in boarne (lykas LLDP) op alle netwurk bestjoeringssystemen mei native en stipe modules.
2) Boarnemodules omfetsje no in steatwearde.
merged: de konfiguraasje wurdt gearfoege mei de levere konfiguraasje (standert);replaced: De boarne konfiguraasje wurdt ferfongen troch de levere konfiguraasje;overridden: De boarne konfiguraasje wurdt ferfongen troch de levere konfiguraasje; ûnnedige boarne-ynstânsjes sille wiske wurde;deleted: De boarne konfiguraasje wurdt wiske/wersteld nei standert.
3) Boarnemodules omfetsje no stabile weromwearden. Wannear't de netwurk boarne module hat makke (of foarsteld) de nedige feroarings oan it netwurk apparaat, it jout deselde kaai-wearde pearen nei it toanielstik.
before: konfiguraasje op it apparaat yn 'e foarm fan strukturearre gegevens foar de taak;after: as it apparaat is feroare (of kin feroarje as testmodus wurdt brûkt), sil de resultearjende konfiguraasje weromjûn wurde as strukturearre gegevens;commands: Alle konfiguraasjekommando's rinne op it apparaat om it yn 'e winske steat te bringen.
Wat betsjut dit alles? Wêrom is it wichtich?
Dizze post beslacht in protte komplekse begripen, mar wy hoopje dat jo op it lêst in better begryp sille hawwe fan wat ûndernimmingskliïnten freegje om feitlik sammeling, gegevensnormalisaasje en loopkonfiguraasje foar in automatisearringsplatfoarm. Mar wêrom hawwe se dizze ferbetterings nedich? In protte organisaasjes folgje no digitale transformaasje om har IT-omjouwings agile en konkurrearjender te meitsjen. Foar better of slimmer wurde in protte netwurkyngenieurs netwurkûntwikkelders itsij út eigenbelang of op opdracht fan behear.
Organisaasjes realisearje dat it automatisearjen fan yndividuele netwurksjabloanen it probleem fan silo's net oplost en allinich effisjinsje ta in beskate mjitte fergruttet. It Red Hat Ansible Automation Platform biedt rigoureuze en normative boarnegegevensmodellen om programmatysk de ûnderlizzende gegevens op in netwurkapparaat te behearjen. Dat is, brûkers ferlitte stadichoan yndividuele konfiguraasjemetoaden yn it foardiel fan modernere metoaden mei de klam op technologyen (bygelyks IP-adressen, VLAN's, LLDP, ensfh.), Yn stee fan in spesifike ferkeaper ymplemintaasje.
Betsjut dit dat de dagen fan betroubere en bewiisde kommando-modules en konfiguraasje binne nûmere? Yn gjin gefal. De ferwachte netwurkboarnemodules sille net yn alle gefallen of foar elke ferkeaper fan tapassing wêze, sadat de kommando- en konfiguraasjemodules noch altyd nedich binne troch netwurkingenieurs foar bepaalde ymplemintaasjes. It doel fan boarnemodules is om grutte Jinja-sjabloanen te ferienfâldigjen en ûnstrukturearre apparaatkonfiguraasjes te normalisearjen yn in strukturearre JSON-formaat. Mei boarnemodules sil it makliker wêze foar besteande netwurken om har konfiguraasje te transformearjen yn strukturearre kaai-wearde-pearen dy't in maklik te lêzen boarne fan wierheid fertsjintwurdigje. Troch gebrûk te meitsjen fan strukturearre kaai-wearde-pearen, kinne jo ferhúzje fan rinnende konfiguraasjes op elk apparaat nei wurkjen mei ûnôfhinklike strukturearre gegevens en bringe netwurken oan 'e foargrûn fan in ynfrastruktuer-as-koade oanpak.
Hokker boarnemodules sille komme yn Ansible Engine 2.9?
Foardat wy jo yn detail fertelle wat der sil barre yn Ansible 2.9, lit ús ûnthâlde hoe't wy it hiele wurkgebiet ferdield hawwe.
Wy identifisearre 7 kategoryen en tawiisd spesifike netwurk boarnen oan elk:
Opmerking: boarnen yn fet waarden pland en ymplementearre yn Ansible 2.9.
Op grûn fan feedback fan ûndernimmingsklanten en de mienskip wie it logysk om earst dy modules oan te pakken oangeande netwurktopologyprotokollen, virtualisaasje en ynterfaces.
De folgjende boarnemodules binne ûntwikkele troch it Ansible Network-team en oerienkomme mei de platfoarms dy't troch Red Hat wurde stipe:
De folgjende modules wurde ûntwikkele troch de Ansible-mienskip:
exos_lldp_global- fan Extreme Networks.nxos_bfd_interfaces- fan Cisconxos_telemetry- fan Cisco
Sa't jo sjen kinne, past it konsept fan boarnemodules yn ús platfoarm-sintraal strategy. Dat is, wy befetsje de nedige mooglikheden en funksjes yn Ansible sels om standerdisearring te stypjen yn 'e ûntwikkeling fan netwurkmodules, en ek om it wurk fan brûkers te ferienfâldigjen op it nivo fan Ansible-rollen en playbooks. Om de ûntwikkeling fan boarnemodules út te wreidzjen, hat it Ansible-team it Module Builder-ark frijlitten.
Plannen foar Ansible 2.10 en fierder
Sadree't Ansible 2.9 is frijlitten, sille wy wurkje oan 'e folgjende set fan boarnemodules foar Ansible 2.10, dy't kinne wurde brûkt om netwurktopology en belied fierder te konfigurearjen, bgl. . It ûntjouwingsplan kin noch oanpast wurde, dus as jo opmerkings hawwe, meld it dan graach oan .
Boarnen en te begjinnen
Boarne: www.habr.com