A Red Hat Ansible Engine 2.9 közelgő kiadása izgalmas fejlesztéseket hoz, amelyek közül néhányat ebben a cikkben tárgyalunk. Mint mindig, most is nyíltan, közösségi támogatással fejlesztjük az Ansible Network fejlesztéseit. Csatlakozzon hozzánk – nézze meg és tanulmányozza a fejlesztési tervet a wiki oldalán .
Ahogy a közelmúltban bejelentettük, mostantól tartalmazza az Ansible Tower, az Ansible Engine és az összes Ansible Network tartalmat. Manapság a legnépszerűbb hálózati platformok az Ansible modulokon keresztül valósulnak meg. Például:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
A Red Hat által az Ansible Automation előfizetésen keresztül teljes mértékben támogatott platformok teljes listájáért: .
Mit tanultunk
Az elmúlt négy év során sokat tanultunk a hálózati automatizálási platform fejlesztéséről. Azt is megtanultuk mint platformtermékeket az Ansible játékkönyvekben és szerepekben használják a végfelhasználók. És íme, amit megtudtunk:
- A szervezetek nem csak egy, hanem sok gyártó eszközeit automatizálják.
- Az automatizálás nemcsak technikai, hanem kulturális jelenség is.
- A hálózatok méretarányos automatizálása az automatizálási tervezés alapvető építészeti elvei miatt nehezebb, mint amilyennek látszik.
Amikor több mint egy évvel ezelőtt megbeszéltük hosszú távú növekedési terveinket, vállalati ügyfeleink a következőket kérték:
- A ténygyűjtést jobban szabványosítani kell, és minden eszközön össze kell hangolni az automatizálási munkafolyamatokkal.
- Az eszköz konfigurációinak frissítésének is szabványosnak és konzisztensnek kell lennie, hogy az Ansible modulok kezeljék a ciklus második felét a tények összegyűjtése után.
- Szigorú és támogatott módszerekre van szükségünk az eszközkonfiguráció strukturált adatokká alakításához. Ezen az alapon az igazság forrása elmozdítható a hálózati eszközről.
Tényfejlesztések
A tények gyűjtése hálózati eszközökről az Ansible használatával gyakran véletlenszerűen történik. A webalapú platformok különböző fokú ténygyűjtési képességekkel rendelkeznek, de csak kevés, vagy egyáltalán nem rendelkeznek a kulcs-érték párokban lévő adatok elemzéséhez és szabványosításához. Olvas Ken Celenza arról, hogy milyen nehéz és fájdalmas lehet a tényadatok elemzése és szabványosítása.
Talán észrevette, hogy az Ansible Network Engine szerepkörön dolgozunk. Természetesen a 24 ezer letöltés után a Network Engine szerepkör gyorsan az egyik legnépszerűbb Ansible szerepkörré vált az Ansible Galaxy-ban a hálózatautomatizálási forgatókönyvekben. Mielőtt ennek nagy részét áthelyeztük volna az Ansible 2.8-ba, hogy felkészüljünk arra, amire az Ansible 2.9-ben lesz szükség, ez az Ansible szerepkör biztosította az első eszközkészletet a parancsok elemzéséhez, a parancsok kezeléséhez és a hálózati eszközök adatgyűjtéséhez.
Ha ismeri a Network Engine használatát, ez egy nagyon hatékony módja a tényadatok gyűjtésének, elemzésének és szabványosításának az Ansible-ben való használatra. Ennek a szerepkörnek az a hátránya, hogy minden platformhoz és minden hálózati tevékenységhez egy csomó elemzőt kell létrehoznia. Ha meg szeretné érteni, milyen nehéz elemzőket létrehozni, szállítani és karbantartani, vessen egy pillantást a Cisco srácaitól.
Dióhéjban, az eszközökről származó tények lekérése és kulcs-érték párokká történő normalizálása elengedhetetlen a nagyszabású automatizáláshoz, de ennek megvalósítása nehéz, ha sok szállító és hálózati platform van.
Az Ansible 2.9 minden hálózati ténymodulja elemezheti a hálózati eszköz konfigurációját, és strukturált adatokat adhat vissza – további könyvtárak, Ansible szerepkörök vagy egyéni értelmezők nélkül.
Az Ansible 2.9 óta minden egyes frissített hálózati modul kiadásakor a ténymodult továbbfejlesztik, hogy adatokat biztosítson a konfiguráció ezen szakaszáról. Vagyis a tények és a modulok fejlesztése ma azonos ütemben zajlik, és mindig közös adatszerkezetük lesz.
A hálózati eszközök erőforrásainak konfigurációja kétféleképpen kérhető le és konvertálható strukturált adatokká. Mindkét módon összegyűjthet és átalakíthat egy adott erőforráslistát egy új kulcsszó használatával gather_network_resources. Az erőforrásnevek megegyeznek a modulnevekkel, ami nagyon kényelmes.
A tények gyűjtése közben:
Kulcsszó használatával gather_facts lekérheti az aktuális eszközkonfigurációt a forgatókönyv elején, majd a teljes útmutatóban használhatja. Adja meg az eszközről lekérendő egyedi erőforrásokat.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueLehet, hogy valami újat vett észre ezekben a példákban, nevezetesen - gather_facts: true már elérhető a natív ténygyűjtéshez hálózati eszközökön.
A hálózati ténymodul közvetlen használata:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesA játékkönyv a következő tényeket adja vissza a felületről:
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: Ethernet1Figyelje meg, hogyan kéri le az Ansible a natív konfigurációt az Arista eszközről, és alakítja át strukturált adatokká, hogy szabványos kulcs-érték párokat használhasson a későbbi feladatokhoz és műveletekhez.
Az interfész tények hozzáadhatók az Ansible tárolt változókhoz, és azonnal vagy később felhasználhatók az erőforrásmodul bemeneteként eos_interfaces további feldolgozás vagy átalakítás nélkül.
Erőforrás modulok
Így kinyertük a tényeket, normalizáltuk az adatokat, szabványosított belső adatszerkezeti diagramba illesztettük, és kész igazságforrást kaptunk. Hurrá! Ez természetesen nagyszerű, de még mindig vissza kell alakítanunk a kulcs-érték párokat az adott eszközplatform által elvárt konfigurációra. Most platformspecifikus modulokra van szükségünk, hogy megfeleljünk ezeknek az új ténygyűjtési és normalizálási követelményeknek.
Mi az az erőforrás modul? Az eszköz konfigurációs szakaszait tekintheti az eszköz által biztosított erőforrásoknak. A hálózati erőforrás modulok szándékosan egyetlen erőforrásra korlátozódnak, és építőelemekként egymásra rakhatók összetett hálózati szolgáltatások konfigurálásához. Ennek eredményeképpen az erőforrásmodul követelményei és specifikációi természetesen leegyszerűsödnek, mivel az erőforrásmodul képes olvasni и konfigurálhat egy adott hálózati szolgáltatást egy hálózati eszközön.
Hogy elmagyarázzuk, mit csinál egy erőforrás-modul, nézzünk meg egy példa-lejátszási könyvet, amely egy idempodent műveletet mutat be új hálózati erőforrás-tények és modul használatával. 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.changedMint látható, az eszközről gyűjtött adatok átalakítás nélkül közvetlenül a megfelelő erőforrás modulba kerülnek. Indításkor a játékkönyv lekéri az értékeket az eszközről, és összehasonlítja azokat a várt értékekkel. Ebben a példában a visszaadott értékek a vártnak megfelelőek (vagyis ellenőrzi a konfigurációs eltéréseket), és jelzi, hogy a konfiguráció megváltozott-e.
A konfigurációs eltolódás észlelésének ideális módja, ha a tényeket Ansible tárolt változókban tárolja, és rendszeres időközönként használja őket az erőforrás modullal vizsgálati módban. Ez egy egyszerű módszer annak ellenőrzésére, hogy valaki manuálisan módosította-e az értékeket. A legtöbb esetben a szervezetek manuálisan engedélyezik a változtatásokat és a konfigurálást, bár sok műveletet az Ansible Automation segítségével hajtanak végre.
Miben különböznek az új forrásmodulok a korábbiaktól?
Egy hálózatautomatizálási mérnök számára 3 fő különbség van az Ansible 2.9 és a korábbi verziók erőforrásmoduljai között.
1) Egy adott hálózati erőforráshoz (amely konfigurációs szakasznak is tekinthető) a modulok és a tények egyidejűleg fejlődnek az összes támogatott hálózati operációs rendszerben. Úgy gondoljuk, hogy ha az Ansible támogatja az erőforrás-konfigurációt egyetlen hálózati platformon, akkor azt mindenhol támogatnunk kell. Ez leegyszerűsíti az erőforrásmodulok használatát, mivel a hálózatautomatizálási mérnök immár minden natív és támogatott modulokkal rendelkező hálózati operációs rendszeren konfigurálhat egy erőforrást (például LLDP-t).
2) Az erőforrásmodulok most már tartalmaznak állapotértéket.
merged: a konfiguráció egyesül a megadott konfigurációval (alapértelmezett);replaced: Az erőforrás-konfiguráció lecserélődik a megadott konfigurációra;overridden: Az erőforrás-konfiguráció lecserélődik a megadott konfigurációra; a szükségtelen erőforráspéldányok törlődnek;deleted: Az erőforrás-konfiguráció törlődik/visszaáll az alapértelmezettre.
3) Az erőforrásmodulok most már stabil visszatérési értékeket is tartalmaznak. Amikor a hálózati erőforrás modul elvégezte (vagy javasolta) a szükséges változtatásokat a hálózati eszközön, ugyanazokat a kulcs-érték párokat adja vissza a forgatókönyvbe.
before: konfiguráció az eszközön strukturált adatok formájában a feladat előtt;after: ha az eszköz megváltozott (vagy módosulhat, ha teszt módot használnak), az eredményül kapott konfiguráció strukturált adatként kerül visszaadásra;commands: Bármely konfigurációs parancs fut az eszközön, hogy a kívánt állapotba hozza azt.
Mit jelent mindez? Miért fontos?
Ez a bejegyzés sok összetett fogalommal foglalkozik, de reméljük, hogy a végén jobban megérti, hogy valójában mit is kérnek a vállalati ügyfelek az automatizálási platformok gyűjtésétől, adatnormalizálásától és hurokkonfigurálásától. De miért van szükségük ezekre a fejlesztésekre? Sok szervezet jelenleg digitális átalakuláson megy keresztül, hogy informatikai környezetét agilisabbá és versenyképesebbé tegye. Jóban-rosszban sok hálózati mérnök válik hálózatfejlesztővé akár önérdekből, akár a vezetőség parancsára.
A szervezetek felismerik, hogy az egyes hálózati sablonok automatizálása nem oldja meg a silók problémáját, és csak bizonyos mértékig növeli a hatékonyságot. A Red Hat Ansible Automation Platform szigorú és normatív erőforrás-adatmodelleket biztosít a mögöttes adatok programozott kezelésére a hálózati eszközön. Ez azt jelenti, hogy a felhasználók fokozatosan elhagyják az egyéni konfigurációs módszereket, és a modernebb módszerekre helyezik a hangsúlyt, és a hangsúlyt a technológiákra (például IP-címekre, VLAN-okra, LLDP-re stb.) helyezik, nem pedig egy konkrét gyártó megvalósítására.
Ez azt jelenti, hogy a megbízható és bevált parancsmodulok és konfiguráció napjai meg vannak számlálva? Semmilyen esetben sem. A várt hálózati erőforrás modulok nem minden esetben és nem minden szállítónál alkalmazhatók, így a parancs- és konfigurációs modulokra továbbra is szükségük lesz a hálózati mérnököknek bizonyos megvalósításokhoz. Az erőforrás-modulok célja a nagy Jinja-sablonok egyszerűsítése és a strukturálatlan eszközkonfigurációk normalizálása strukturált JSON-formátumba. Az erőforrás-modulokkal a meglévő hálózatok könnyebben alakíthatják át konfigurációjukat strukturált kulcs-érték párokká, amelyek az igazság könnyen olvasható forrását jelentik. A strukturált kulcs-érték párok használatával az egyes eszközökön futó konfigurációkról áttérhet a független strukturált adatokkal való munkavégzésre, és a hálózatokat az infrastruktúra-kódként megközelítés előterébe helyezheti.
Milyen erőforrásmodulok fognak megjelenni az Ansible Engine 2.9-ben?
Mielőtt részletesen elmondanánk, mi fog történni az Ansible 2.9-ben, emlékezzünk arra, hogyan osztottuk fel a teljes munkakört.
Hét kategóriát azonosítottunk, és mindegyikhez külön hálózati erőforrásokat rendeltünk:
Megjegyzés: A félkövérrel szedett forrásokat az Ansible 2.9-ben terveztük és alkalmaztuk.
A vállalati ügyfelek és a közösség visszajelzései alapján logikus volt, hogy először a hálózati topológiai protokollokhoz, virtualizációhoz és interfészekhez kapcsolódó modulokat kezeljük.
A következő erőforrás-modulokat az Ansible Network csapata fejlesztette ki, és megfelelnek a Red Hat által támogatott platformoknak:
A következő modulokat az Ansible közösség fejlesztette ki:
exos_lldp_global- az Extreme Networkstől.nxos_bfd_interfaces- a Ciscótólnxos_telemetry- a Ciscótól
Amint látja, az erőforrásmodulok koncepciója illeszkedik platformközpontú stratégiánkba. Vagyis magában az Ansible-ben beépítjük a szükséges képességeket és funkciókat, hogy támogassuk a szabványosítást a hálózati modulok fejlesztése során, és egyszerűsítsük a felhasználók munkáját az Ansible szerepek és játékkönyvek szintjén. Az erőforrásmodulok fejlesztésének bővítése érdekében az Ansible csapata kiadta a Module Builder eszközt.
Tervek az Ansible 2.10-re és későbbre
Az Ansible 2.9 kiadása után az Ansible 2.10 erőforrásmoduljainak következő készletén dolgozunk, amelyek segítségével tovább konfigurálható a hálózati topológia és házirend, pl. . A fejlesztési terv még módosítható, így ha észrevétele van, kérem jelezze .
Erőforrások és az első lépések
Forrás: will.com