Væntanleg útgáfa af Red Hat Ansible Engine 2.9 færir spennandi endurbætur, sem sumar hverjar eru ræddar í þessari grein. Eins og alltaf höfum við verið að þróa Ansible Network endurbætur opinskátt, með stuðningi samfélagsins. Vertu með okkur - kíktu á og kynna sér þróunaráætlun fyrir á wiki síðunni fyrir .
Eins og við tilkynntum nýlega, inniheldur nú Ansible Tower, Ansible Engine og allt efni frá Ansible Network. Nú á dögum eru vinsælustu netkerfin útfærð í gegnum Ansible einingar. Til dæmis:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Fyrir heildarlista yfir vettvanga sem eru að fullu studdir af Red Hat í gegnum Ansible Automation áskrift, .
Hvað höfum við lært
Undanfarin fjögur ár höfum við lært mikið um að þróa sjálfvirkni netkerfis. Við lærðum það líka sem vettvangsgripir eru notaðir í Ansible leikbókum og hlutverkum af notendum. Og hér er það sem við komumst að:
- Stofnanir eru að gera sjálfvirk tæki frá ekki bara einum heldur mörgum söluaðilum.
- Sjálfvirkni er ekki aðeins tæknilegt fyrirbæri heldur einnig menningarlegt.
- Það er erfiðara að gera sjálfvirkan netkerfi í stærðargráðu en það virðist vegna grundvallarsjónarmiða byggingarlistar sjálfvirknihönnunar.
Þegar við ræddum langtímavaxtaráætlanir okkar fyrir meira en ári síðan báðu viðskiptavinir okkar um eftirfarandi:
- Staðla þarf staðreyndasöfnun betur og samræma vinnuflæði sjálfvirkni í öllum tækjum.
- Uppfærslustillingar á tækinu þurfa einnig að vera staðlaðar og samkvæmar þannig að Ansible einingar sjái um seinni hluta lotunnar eftir að hafa safnað staðreyndum.
- Við þurfum strangar og studdar aðferðir til að umbreyta uppsetningu tækja í skipulögð gögn. Á þessum grundvelli er hægt að færa uppruna sannleikans úr nettækinu.
Umbætur á staðreyndum
Að safna staðreyndum úr nettækjum sem nota Ansible gerist oft af handahófi. Vefvettvangar hafa mismikla möguleika til að safna staðreyndum, en þeir hafa litla sem enga virkni til að flokka og staðla framsetningu gagna í lykilgildapörum. Lestu Ken Celenza um hversu erfitt og sársaukafullt það getur verið að greina og staðla staðreyndagögn.
Þú gætir hafa tekið eftir því að við erum að vinna að Ansible Network Engine hlutverkinu. Eðlilega, 24K niðurhalum síðar, hefur Network Engine hlutverkið fljótt orðið eitt vinsælasta Ansible hlutverkið í Ansible Galaxy fyrir sjálfvirkni netkerfis. Áður en við fluttum mikið af þessu inn í Ansible 2.8 til að undirbúa okkur fyrir það sem þyrfti í Ansible 2.9, var þetta Ansible hlutverk fyrsta sett af verkfærum til að hjálpa að flokka skipanir, stjórna skipunum og safna gögnum fyrir nettæki.
Ef þú veist hvernig á að nota Network Engine er þetta mjög skilvirk leið til að safna, flokka og staðla staðreyndagögn til notkunar í Ansible. Ókosturinn við þetta hlutverk er að þú þarft að búa til heilan helling af þáttum fyrir hvern vettvang og fyrir alla netvirkni. Til að skilja hversu erfitt það er að búa til, senda og viðhalda þáttum, kíktu á frá strákunum hjá Cisco.
Í hnotskurn, að fá staðreyndir úr tækjum og staðla þær í lykilgilda pör er nauðsynlegt fyrir sjálfvirkni í stærðargráðu, en að ná þessu er erfitt þegar þú ert með marga söluaðila og netkerfi.
Hver net staðreyndareining í Ansible 2.9 getur nú greint stillingar nettækis og skilað skipulögðum gögnum - án viðbótarsöfnum, Ansible hlutverkum eða sérsniðnum þáttum.
Frá Ansible 2.9, í hvert sinn sem uppfærð neteining er gefin út, er staðreyndareiningin endurbætt til að veita gögn um þennan hluta stillingarinnar. Það er að segja að þróun staðreynda og eininga á sér nú stað á sama hraða og þær munu alltaf hafa sameiginlega gagnauppbyggingu.
Stillingar auðlinda á nettæki er hægt að sækja og breyta í skipulögð gögn á tvo vegu. Á báða vegu geturðu safnað og umbreytt tilteknum lista yfir auðlindir með því að nota nýtt leitarorð gather_network_resources. Aðfangaheitin passa við einingaheitin, sem er mjög þægilegt.
Þegar þú safnar staðreyndum:
Að nota leitarorð gather_facts þú getur sótt núverandi uppsetningu tækisins í upphafi leikbókarinnar og síðan notað hana í gegnum alla leikbókina. Tilgreindu einstök tilföng sem á að sækja úr tækinu.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueÞú gætir hafa tekið eftir einhverju nýju í þessum dæmum, nefnilega - gather_facts: true er nú fáanlegt fyrir innbyggða staðreyndasöfnun fyrir nettæki.
Notkun netstaðreyndaeiningarinnar beint:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesLeikbókin skilar eftirfarandi staðreyndum um viðmótið:
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: Ethernet1Taktu eftir því hvernig Ansible sækir innbyggðu uppsetninguna úr Arista tækinu og umbreytir þeim í skipulögð gögn til að nota sem staðlað lykilgildapör fyrir verkefni og aðgerðir eftir strauminn.
Viðmótsstaðreyndir er hægt að bæta við Ansible vistaðar breytur og nota strax eða síðar sem inntak í auðlindareiningu eos_interfaces án viðbótarvinnslu eða umbreytingar.
Auðlindaeiningar
Þannig að við tókum út staðreyndirnar, staðluðum gögnin, pössuðum þau inn í staðlaða innri gagnaskipulagsmynd og fengum tilbúna uppsprettu sannleikans. Húrra! Þetta er auðvitað frábært, en við þurfum samt einhvern veginn að breyta lykilgildapörunum aftur í þá tilteknu uppsetningu sem tiltekinn tækisvettvangur býst við. Við þurfum nú vettvangssértækar einingar til að uppfylla þessar nýju staðreyndaöflun og eðlilegar kröfur.
Hvað er auðlindareining? Þú getur hugsað um stillingarhluta tækis sem auðlindir frá því tæki. Netauðlindaeiningar eru viljandi takmarkaðar við eina auðlind og hægt er að stafla þeim eins og byggingareiningar til að stilla flókna netþjónustu. Þar af leiðandi eru kröfur og forskriftir fyrir auðlindareiningu eðlilega einfaldaðar, þar sem auðlindareiningin getur lesið и stilla tiltekna sérþjónustu á nettæki.
Til að útskýra hvað auðlindareining gerir, skulum við skoða dæmi leikbók sem sýnir óábyrga aðgerð með því að nota nýjar upplýsingar um netauðlindir og einingu 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.changedEins og þú sérð eru gögnin sem safnað er úr tækinu flutt beint í samsvarandi auðlindareiningu án umbreytingar. Þegar leikbókin er hleypt af stokkunum sækir hún gildi úr tækinu og ber þau saman við væntanleg gildi. Í þessu dæmi eru gildin sem skilað er eins og búist var við (þ.e. það athugar fyrir frávik í stillingum) og tilkynnir hvort stillingin hafi breyst.
Ákjósanlegasta leiðin til að greina stillingarskref er að geyma staðreyndir í Ansible vistuðum breytum og nota þær reglulega með auðlindareiningunni í skoðunarham. Þetta er einföld aðferð til að sjá hvort einhver hafi breytt gildunum handvirkt. Í flestum tilfellum leyfa stofnanir breytingar og stillingar handvirkt, þó að margar aðgerðir séu gerðar í gegnum Ansible Automation.
Hvernig eru nýju tilfangaeiningarnar frábrugðnar þeim fyrri?
Fyrir net sjálfvirkni verkfræðing, það er 3 meginmunur á milli auðlindareininga í Ansible 2.9 og fyrri útgáfum.
1) Fyrir tiltekið netkerfi (sem einnig má líta á sem stillingarhluta), munu einingar og staðreyndir þróast yfir öll studd netstýrikerfi samtímis. Við teljum að ef Ansible styður auðlindastillingu á einum netvettvangi ættum við að styðja það alls staðar. Þetta einfaldar notkun auðlindareininga vegna þess að netsjálfvirkniverkfræðingur getur nú stillt auðlind (eins og LLDP) á öllum netstýrikerfum með innfæddum og studdum einingum.
2) Tilfangaeiningar innihalda nú ástandsgildi.
merged: uppsetningin er sameinuð uppsetningunni sem fylgir (sjálfgefin);replaced: Tilfangastillingunni verður skipt út fyrir uppsetninguna sem fylgir;overridden: Tilfangastillingunni verður skipt út fyrir uppsetninguna sem fylgir; óþarfa auðlindatilvikum verður eytt;deleted: Auðlindastillingunni verður eytt/endurheimt í sjálfgefið.
3) Auðlindaeiningar innihalda nú stöðug skilagildi. Þegar netauðlindareiningin hefur gert (eða lagt til) nauðsynlegar breytingar á nettækinu skilar hún sömu lykilgildapörunum í leikbókina.
before: stillingar á tækinu í formi skipulögðra gagna fyrir verkefnið;after: ef tækið hefur breyst (eða gæti breyst ef prófunarhamur er notaður), verður stillingunni sem myndast skilað sem skipulögð gögn;commands: Allar stillingarskipanir keyra á tækinu til að koma því í æskilegt ástand.
Hvað þýðir allt þetta? Hvers vegna er það mikilvægt?
Þessi færsla fjallar um mörg flókin hugtök, en við vonum að á endanum hafirðu betri skilning á því hvað fyrirtækisviðskiptavinir biðja um í rauninni söfnun, gagnastillingu og lykkjustillingu fyrir sjálfvirknivettvang. En hvers vegna þurfa þeir þessar endurbætur? Margar stofnanir stunda nú stafræna umbreytingu til að gera upplýsingatækniumhverfi sitt lipra og samkeppnishæfara. Með góðu eða verri verða margir netverkfræðingar netframleiðendur annaðhvort vegna eigin hagsmuna eða í boði stjórnenda.
Samtök eru að átta sig á því að sjálfvirkni einstakra netsniðmáta leysir ekki vandamál sílóanna og eykur aðeins skilvirkni að vissu marki. Red Hat Ansible Automation Platform býður upp á strangar og staðlaðar auðlindagagnalíkön til að stjórna undirliggjandi gögnum á netbúnaði með forritunaraðferðum. Það er að segja, notendur eru smám saman að yfirgefa einstakar uppsetningaraðferðir í þágu nútímalegri aðferða með áherslu á tækni (til dæmis IP tölur, VLAN, LLDP, osfrv.), frekar en á tiltekna útfærslu söluaðila.
Þýðir þetta að dagar áreiðanlegra og sannaðra stjórnaeininga og uppsetningar séu taldir? Í engu tilviki. Væntanlegar netauðlindaeiningar munu ekki eiga við í öllum tilfellum eða fyrir hvern söluaðila, þannig að stjórnunar- og stillingareiningarnar verða áfram nauðsynlegar af netverkfræðingum fyrir ákveðnar útfærslur. Tilgangur auðlindareininga er að einfalda stór Jinja sniðmát og staðla óskipulagðar tækjastillingar í skipulögð JSON snið. Með auðlindareiningum verður auðveldara fyrir núverandi net að umbreyta stillingum sínum í skipulögð lykilgildapör sem tákna auðlesna uppsprettu sannleikans. Með því að nota skipulögð lykilgildapör geturðu farið frá því að keyra stillingar á hverju tæki yfir í að vinna með óháð skipulögð gögn og koma netkerfum í fremstu röð í innviðum-eins og kóða nálgun.
Hvaða auðlindaeiningar munu koma í Ansible Engine 2.9?
Áður en við segjum þér í smáatriðum hvað mun gerast í Ansible 2.9, skulum við muna hvernig við skiptum öllu umfangi vinnunnar.
Við auðkenndum 7 flokka og úthlutuðum sérstökum nettilföngum til hvers:
Athugið: Feitletruð tilföng voru skipulögð og útfærð í Ansible 2.9.
Byggt á endurgjöf frá viðskiptavinum fyrirtækja og samfélaginu var rökrétt að takast fyrst á við þessar einingar sem tengjast netkerfisfræðisamskiptareglum, sýndarvæðingu og viðmótum.
Eftirfarandi auðlindaeiningar voru þróaðar af Ansible Network teyminu og samsvara þeim kerfum sem Red Hat styður:
Eftirfarandi einingar eru þróaðar af Ansible samfélaginu:
exos_lldp_global- frá Extreme Networks.nxos_bfd_interfaces- frá Cisconxos_telemetry- frá Cisco
Eins og þú sérð passar hugmyndin um auðlindareining inn í vettvangsmiðaða stefnu okkar. Það er að segja, við tökum nauðsynlega getu og aðgerðir inn í Ansible sjálft til að styðja við stöðlun í þróun neteininga og einnig til að einfalda vinnu notenda á stigi Ansible hlutverka og leikbóka. Til að auka þróun auðlindareininga gaf Ansible teymið út Module Builder tólið.
Áætlanir fyrir Ansible 2.10 og lengra
Þegar Ansible 2.9 hefur verið gefin út, munum við vinna að næsta setti af auðlindareiningum fyrir Ansible 2.10, sem hægt er að nota til að stilla frekar svæðisfræði og stefnu netkerfisins, t.d. . Enn er hægt að laga þróunaráætlunina, svo ef þú hefur athugasemdir, vinsamlegast tilkynntu það til .
Úrræði og að byrja
Heimild: www.habr.com