Die komende vrystelling van Red Hat Ansible Engine 2.9 bring opwindende verbeterings, waarvan sommige in hierdie artikel bespreek word. Soos altyd het ons Ansible Network-verbeterings openlik ontwikkel, met gemeenskapsondersteuning. Sluit by ons aan - kyk na en bestudeer die ontwikkelingsplan vir op die wiki-bladsy vir .
Soos ons onlangs aangekondig het, sluit nou Ansible Tower, Ansible Engine en alle Ansible Network-inhoud in. Deesdae word die gewildste netwerkplatforms deur Ansible-modules geïmplementeer. Byvoorbeeld:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Vir 'n volledige lys platforms wat ten volle deur Red Hat ondersteun word deur Ansible Automation-intekening, .
Wat het ons geleer
Oor die afgelope vier jaar het ons baie geleer oor die ontwikkeling van 'n netwerkoutomatiseringsplatform. Ons het dit ook geleer hoe platform-artefakte word in Ansible-speelboeke en rolle deur eindgebruikers gebruik. En hier is wat ons uitgevind het:
- Organisasies outomatiseer toestelle van nie net een nie, maar baie verskaffers.
- Outomatisering is nie net 'n tegniese verskynsel nie, maar ook 'n kulturele een.
- Outomatisering van netwerke op skaal is moeiliker as wat dit lyk as gevolg van die fundamentele argitektoniese beginsels van outomatiseringsontwerp.
Toe ons ons langtermyn-groeiplanne meer as 'n jaar gelede bespreek het, het ons korporatiewe kliënte die volgende gevra:
- Feite-insameling moet beter gestandaardiseer en in lyn gebring word met outomatiseringswerkvloeie oor alle toestelle.
- Opdatering van konfigurasies op die toestel moet ook gestandaardiseer en konsekwent wees sodat Ansible-modules die tweede helfte van die siklus hanteer nadat feite ingesamel is.
- Ons benodig streng en ondersteunde metodes om toestelkonfigurasie in gestruktureerde data om te skakel. Op hierdie basis kan die bron van waarheid van die netwerktoestel geskuif word.
Feitverbeterings
Die insameling van feite vanaf netwerktoestelle met Ansible gebeur dikwels lukraak. Web-gebaseerde platforms het verskillende grade van feite-insamelingsvermoëns, maar hulle het min of geen funksionaliteit vir die ontleding en standaardisering van die voorstelling van data in sleutel-waarde-pare. Lees Ken Celenza oor hoe moeilik en pynlik dit kan wees om feitelike data te ontleed en te standaardiseer.
Jy het dalk opgemerk dat ons aan die Ansible Network Engine-rol werk. Natuurlik, 24K later afgelaai, het die Network Engine-rol vinnig een van die gewildste Ansible-rolle in Ansible Galaxy geword vir netwerkoutomatiseringscenario's. Voordat ons baie hiervan na Ansible 2.8 verskuif het om voor te berei vir wat in Ansible 2.9 nodig sou wees, het hierdie Ansible-rol die eerste stel gereedskap verskaf om opdragte te help ontleed, opdragte te bestuur en data vir netwerktoestelle in te samel.
As jy weet hoe om Network Engine te gebruik, is dit 'n baie doeltreffende manier om feitedata in te samel, te ontleed en te standaardiseer vir gebruik in Ansible. Die nadeel van hierdie rol is dat jy 'n hele klomp ontleders vir elke platform en vir alle netwerkaktiwiteit moet skep. Om te verstaan hoe moeilik dit is om ontleders te skep, te stuur en in stand te hou, kyk na van die ouens by Cisco.
In 'n neutedop, om feite van toestelle af te kry en dit in sleutel-waarde-pare te normaliseer, is noodsaaklik vir outomatisering op skaal, maar dit is moeilik om dit te bereik as jy baie verskaffers en netwerkplatforms het.
Elke netwerkfeitemodule in Ansible 2.9 kan nou die konfigurasie van 'n netwerktoestel ontleed en gestruktureerde data terugstuur - sonder bykomende biblioteke, Ansible-rolle of pasgemaakte ontleders.
Sedert Ansible 2.9, elke keer as 'n opgedateerde netwerkmodule vrygestel word, word die feitemodule verbeter om data oor hierdie afdeling van die opstelling te verskaf. Dit wil sê, die ontwikkeling van feite en modules vind nou in dieselfde tempo plaas, en hulle sal altyd 'n gemeenskaplike datastruktuur hê.
Die konfigurasie van hulpbronne op 'n netwerktoestel kan op twee maniere opgespoor en in gestruktureerde data omgeskakel word. Op beide maniere kan jy 'n spesifieke lys hulpbronne versamel en transformeer deur 'n nuwe sleutelwoord te gebruik gather_network_resources. Die hulpbronname pas by die modulename, wat baie gerieflik is.
Terwyl jy feite versamel:
Die gebruik van 'n sleutelwoord gather_facts jy kan die huidige toestelkonfigurasie aan die begin van die speelboek ophaal en dit dan deur die hele speelboek gebruik. Spesifiseer die individuele hulpbronne wat van die toestel af gehaal moet word.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueJy het dalk iets nuuts in hierdie voorbeelde opgemerk, naamlik - gather_facts: true is nou beskikbaar vir inheemse feiteversameling vir netwerktoestelle.
Deur die netwerkfeitmodule direk te gebruik:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesDie speelboek gee die volgende feite oor die koppelvlak terug:
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: Ethernet1Let op hoe Ansible die oorspronklike konfigurasie van die Arista-toestel af haal en dit in gestruktureerde data omskep om as standaard sleutel-waarde-pare vir stroomaf take en bedrywighede te gebruik.
Koppelvlakfeite kan by Ansible-gestoorde veranderlikes gevoeg word en onmiddellik of later gebruik word as insette na 'n hulpbronmodule eos_interfaces sonder bykomende verwerking of omskakeling.
Hulpbronmodules
So, ons het die feite onttrek, die data genormaliseer, dit in 'n gestandaardiseerde interne datastruktuurdiagram inpas en 'n klaargemaakte bron van waarheid ontvang. Hoera! Dit is natuurlik wonderlik, maar ons moet steeds die sleutel-waarde-pare op een of ander manier terugskakel na die spesifieke konfigurasie wat die spesifieke toestelplatform verwag. Ons benodig nou platformspesifieke modules om aan hierdie nuwe feite-insamelings- en normaliseringsvereistes te voldoen.
Wat is 'n hulpbronmodule? Jy kan aan 'n toestel se konfigurasieafdelings dink as hulpbronne wat deur daardie toestel verskaf word. Netwerkhulpbronmodules word doelbewus tot 'n enkele hulpbron beperk en kan soos boustene gestapel word om komplekse netwerkdienste op te stel. Gevolglik word die vereistes en spesifikasie vir 'n hulpbronmodule natuurlik vereenvoudig, aangesien die hulpbronmodule kan lees и stel 'n spesifieke netwerkdiens op 'n netwerktoestel in.
Om te verduidelik wat 'n hulpbronmodule doen, kom ons kyk na 'n voorbeeld-speelboek wat 'n onbehoorlike bewerking toon deur nuwe netwerkhulpbron- en modulefeite te gebruik 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.changedSoos u kan sien, word die data wat vanaf die toestel ingesamel word, direk na die ooreenstemmende hulpbronmodule oorgedra sonder omskakeling. Wanneer dit bekendgestel word, haal die speelboek waardes van die toestel af en vergelyk dit met verwagte waardes. In hierdie voorbeeld is die waardes wat teruggestuur word soos verwag (dit wil sê, dit kyk vir konfigurasieafwykings) en rapporteer of die konfigurasie verander het.
Die ideale manier om konfigurasieverskuiwing op te spoor, is om feite in Ansible-gestoorde veranderlikes te stoor en dit periodiek met die hulpbronmodule in inspeksiemodus te gebruik. Dit is 'n eenvoudige metode om te sien of iemand die waardes met die hand verander het. In die meeste gevalle laat organisasies veranderinge en konfigurasie met die hand toe, hoewel baie bewerkings deur Ansible Automation uitgevoer word.
Hoe verskil die nuwe hulpbronmodules van die voriges?
Vir 'n netwerkoutomatiseringsingenieur is daar 3 hoofverskille tussen hulpbronmodules in Ansible 2.9 en vorige weergawes.
1) Vir 'n gegewe netwerkhulpbron (wat ook as 'n konfigurasieafdeling beskou kan word), sal modules en feite gelyktydig oor alle ondersteunde netwerkbedryfstelsels ontwikkel. Ons dink dat as Ansible hulpbronkonfigurasie op een netwerkplatform ondersteun, ons dit oral moet ondersteun. Dit vergemaklik die gebruik van hulpbronmodules omdat 'n netwerkoutomatiseringsingenieur nou 'n hulpbron (soos LLDP) op alle netwerkbedryfstelsels met inheemse en ondersteunde modules kan opstel.
2) Hulpbronmodules sluit nou 'n staatwaarde in.
merged: die konfigurasie word saamgevoeg met die verskafde konfigurasie (verstek);replaced: Die hulpbronkonfigurasie sal vervang word met die verskafde konfigurasie;overridden: Die hulpbronkonfigurasie sal vervang word met die verskafde konfigurasie; onnodige hulpbrongevalle sal uitgevee word;deleted: Die hulpbronkonfigurasie sal uitgevee/herstel word na verstek.
3) Hulpbronmodules sluit nou stabiele opbrengswaardes in. Wanneer die netwerkhulpbronmodule die nodige veranderinge aan die netwerktoestel aangebring (of voorgestel het), stuur dit dieselfde sleutel-waarde-pare terug na die speelboek.
before: konfigurasie op die toestel in die vorm van gestruktureerde data voor die taak;after: as die toestel verander het (of kan verander as toetsmodus gebruik word), sal die gevolglike konfigurasie as gestruktureerde data teruggestuur word;commands: Enige konfigurasie-opdragte loop op die toestel om dit in die verlangde toestand te bring.
Wat beteken dit alles? Hoekom is dit belangrik?
Hierdie pos dek baie komplekse konsepte, maar ons hoop dat u uiteindelik 'n beter begrip sal hê van waarvoor ondernemingskliënte in werklikheid insameling, datanormalisering en luskonfigurasie vir 'n outomatiseringsplatform vra. Maar hoekom het hulle hierdie verbeterings nodig? Baie organisasies streef nou na digitale transformasie om hul IT-omgewings meer rats en mededingend te maak. Vir beter of slegter word baie netwerkingenieurs netwerkontwikkelaars óf uit eiebelang óf in opdrag van bestuur.
Organisasies besef dat die outomatisering van individuele netwerksjablone nie die probleem van silo's oplos nie en net doeltreffendheid tot 'n sekere mate verhoog. Die Red Hat Ansible Automation Platform bied streng en normatiewe hulpbrondatamodelle om die onderliggende data op 'n netwerktoestel programmaties te bestuur. Dit wil sê, gebruikers verlaat geleidelik individuele konfigurasiemetodes ten gunste van meer moderne metodes met die klem op tegnologieë (byvoorbeeld IP-adresse, VLAN's, LLDP, ens.), eerder as op 'n spesifieke verskaffer-implementering.
Beteken dit dat die dae van betroubare en bewese opdragmodules en konfigurasie getel is? In geen geval nie. Die verwagte netwerkhulpbronmodules sal nie in alle gevalle of vir elke verskaffer van toepassing wees nie, so die opdrag- en konfigurasiemodules sal steeds deur netwerkingenieurs benodig word vir sekere implementerings. Die doel van hulpbronmodules is om groot Jinja-sjablone te vereenvoudig en ongestruktureerde toestelkonfigurasies in 'n gestruktureerde JSON-formaat te normaliseer. Met hulpbronmodules sal dit makliker wees vir bestaande netwerke om hul konfigurasie te omskep in gestruktureerde sleutel-waarde-pare wat 'n maklik-leesbare bron van waarheid verteenwoordig. Deur gestruktureerde sleutel-waarde-pare te gebruik, kan jy beweeg van hardloopkonfigurasies op elke toestel na werk met onafhanklike gestruktureerde data en netwerke na die voorpunt van 'n infrastruktuur-as-kode-benadering bring.
Watter hulpbronmodules sal in Ansible Engine 2.9 kom?
Voordat ons jou in detail vertel wat in Ansible 2.9 gaan gebeur, laat ons onthou hoe ons die hele omvang van werk verdeel het.
Ons het 7 kategorieë geïdentifiseer en spesifieke netwerkhulpbronne aan elkeen toegeken:
Let wel: Hulpbronne in vetdruk is beplan en geïmplementeer in Ansible 2.9.
Gebaseer op terugvoer van ondernemingskliënte en die gemeenskap, was dit logies om eers daardie modules aan te pak wat verband hou met netwerktopologieprotokolle, virtualisering en koppelvlakke.
Die volgende hulpbronmodules is ontwikkel deur die Ansible Network-span en stem ooreen met die platforms wat deur Red Hat ondersteun word:
Die volgende modules word deur die Ansible-gemeenskap ontwikkel:
exos_lldp_global- van Extreme Networks.nxos_bfd_interfaces- van Cisconxos_telemetry- van Cisco
Soos u kan sien, pas die konsep van hulpbronmodules by ons platformgesentreerde strategie. Dit wil sê, ons sluit die nodige vermoëns en funksies in Ansible self in om standaardisering in die ontwikkeling van netwerkmodules te ondersteun, en ook om die werk van gebruikers op die vlak van Ansible-rolle en speelboeke te vereenvoudig. Om die ontwikkeling van hulpbronmodules uit te brei, het die Ansible-span die Module Builder-nutsding vrygestel.
Planne vir Ansible 2.10 en verder
Sodra Ansible 2.9 vrygestel is, sal ons werk aan die volgende stel hulpbronmodules vir Ansible 2.10, wat gebruik kan word om netwerktopologie en -beleid verder op te stel, bv. . Die ontwikkelingsplan kan steeds aangepas word, so as jy kommentaar het, meld dit asseblief by .
Hulpbronne en begin
Bron: will.com