A Red Hat Ansible Engine 2.9 közelgő kiadásában lenyűgöző fejlesztések várnak Önre, és ezek közül néhányat ebben a cikkben ismertetünk. Mint mindig, az Ansible Network fejlesztéseit nyíltan, a közösség támogatásával dolgoztuk ki. Csatlakozzon – nézze meg a és tekintse meg a fejlesztési tervet a az Ansible Network wiki oldalán .
Ahogy nemrég bejelentettük, mostantól magában foglalja az Ansible Tower-t, az Ansible Engine-t és az egész Ansible Network tartalmat. Jelenleg a legnépszerűbb hálózati platformok többsége Ansible modulokon keresztül valósul 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és keretében teljes mértékben támogatott platformok teljes listája .
Amit tanultunk
Az elmúlt négy évben sokat tanultunk a hálózati automatizáló platform fejlesztéséről. Továbbá azt is megtudtuk, hogyan hogyan alkalmazzák a platform artefaktumait az Ansible playbookokban és szerepekben a végfelhasználók. Íme, amit felfedeztünk:
- A szervezetek nem egy, hanem számos gyártó eszközeit automatizálják.
- Az automatizálás nemcsak technikai jelenség, hanem kulturális is.
- A hálózati automatizálás nagy léptékben bonyolultabb, mint amilyennek látszik, az automatizálási tervezési alapelv fundamentális okai miatt.
Amikor tavaly több mint egy évvel ezelőtt a hosszú távú fejlesztési terveinket vitattuk, vállalati ügyfeleink a következőt kérték:
- A tényszerzésnek jobban standardizáltnak és az automatizálási munkafolyammal összehangoltnak kell lennie bármilyen eszköznél.
- Az eszközön végzett konfigurációfrissítéseket is standardizálni és összehangolni kell, hogy az Ansible modulok a tények begyűjtése utáni második fázist kezeljék.
- Szigorú és támogatott módszerek szükségesek az eszköz konfigurációs adatok strukturált adatokra történő átalakítására. Ezen az alapon az igazság forrását át lehet helyezni a hálózati eszközön.
Tények fejlesztése
A hálózati eszközökről az Ansible-t használva történő tényszerzés gyakran találomra zajlik. A hálózati platformok eltérő mértékben rendelkeznek ténybegyűjtési lehetőségekkel, de szinte egyáltalán nincsenek – vagy szinte egyáltalán nincsenek – funkcióik az adatok kulcs-érték párra történő elemzésére és standardizálására. Olvassa el Ken Celenza írását, hogy megtudja, milyen nehéz és fájdalmas lehet az adatok elemzése és standardizálása.
Talán észrevette, hogy dolgoztunk az Ansible Network Engine szerepén. Természetesen a 24 ezer letöltés után a Network Engine szerep gyorsan az Ansible Galaxy egyik legnépszerűbb szerepévé vált a hálózati automatizálási szkriptek számára. Mielőtt sok mindent áthelyeztünk az Ansible 2.8-ba, hogy felkészüljünk arra, amire az Ansible 2.9-ben szükség lesz, ez az Ansible szerep biztosította az első eszközkészletet a parancsok elemzéséhez, a csapatok kezeléséhez és az adatok gyűjtéséhez a hálózati eszközökről.
Ha érted, hogyan használhatod a Network Engine-t, ez egy nagyon hatékony módja a tények adatainak gyűjtésére, elemzésére és standardizálására Ansible-ban. A szerep hátránya, hogy rengeteg parsert kell létrehozni minden platformhoz és az összes hálózati tevékenységhez. Ahhoz, hogy megértsd, mennyire nehéz parsert létrehozni, szállítani és karbantartani, nézd meg a Cisco csapatától.
Röviden, a nagyszabású automatizálás esetén rendkívül fontos, hogy tényeket szerezzünk a készülékekről, és ezeket kulcs-érték párokba normalizáljuk, de ez nehéz, ha sok különböző gyártónk és hálózati platformunk van.
Az Ansible 2.9-ben minden hálózati ténymodul most képes a hálózati eszköz konfigurációjának elemzésére és strukturált adatok visszaadására — külön könyvtárak, Ansible szerepek vagy egyedi parsert nélkül.
Az Ansible 2.9-től kezdve, amikor egy új hálózati modul kerül kiadásra, a ténymodul folyamatosan fejlődik, hogy adatokat nyújtson a konfigurációs szekcióról. Ez azt jelenti, hogy a tények és a modulok fejlődése most egy ütemben történik, és mindig közös adattal rendelkeznek.
A hálózati eszköz konfigurációs erőforrásait kétféle módon lehet kinyerni és strukturált adatokba átalakítani. Mindkét módszerrel egy meghatározott erőforráslistát gyűjthetünk és alakíthatunk át az új kulcsszóval gather_network_resources. Az erőforrások nevei megegyeznek a modulok neveivel, ami rendkívül kényelmes.
Tények gyűjtésekor:
A kulcsszóval gather_facts ki lehet nyerni a készülék aktuális konfigurációját a playbook elején, és aztán használhatod az egész playbook során. Megadhatod azokat az egyedi erőforrásokat, amelyeket ki szeretnél nyerni a készülékről.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueÉszrevettél valami újat ezekben a példákban, nevezetesen — gather_facts: true most már elérhető a natív ténygyűjtés a hálózati eszközök számára.
A hálózati tények modul közvetlen használata:
- név: interfész konfigurációs tények gyűjtése
eos_facts:
gather_subset: min
gather_network_resources:
- interfészekA playbook a következő tényeket adja vissza az interfészről:
ansible_facts:
ansible_network_resources:
interfészek:
- engedélyezett: true
név: Ethernet1
mtu: '1476'
- engedélyezett: true
név: Loopback0
- engedélyezett: true
név: Loopback1
- engedélyezett: true
mtu: '1476'
név: Tunnel0
- engedélyezett: true
név: Ethernet1
- engedélyezett: true
név: Tunnel1
- engedélyezett: true
név: Ethernet1Figyelje meg, hogyan húzza ki az Ansible a natív konfigurációt az Arista eszközről, és alakítja át azt strukturált adatokra, hogy standard kulcs-érték párokként használhassa a későbbi feladatokhoz és műveletekhez.
Az interfész tények Ansible tárolt változókba adhatók, és azonnal vagy később bemenetként használhatók a forrás modulhoz. eos_interfaces további feldolgozás vagy átalakítás nélkül.
Erőforrás modulok
Tehát kinyertük a tényeket, normalizáltuk az adatokat, beillesztettük azokat egy szabványosított belső adatstruktúrába, és így készen állunk a hiteles forrásra. Hurrá! Ez természetesen nagyszerű, de még mindig vissza kell alakítanunk a kulcs-érték párokat arra a konkrét konfigurációra, amelyet egy adott eszközplatform elvár. Most olyan modulokra van szükségünk, amelyek bizonyos platformokhoz megfelelnek ezek új ténygyűjtési és normalizálási követelményeinek.
Mi az erőforrás modul? Az eszköz konfigurációs szekciókat olyan erőforrásokként lehet elképzelni, amelyeket az eszköz biztosít. A hálózati erőforrás modulokat szándékosan egy erőforrásra korlátozzák, és azok összekapcsolhatók, mint a legók, összetett hálózati szolgáltatások testreszabásához. Ennek eredményeként az erőforrás modul követelményei és specifikációi természetes módon egyszerűsödnek, mivel az erőforrás modul képes és konfigurálni egy adott hálózati szolgáltatást egy hálózati eszközön.
Hogy megértsük, mit csinál az erőforrás modul, nézzünk meg egy példát egy playbookra, amelyben az új hálózati erőforrás tények és modul segítségével az idempotens művelet látható. eos_l3_interface.
- név: példa arra, hogy a tények közvetlenül visszakerülnek az eszközhöz.
gazdák: arista
tények_gyűjtése: hamis
feladatok:
- név: arista eos tények lekérdezése
eos_tények:
gyűjtési_alcsoportra: min
gyűjtsd_össze_a_hálózati_erőforrásokat: l3_interfaces
- név: győződj meg arról, hogy az IP-cím információ pontos
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
regisztráció: eredmény
- név: győződj meg arról, hogy a konfiguráció nem változott meg
állítás:
hogy: nem eredmény.megváltozottAhogy látja, az eszközről gyűjtött adatokat közvetlenül a megfelelő erőforrás modulnak küldjük, átalakítás nélkül. A playbook futtatásakor az értékeket az eszközről nyerjük ki, és összehasonlítjuk a vártakkal. Ebben a példában az elért értékek megfelelnek a várt értékeknek (azaz a konfiguráció eltérésének ellenőrzése megtörténik), és a rendszer jelzi, hogy megváltozott-e a konfiguráció.
A legjobb módja a konfiguráció eltéréseinek felfedezésére, ha az Ansible tárolt változókban megtartja a tényeket, és időről időre a forrásmodullal ellenőrzi azokat. Ez egy egyszerű módszer annak látására, hogy valaki kézzel módosította-e az értékeket. A legtöbb esetben a szervezetek megengedik a kézi módosításokat és konfigurációt, bár sok művelet az Ansible automatizáláson keresztül történik.
Miben különböznek az új erőforrás modulok a korábbiaktól?
A hálózati automatizáló mérnök számára három fő különbség van az Ansible 2.9 erőforrás moduljai és a korábbi verziók között.
1) Egy adott hálózati erőforráshoz (amelyet konfigurációs résznek is tekinthetünk) a modulok és a tények egyszerre fejlődnek minden támogatott hálózati operációs rendszerben. Úgy véljük, hogy ha az Ansible támogat egy erőforrás konfigurációt egy hálózati platformon, azt mindenhol támogatni kell. Ez leegyszerűsíti az erőforrás modulok használatát, mert a hálózati automatizáló mérnök most natív és támogatott modulokkal tudja beállítani az erőforrást (például LLDP) minden hálózati operációs rendszerben.
2) Az erőforrás modulok most tartalmazzák az állapotértéket.
összevonva: a konfiguráció egyesül a megadott konfigurációval (alapértelmezés szerint);helyettesítve: az erőforrás konfigurációja a megadott konfigurációra lesz cserélve;felülírva: az erőforrás konfigurációja a megadott konfigurációra lesz cserélve; a felesleges erőforrás példányok eltávolításra kerülnek;deletált: az erőforrás konfigurációja alapértelmezés szerint eltávolításra/visszaállításra kerül.
3) Az erőforrás moduljai most már megbízható visszatérési értékeket tartalmaznak. Amikor a hálózati erőforrás modulja végrehajtotta (vagy javasolta) a szükséges módosításokat a hálózati eszközön, ugyanazokat a kulcs-érték párokat adja vissza a playbookban.
before: a konfiguráció az eszközön strukturált adatok formájában a feladat előtt;miután: ha az eszköz megváltozott (vagy megváltozhat, ha ellenőrzési módot használnak), a kapott konfigurációt strukturált adatok formájában adják vissza;parancsok: bármely konfigurációs parancs, amelyet az eszközön futtatnak, hogy elérje a kívánt állapotot.
Mit jelent ez az egész? Miért fontos ez?
Ebben a bejegyzésben sok bonyolult fogalmat tárgyalunk, de reméljük, hogy végül jobban megérti, hogy az üzleti ügyfelek milyen ténygyűjtést, adatnormalizálást és konfigurációs ciklusokat kérnek az automatizálási platformhoz. De miért van szükségük ezekre a fejlesztésekre? Jelenleg sok szervezet digitális átalakuláson megy keresztül, hogy IT környezetüket rugalmasabbá és versenyképesebbé tegyék. Jó vagy rossz, de sok hálózati mérnök hálózati fejlesztővé válik — saját érdeklődésükből vagy vezetőik kérésére.
A szervezetek felismerik, hogy az egyes hálózati sablonok automatizálása nem oldja meg a fragmentáltság problémáját, és a hatékonyságot csak egy bizonyos határig növeli. A Red Hat Ansible Automation Platform szigorú és normáló erőforrásadat-modelleket kínál a hálózati eszközön lévő alapadatok programozott kezeléséhez. Ezért a felhasználók fokozatosan lemondanak az egyéni konfigurációs módokról a modernebb megközelítések javára, amelyek a technológiákra (például IP-címek, VLAN, LLDP stb.) összpontosítanak, nem pedig a konkrét gyártó implementációjára.
Jelenti ez, hogy a megbízható és jól bevett modulok, valamint a konfigurációk napjai meg vannak számlálva? Egyáltalán nem. Az elvárt hálózati erőforrás modulok nem minden esetben és nem minden szolgáltatónál lesznek alkalmazhatók, így a hálózati mérnököknek még mindig szükségük lesz parancs- és konfigurációs modulokra egyes megvalósításokhoz. Az erőforrás modulok célja, hogy egyszerűsítsék a nagy Jinja sablonokat és normalizálják a strukturálatlan eszközkonfigurációkat egy 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 egy könnyen olvasható igazságforrást fognak képviselni. A strukturált kulcs-érték párok használatával át lehet térni arról, hogy minden eszközön futtassák a konfigurációkat, arra, hogy független strukturált adatokkal dolgozzanak, ezzel előtérbe helyezve a „infrastruktúra mint kód” megközelítést.
Milyen erőforrás modulok jelennek meg az Ansible Engine 2.9 verziójában?
Mielőtt részletesen beszélnénk arról, hogy mi lesz az Ansible 2.9-ben, emlékezzünk vissza arra, hogyan osztottuk fel az egész munkamennyiséget.
Hét kategóriát különítettünk el, és mindegyiknek meghatározott hálózati erőforrásokat rendeltünk:
Megjegyzés: A vastagon kiemelt erőforrások tervezése és megvalósítása az Ansible 2.9 verzióban történt.
A vállalati ügyfelektől és a közösségtől kapott visszajelzések alapján logikus volt először azokat a modulokat fejleszteni, amelyek a hálózati topológiák, virtualizáció és interfészek protokolljaihoz kapcsolódnak.
A következő erőforrás modulok az Ansible Network csapata által kerültek kidolgozásra, és megfelelnek a Red Hat által támogatott platformoknak:
A következő modulokat az Ansible közössége fejlesztette:
exos_lldp_global— az Extreme Networks-től.nxos_bfd_interfaces— a Cisco-tólnxos_telemetry— a Cisco-tól
Amint látja, az erőforrás modulok koncepciója illeszkedik a platform-orientált stratégiánkhoz. Ez azt jelenti, hogy az Ansible-be beépítjük a szükséges képességeket és funkciókat, hogy támogassuk a hálózati modulok fejlesztésének standardizálását, és egyszerűsítsük a felhasználók munkáját az Ansible szerepein és playbook-jain. Az erőforrás modulok fejlesztésének bővítése érdekében az Ansible csapat kiadta a Module Builder eszközt.
Tervek az Ansible 2.10-re és azon túl
Az Ansible 2.9 kiadása után a következő erőforrás modulokkal foglalkozunk az Ansible 2.10 verziójához, amelyeket a hálózati topológia és politika további finomhangolásához lehet használni, például A fejlődési terv még módosítható, így ha van bármilyen megjegyzése, kérem jelezze azt a .
Források és az indulás
Forrás: habr.com
