Tuleva Red Hat Ansible Engine 2.9 -versio tuo jännittäviä parannuksia, joista joitain käsitellään tässä artikkelissa. Kuten aina, olemme kehittäneet Ansible Networkin parannuksia avoimesti yhteisön tuella. Liity meihin - katso ja tutustu kehityssuunnitelmaan wiki-sivulla .
Kuten äskettäin ilmoitimme, sisältää nyt Ansible Towerin, Ansible Enginen ja kaiken Ansible Network -sisällön. Nykyään suosituimmat verkkoympäristöt toteutetaan Ansible-moduulien kautta. Esimerkiksi:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Täydellinen luettelo alustoista, joita Red Hat tukee täysin Ansible Automation -tilauksen kautta, .
Mitä olemme oppineet
Viimeisten neljän vuoden aikana olemme oppineet paljon verkkoautomaatioalustan kehittämisestä. Opimme myös sen как loppukäyttäjät käyttävät alustan artefakteja Ansible-pelikirjoissa ja rooleissa. Ja tässä on mitä saimme selville:
- Organisaatiot automatisoivat laitteita ei vain yhdeltä, vaan useilta toimittajilta.
- Automaatio ei ole vain tekninen, vaan myös kulttuurinen ilmiö.
- Verkostojen automatisointi mittakaavassa on vaikeampaa kuin miltä näyttää automaation suunnittelun arkkitehtonisten perusperiaatteiden vuoksi.
Kun yli vuosi sitten keskustelimme pitkän aikavälin kasvusuunnitelmistamme, yritysasiakkaamme kysyivät seuraavaa:
- Faktankeruuta on standardoitava paremmin ja yhdenmukaistettava automaation työnkulkujen kanssa kaikilla laitteilla.
- Laitteen konfiguraatioiden päivittämisen on myös oltava standardoitua ja johdonmukaista, jotta Ansible-moduulit käsittelevät syklin toisen puoliskon faktojen keräämisen jälkeen.
- Tarvitsemme tiukkoja ja tuettuja menetelmiä laitekokoonpanon muuntamiseksi strukturoiduksi dataksi. Tällä perusteella totuuden lähde voidaan siirtää verkkolaitteesta.
Faktan parannuksia
Faktojen kerääminen verkkolaitteista Ansiblen avulla tapahtuu usein satunnaisesti. Web-pohjaisilla alustoilla on eriasteisia tiedonkeruuominaisuuksia, mutta niillä on vain vähän tai ei ollenkaan toimintoja tietojen jäsentämiseen ja standardointiin avainarvopareina. Lukea Ken Celenza kertoo, kuinka vaikeaa ja tuskallista tosiasiatietojen analysointi ja standardointi voi olla.
Olet ehkä huomannut, että työskentelemme Ansible Network Engine -roolin parissa. Luonnollisesti 24 2.8 latausta myöhemmin Network Engine -roolista on nopeasti tullut yksi suosituimmista Ansible-rooleista Ansible Galaxyssa verkon automatisointiskenaarioissa. Ennen kuin siirsimme suuren osan tästä Ansible 2.9:aan valmistautuaksemme siihen, mitä Ansible XNUMX:ssä tarvitaan, tämä Ansible-rooli tarjosi ensimmäiset työkalut, jotka auttoivat jäsentämään komentoja, hallitsemaan komentoja ja keräämään tietoja verkkolaitteita varten.
Jos osaat käyttää Network Engineä, tämä on erittäin tehokas tapa kerätä, jäsentää ja standardoida faktatietoja käytettäväksi Ansiblessa. Tämän roolin haittana on, että sinun on luotava koko joukko jäsentimiä jokaiselle alustalle ja kaikille verkkotoiminnoille. Katsomalla, kuinka vaikeaa jäsentimien luominen, lähettäminen ja ylläpitäminen on Ciscon miehiltä.
Lyhyesti sanottuna faktojen saaminen laitteista ja niiden normalisointi avainarvopareiksi on olennaista mittakaavassa tapahtuvan automatisoinnin kannalta, mutta tämän saavuttaminen on vaikeaa, kun toimittajia ja verkkoalustoja on useita.
Jokainen Ansible 2.9:n verkkotietomoduuli voi nyt analysoida verkkolaitteen kokoonpanoa ja palauttaa strukturoitua dataa ilman lisäkirjastoja, Ansible-rooleja tai mukautettuja jäsentimiä.
Ansible 2.9:n jälkeen faktamoduulia on parannettu joka kerta kun päivitetty verkkomoduuli julkaistaan antamaan tietoja tästä kokoonpanon osasta. Toisin sanoen faktojen ja moduulien kehitys tapahtuu nyt samaa tahtia, ja niillä on aina yhteinen tietorakenne.
Verkkolaitteen resurssien määritykset voidaan hakea ja muuntaa strukturoiduksi tiedoiksi kahdella tavalla. Molemmilla tavoilla voit kerätä ja muuttaa tietyn resurssiluettelon käyttämällä uutta avainsanaa gather_network_resources. Resurssien nimet vastaavat moduulien nimiä, mikä on erittäin kätevää.
Faktoja kerättäessä:
Hakusanalla gather_facts Voit hakea nykyisen laitteen kokoonpanon ohjekirjan alussa ja käyttää sitä sitten koko pelikirjan ajan. Määritä yksittäiset resurssit, jotka haetaan laitteesta.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueOlet ehkä huomannut jotain uutta näissä esimerkeissä, nimittäin - gather_facts: true on nyt saatavilla natiivitietojen keräämiseen verkkolaitteille.
Verkkotietomoduulin käyttäminen suoraan:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesOhjekirja palauttaa seuraavat faktat käyttöliittymästä:
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: Ethernet1Huomaa, kuinka Ansible hakee alkuperäisen konfiguraation Arista-laitteesta ja muuntaa sen strukturoiduksi tiedoiksi käytettäväksi tavallisina avainarvopareina myöhempien tehtävien ja toimintojen yhteydessä.
Käyttöliittymäfaktoja voidaan lisätä Ansible-tallennettuihin muuttujiin ja käyttää välittömästi tai myöhemmin syötteenä resurssimoduuliin eos_interfaces ilman lisäkäsittelyä tai muuntamista.
Resurssimoduulit
Poimimme siis tosiasiat, normalisoimme tiedot, sovitimme ne standardoituun sisäiseen tietorakennekaavioon ja saimme valmiin totuuden lähteen. Hurraa! Tämä on tietysti hienoa, mutta meidän on silti jotenkin muutettava avain-arvo-parit takaisin tiettyyn kokoonpanoon, jota tietty laitealusta odottaa. Tarvitsemme nyt alustakohtaisia moduuleja täyttääksemme nämä uudet tiedonkeruu- ja normalisointivaatimukset.
Mikä on resurssimoduuli? Voit ajatella laitteen määritysosioita kyseisen laitteen tarjoamina resursseina. Verkkoresurssimoduulit on tarkoituksella rajoitettu yhteen resurssiin, ja ne voidaan pinota rakennuspalikoiden tavoin monimutkaisten verkkopalvelujen määrittämiseksi. Tämän seurauksena resurssimoduulin vaatimukset ja spesifikaatiot luonnollisesti yksinkertaistuvat, koska resurssimoduuli osaa lukea и määrittää tietyn verkkopalvelun verkkolaitteeseen.
Selvittääksesi, mitä resurssimoduuli tekee, katsotaanpa esimerkkiohjekirjaa, joka näyttää idempodent-toiminnon käyttämällä uusia verkkoresurssitietoja ja -moduulia 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.changedKuten näet, laitteelta kerätyt tiedot siirretään suoraan vastaavaan resurssimoduuliin ilman muuntamista. Kun pelikirja käynnistetään, se hakee arvot laitteesta ja vertaa niitä odotettuihin arvoihin. Tässä esimerkissä palautetut arvot ovat odotetusti (eli tarkistaa konfiguraatiopoikkeamat) ja raportoi, onko kokoonpano muuttunut.
Ihanteellinen tapa havaita konfiguraatiopoikkeama on tallentaa tosiasiat Ansiblen tallennettuihin muuttujiin ja käyttää niitä ajoittain resurssimoduulin kanssa tarkastustilassa. Tämä on yksinkertainen tapa nähdä, onko joku muuttanut arvoja manuaalisesti. Useimmissa tapauksissa organisaatiot sallivat muutokset ja määritykset manuaalisesti, vaikka monet toiminnot suoritetaan Ansible Automationin kautta.
Miten uudet resurssimoduulit eroavat aiemmista?
Verkkoautomaatioinsinöörille Ansible 3:n ja aiempien versioiden resurssimoduulien välillä on kolme pääeroa.
1) Tietyn verkkoresurssin (jota voidaan pitää myös konfigurointiosiona) osalta moduulit ja faktat kehittyvät kaikissa tuetuissa verkkokäyttöjärjestelmissä samanaikaisesti. Uskomme, että jos Ansible tukee resurssien määrittämistä yhdellä verkkoalustalla, meidän pitäisi tukea sitä kaikkialla. Tämä yksinkertaistaa resurssimoduulien käyttöä, koska verkon automaatioinsinööri voi nyt määrittää resurssin (kuten LLDP) kaikissa verkkokäyttöjärjestelmissä, joissa on alkuperäiset ja tuetut moduulit.
2) Resurssimoduulit sisältävät nyt tilaarvon.
merged: kokoonpano on yhdistetty annettuun kokoonpanoon (oletus);replaced: Resurssikokoonpano korvataan toimitetulla kokoonpanolla;overridden: Resurssikokoonpano korvataan toimitetulla kokoonpanolla; tarpeettomat resurssit poistetaan;deleted: Resurssimääritykset poistetaan/palautetaan oletusarvoiksi.
3) Resurssimoduulit sisältävät nyt vakaat palautusarvot. Kun verkkoresurssimoduuli on tehnyt (tai ehdottanut) tarvittavat muutokset verkkolaitteeseen, se palauttaa samat avainarvoparit pelikirjaan.
before: laitteen konfigurointi strukturoidun tiedon muodossa ennen tehtävää;after: jos laite on muuttunut (tai voi muuttua, jos testitilaa käytetään), tuloksena oleva konfiguraatio palautetaan strukturoituna tietona;commands: Laitteessa suoritetaan kaikki konfigurointikomennot sen saattamiseksi haluttuun tilaan.
Mitä tämä kaikki tarkoittaa? Miksi se on tärkeää?
Tämä viesti kattaa monia monimutkaisia käsitteitä, mutta toivomme, että ymmärrät lopulta paremmin, mitä yritysasiakkaat itse asiassa vaativat keräämistä, tietojen normalisointia ja silmukkamäärityksiä automaatioalustaa varten. Mutta miksi he tarvitsevat näitä parannuksia? Monet organisaatiot ovat nyt toteuttamassa digitaalista muutosta tehdäkseen IT-ympäristöstään ketterämpiä ja kilpailukykyisempiä. Paremmin tai huonommin monista verkkoinsinööreistä tulee verkkokehittäjiä joko oman edun vuoksi tai johdon käskystä.
Organisaatiot ovat ymmärtäneet, että yksittäisten verkkopohjien automatisointi ei ratkaise siilojen ongelmaa vaan lisää tehokkuutta vain jossain määrin. Red Hat Ansible Automation Platform tarjoaa tiukkoja ja normatiivisia resurssitietomalleja, joiden avulla voidaan hallita ohjelmallisesti verkkolaitteen taustalla olevia tietoja. Toisin sanoen käyttäjät hylkäävät vähitellen yksittäisiä konfigurointimenetelmiä ja suosivat nykyaikaisempia menetelmiä, joissa painotetaan teknologioita (esimerkiksi IP-osoitteita, VLAN-verkkoja, LLDP jne.) tietyn toimittajan toteutuksen sijaan.
Tarkoittaako tämä sitä, että luotettavien ja hyväksi havaittujen komentomoduulien ja konfigurointien päivät ovat luettuja? Ei missään tapauksessa. Odotetut verkkoresurssimoduulit eivät ole käytettävissä kaikissa tapauksissa tai jokaiselle toimittajalle, joten verkkosuunnittelijat tarvitsevat silti komento- ja määritysmoduuleja tiettyjä toteutuksia varten. Resurssimoduulien tarkoitus on yksinkertaistaa suuria Jinja-malleja ja normalisoida jäsentelemättömät laitekokoonpanot strukturoituun JSON-muotoon. Resurssimoduulien avulla olemassa olevien verkkojen on helpompi muuttaa kokoonpanonsa jäsennellyiksi avainarvopareiksi, jotka edustavat helposti luettavaa totuuden lähdettä. Käyttämällä strukturoituja avainarvopareja voit siirtyä kunkin laitteen konfiguroinnista riippumattomien jäsenneltyjen tietojen käsittelyyn ja tuoda verkot infrastruktuurina koodina -lähestymistavan eturintamaan.
Mitä resurssimoduuleja on tulossa Ansible Engine 2.9:ään?
Ennen kuin kerromme sinulle yksityiskohtaisesti, mitä Ansible 2.9:ssä tapahtuu, muistetaan kuinka jaoimme koko työn laajuuden.
Tunnistamme 7 luokkaa ja määritimme jokaiselle tietyt verkkoresurssit:
Huomautus: Lihavoidut resurssit suunniteltiin ja toteutettiin Ansible 2.9:ssä.
Yritysasiakkailta ja yhteisöltä saadun palautteen perusteella oli loogista käsitellä ensin niitä moduuleja, jotka liittyvät verkkotopologiaprotokolliin, virtualisointiin ja rajapintoihin.
Ansible Network -tiimi on kehittänyt seuraavat resurssimoduulit, ja ne vastaavat Red Hatin tukemia alustoja:
Ansible-yhteisö on kehittänyt seuraavat moduulit:
exos_lldp_global- Extreme Networksilta.nxos_bfd_interfaces- Ciscostanxos_telemetry- Ciscosta
Kuten näet, resurssimoduulien käsite sopii alustakeskeiseen strategiaamme. Toisin sanoen sisällytämme tarvittavat ominaisuudet ja toiminnot itse Ansibleen tukemaan standardointia verkkomoduulien kehittämisessä ja myös yksinkertaistamaan käyttäjien työtä Ansiblen roolien ja pelikirjojen tasolla. Laajentaakseen resurssimoduulien kehitystä Ansible-tiimi julkaisi Module Builder -työkalun.
Suunnitelmat Ansible 2.10:lle ja uudemmille
Kun Ansible 2.9 on julkaistu, työskentelemme Ansible 2.10:n seuraavan resurssimoduulisarjan parissa, jota voidaan käyttää verkon topologian ja käytäntöjen edelleen konfigurointiin, esim. . Kehittämissuunnitelmaa voidaan vielä muokata, joten jos sinulla on kommentteja, ilmoita siitä osoitteeseen .
Resurssit ja alkuun pääseminen
Lähde: will.com