Nadcházející vydání Red Hat Ansible Engine 2.9 přináší vzrušující vylepšení, z nichž některá jsou popsána v tomto článku. Jako vždy jsme vyvíjeli vylepšení Ansible Network otevřeně s podporou komunity. Přidejte se k nám – podívejte se
Jak jsme nedávno oznámili,
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Úplný seznam platforem, které Red Hat plně podporuje prostřednictvím předplatného Ansible Automation,
Co jsme se naučili
Za poslední čtyři roky jsme se hodně naučili o vývoji platformy pro automatizaci sítě. To jsme se také naučili как artefakty platformy používají koncoví uživatelé v herních knihách a rolích Ansible. A tady je to, co jsme zjistili:
- Organizace automatizují zařízení nejen od jednoho, ale od mnoha dodavatelů.
- Automatizace není jen technický fenomén, ale také kulturní.
- Automatizace sítí v měřítku je obtížnější, než se zdá, kvůli základním architektonickým principům návrhu automatizace.
Když jsme před více než rokem diskutovali o našich dlouhodobých plánech růstu, naši firemní klienti žádali o následující:
- Shromažďování faktů je třeba lépe standardizovat a sladit s automatizačními pracovními postupy napříč všemi zařízeními.
- Aktualizace konfigurací na zařízení musí být také standardizovaná a konzistentní, aby moduly Ansible zvládly druhou polovinu cyklu po shromáždění faktů.
- Potřebujeme přísné a podporované metody pro převod konfigurace zařízení na strukturovaná data. Na tomto základě lze zdroj pravdy přesunout ze síťového zařízení.
Zlepšení faktů
Shromažďování faktů ze síťových zařízení pomocí Ansible se často děje náhodně. Webové platformy mají různé stupně možností shromažďování faktů, ale mají malou nebo žádnou funkčnost pro analýzu a standardizaci reprezentace dat v párech klíč-hodnota. Číst
Možná jste si všimli, že pracujeme na roli Ansible Network Engine. Přirozeně, že po 24 2.8 staženích později se role Network Engine rychle stala jednou z nejoblíbenějších rolí Ansible v Ansible Galaxy pro scénáře automatizace sítě. Než jsme většinu z toho přesunuli do Ansible 2.9, abychom se připravili na to, co bude potřeba v Ansible XNUMX, tato role Ansible poskytla první sadu nástrojů, které pomáhají analyzovat příkazy, spravovat příkazy a shromažďovat data pro síťová zařízení.
Pokud víte, jak používat Network Engine, je to velmi efektivní způsob, jak shromažďovat, analyzovat a standardizovat data faktů pro použití v Ansible. Nevýhodou této role je, že musíte vytvořit spoustu analyzátorů pro každou platformu a pro veškerou síťovou aktivitu. Chcete-li pochopit, jak obtížné je vytvářet, odesílat a udržovat analyzátory, podívejte se na
Stručně řečeno, získávání faktů ze zařízení a jejich normalizace do párů klíč–hodnota je pro automatizaci ve velkém měřítku zásadní, ale dosáhnout toho je obtížné, když máte mnoho prodejců a síťových platforem.
Každý modul síťových faktů v Ansible 2.9 nyní může analyzovat konfiguraci síťového zařízení a vracet strukturovaná data – bez dalších knihoven, rolí Ansible nebo vlastních analyzátorů.
Od Ansible 2.9 je při každém vydání aktualizovaného síťového modulu vylepšen faktický modul, aby poskytoval data o této části konfigurace. To znamená, že vývoj faktů a modulů nyní probíhá stejným tempem a vždy budou mít společnou datovou strukturu.
Konfiguraci prostředků na síťovém zařízení lze načíst a převést na strukturovaná data dvěma způsoby. Oběma způsoby můžete shromáždit a transformovat konkrétní seznam zdrojů pomocí nového klíčového slova gather_network_resources
. Názvy zdrojů se shodují s názvy modulů, což je velmi výhodné.
Při shromažďování faktů:
Pomocí klíčového slova gather_facts
můžete načíst aktuální konfiguraci zařízení na začátku příručky a poté ji používat v celé příručce. Zadejte jednotlivé zdroje, které mají být načteny ze zařízení.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: True
Možná jste si v těchto příkladech všimli něčeho nového, konkrétně - gather_facts: true
je nyní k dispozici pro nativní shromažďování faktů pro síťová zařízení.
Přímé použití modulu síťových faktů:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
Příručka vrací následující fakta o rozhraní:
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: Ethernet1
Všimněte si, jak Ansible načítá nativní konfiguraci ze zařízení Arista a transformuje ji na strukturovaná data, která lze použít jako standardní páry klíč-hodnota pro následné úlohy a operace.
Fakta rozhraní lze přidat do uložených proměnných Ansible a použít je okamžitě nebo později jako vstup do modulu zdrojů eos_interfaces
bez dalšího zpracování nebo konverze.
Moduly zdrojů
Takže jsme extrahovali fakta, normalizovali data, vložili je do standardizovaného diagramu interní struktury dat a máme hotový zdroj pravdy. Hurá! To je samozřejmě skvělé, ale stále musíme nějak převést páry klíč-hodnota zpět na konkrétní konfiguraci, kterou konkrétní platforma zařízení očekává. Nyní potřebujeme moduly specifické pro platformu, abychom splnili tyto nové požadavky na shromažďování faktů a normalizaci.
Co je zdrojový modul? Sekce konfigurace zařízení si můžete představit jako zdroje poskytované tímto zařízením. Moduly síťových prostředků jsou záměrně omezeny na jeden zdroj a lze je skládat jako stavební bloky pro konfiguraci komplexních síťových služeb. V důsledku toho jsou požadavky a specifikace pro zdrojový modul přirozeně zjednodušeny, protože zdrojový modul umí číst и nakonfigurovat konkrétní síťovou službu na síťovém zařízení.
Abychom vysvětlili, co modul prostředků dělá, podívejme se na příklad playbooku, který ukazuje idempodentní operaci pomocí nových faktů o síťovém zdroji a modulu 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.changed
Jak vidíte, data shromážděná ze zařízení se přenášejí přímo do odpovídajícího modulu zdrojů bez konverze. Po spuštění playbook načte hodnoty ze zařízení a porovná je s očekávanými hodnotami. V tomto příkladu jsou vrácené hodnoty podle očekávání (to znamená, že kontroluje odchylky konfigurace) a hlásí, zda se konfigurace změnila.
Ideálním způsobem, jak detekovat posun konfigurace, je ukládat fakta do uložených proměnných Ansible a pravidelně je používat s modulem zdrojů v režimu kontroly. Jedná se o jednoduchý způsob, jak zjistit, zda někdo ručně nezměnil hodnoty. Ve většině případů organizace povolují změny a konfiguraci ručně, ačkoli mnoho operací se provádí prostřednictvím Ansible Automation.
Jak se nové moduly zdrojů liší od předchozích?
Pro inženýra síťové automatizace existují 3 hlavní rozdíly mezi zdrojovými moduly v Ansible 2.9 a předchozími verzemi.
1) Pro daný síťový zdroj (který lze také považovat za konfigurační sekci) se moduly a fakta budou vyvíjet ve všech podporovaných síťových operačních systémech současně. Myslíme si, že pokud Ansible podporuje konfiguraci zdrojů na jedné síťové platformě, měli bychom ji podporovat všude. To zjednodušuje použití modulů prostředků, protože technik síťové automatizace nyní může nakonfigurovat prostředek (jako je LLDP) na všech síťových operačních systémech s nativními a podporovanými moduly.
2) Moduly prostředků nyní obsahují hodnotu stavu.
merged
: konfigurace je sloučena s poskytnutou konfigurací (výchozí);replaced
: Konfigurace prostředků bude nahrazena poskytnutou konfigurací;overridden
: Konfigurace prostředků bude nahrazena poskytnutou konfigurací; nepotřebné instance zdrojů budou odstraněny;deleted
: Konfigurace prostředků bude odstraněna/obnovena na výchozí.
3) Moduly zdrojů nyní obsahují stabilní návratové hodnoty. Když modul síťového prostředku provede (nebo navrhne) potřebné změny na síťovém zařízení, vrátí stejné páry klíč-hodnota do playbooku.
before
: konfigurace na zařízení ve formě strukturovaných dat před úkolem;after
: pokud se zařízení změnilo (nebo se může změnit, pokud je použit testovací režim), bude výsledná konfigurace vrácena jako strukturovaná data;commands
: Jakékoli konfigurační příkazy se spouštějí na zařízení, aby jej uvedly do požadovaného stavu.
Co to všechno znamená? Proč je to důležité?
Tento příspěvek pokrývá mnoho složitých konceptů, ale doufáme, že nakonec budete lépe rozumět tomu, co podnikoví klienti ve skutečnosti požadují shromažďování, normalizaci dat a konfiguraci smyček pro automatizační platformu. Proč ale potřebují tato vylepšení? Mnoho organizací nyní provádí digitální transformaci, aby jejich IT prostředí byla agilnější a konkurenceschopnější. Ať už je to v dobrém nebo ve zlém, mnoho síťových inženýrů se stává síťovými vývojáři buď z vlastního zájmu, nebo na příkaz vedení.
Organizace si uvědomují, že automatizace jednotlivých síťových šablon neřeší problém sil a pouze do určité míry zvyšuje efektivitu. Red Hat Ansible Automation Platform poskytuje přesné a normativní datové modely zdrojů pro programovou správu základních dat na síťovém zařízení. To znamená, že uživatelé postupně opouštějí jednotlivé konfigurační metody ve prospěch modernějších metod s důrazem na technologie (například IP adresy, VLAN, LLDP atd.), spíše než na implementaci konkrétního dodavatele.
Znamená to, že dny spolehlivých a osvědčených velitelských modulů a konfigurace jsou sečteny? V žádném případě. Očekávané moduly síťových prostředků nebudou použitelné ve všech případech a pro každého dodavatele, takže příkazové a konfigurační moduly budou síťoví inženýři pro určité implementace stále potřebovat. Účelem zdrojových modulů je zjednodušit velké šablony Jinja a normalizovat nestrukturované konfigurace zařízení do strukturovaného formátu JSON. Se zdrojovými moduly bude pro stávající sítě snazší transformovat svou konfiguraci do strukturovaných párů klíč-hodnota, které představují snadno čitelný zdroj pravdy. Pomocí strukturovaných párů klíč–hodnota můžete přejít od spouštění konfigurací na každém zařízení k práci s nezávislými strukturovanými daty a dostat sítě do popředí přístupu infrastruktury jako kódu.
Jaké zdrojové moduly přijdou v Ansible Engine 2.9?
Než vám podrobně řekneme, co se bude dít v Ansible 2.9, připomeňme si, jak jsme si rozdělili celý rozsah práce.
Identifikovali jsme 7 kategorií a každé z nich přiřadili specifické síťové zdroje:
Poznámka: Zdroje vyznačené tučně byly naplánovány a implementovány v Ansible 2.9.
Na základě zpětné vazby od podnikových zákazníků a komunity bylo logické nejprve se zabývat moduly souvisejícími s protokoly topologie sítě, virtualizací a rozhraními.
Následující moduly zdrojů byly vyvinuty týmem Ansible Network a odpovídají platformám podporovaným Red Hat:
Následující moduly jsou vyvinuty komunitou Ansible:
exos_lldp_global
- od Extreme Networks.nxos_bfd_interfaces
- od společnosti Cisconxos_telemetry
- od společnosti Cisco
Jak vidíte, koncept zdrojových modulů zapadá do naší strategie zaměřené na platformu. To znamená, že do samotného Ansible zařazujeme potřebné schopnosti a funkce pro podporu standardizace při vývoji síťových modulů a také pro zjednodušení práce uživatelů na úrovni Ansible rolí a playbooků. Pro rozšíření vývoje zdrojových modulů vydal tým Ansible nástroj Module Builder.
Plány pro Ansible 2.10 a novější
Po vydání Ansible 2.9 budeme pracovat na další sadě modulů prostředků pro Ansible 2.10, které lze použít k další konfiguraci topologie sítě a zásad, např.
Zdroje a jak začít
Zdroj: www.habr.com