The Inside Playbook. Síťové funkce v novém Ansible Engine 2.9

The Inside Playbook. Síťové funkce v novém Ansible Engine 2.9

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 vývěska na GitHubu a prostudujte si plán rozvoje vydání Red Hat Ansible Engine 2.9 na stránce wiki pro Síť Ansible.

Jak jsme nedávno oznámili, Red Hat Ansible Automation Platform nyní zahrnuje Ansible Tower, Ansible Engine a veškerý obsah Ansible Network. V současné době jsou nejpopulárnější síťové platformy implementovány prostřednictvím modulů Ansible. Například:

  • 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, zveřejněno zde.

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 zveřejnit Ken Celenza o tom, jak obtížné a bolestivé může být analyzovat a standardizovat faktická data.

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 Více než 1200 analyzátorů od kluků z Cisco.

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í.

The Inside Playbook. Síťové funkce v novém Ansible Engine 2.9

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.

The Inside Playbook. Síťové funkce v novém Ansible Engine 2.9

The Inside Playbook. Síťové funkce v novém Ansible Engine 2.9

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:

The Inside Playbook. Síťové funkce v novém Ansible Engine 2.9

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:

The Inside Playbook. Síťové funkce v novém Ansible Engine 2.9

Následující moduly jsou vyvinuty komunitou Ansible:

  • exos_lldp_global - od Extreme Networks.
  • nxos_bfd_interfaces - od společnosti Cisco
  • nxos_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ř. ACL, OSPF a BGP. Plán rozvoje lze stále upravovat, takže pokud máte připomínky, nahlaste je Komunita Ansible Network.

Zdroje a jak začít

Tisková zpráva o Ansible Automation Platform
Blog Ansible Automation Platform
Budoucnost doručování obsahu v Ansible
Úvahy o změně struktury projektu Ansible

Zdroj: www.habr.com

Přidat komentář