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

V nadcházející verzi Red Hat Ansible Engine 2.9 se můžete těšit na působivé vylepšení, z nichž některá jsou popsána v tomto článku. Jak je obvyklé, vylepšení Ansible Network jsme vyvíjeli otevřeně s podporou komunity. Připojte se - podívejte se na tabuli úkolů na GitHubu a prozkoumejte plán rozvoje pro verzi Red Hat Ansible Engine 2.9 na wiki stránce pro Ansible Network.

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časnosti se většina populárních síťových platforem implementuje prostřednictvím modulů Ansible. Například:

  • Arista EOS
  • Cisco IOS
  • Cisco IOS XR
  • Cisco NX-OS
  • Juniper Junos
  • VyOS

Úplný seznam platforem, které jsou plně podporovány Red Hat prostřednictvím předplatného Ansible Automation, je zveřejněn zde.

Co jsme se naučili

Během posledních čtyř let jsme se hodně naučili o vývoji platformy pro automatizaci sítě. Také jsme se dozvěděli, jak jak se artefakty platformy používají v playbookách a rolích Ansible ze strany koncových uživatelů. A to, co jsme zjistili:

  • Organizace automatizují zařízení ne od jednoho, ale od mnoha dodavatelů.
  • Automatizace je jev nejen technický, ale také kulturní.
  • Široká automatizace sítí je složitější, než se zdá, kvůli fundamentálním architektonickým principům návrhu automatizace.

Když jsme diskutovali o našich dlouhodobých plánech rozvoje před více než rokem, naši podnikoví klienti žádali následující:

  • Sběr faktů je potřeba lépe standardizovat a sladit s pracovním postupem automatizace pro jakákoli zařízení.
  • Aktualizace konfigurací na zařízení by také měly být standardizovány a sladěny, aby moduly Ansible zpracovaly druhou polovinu cyklu po sběru faktů.
  • Jsou potřeba přísné a podporované metody převodu konfigurace zařízení na strukturovaná data. Na tomto základě bude možné přesunout zdroj pravdy z síťového zařízení.

Vylepšení faktů

Sběr faktů ze síťových zařízení pomocí Ansible se často děje náhodně. Síťové platformy mají v různé míře vybavení pro sběr faktů, ale většinou postrádají - nebo dokonce nemají vůbec - funkce pro analýzu a standardizaci prezentace dat v párech klíč-hodnota. Přečtěte si příspěvek Kena Selenzy o tom, jak obtížné a bolestivé může být analyzovat a standardizovat data faktů.

Možná jste si všimli, jak jsme pracovali na roli Ansible Network Engine. Přirozeně, po 24 tisících stažení se role Network Engine rychle stala jednou z nejoblíbenějších rolí Ansible v Ansible Galaxy pro automatizaci síťových skriptů. Než jsme mnoho z toho přenesli do Ansible 2.8, abychom se připravili na to, co bude potřeba v Ansible 2.9, tato role Ansible poskytla první sadu nástrojů pro pomoc při analýze příkazů, správě týmů a sběru dat pro síťová zařízení.

Pokud rozumíte používání Network Engine, je to velmi efektivní způsob sběru, analýzy a standardizace faktických dat k použití v Ansible. Nevýhodou této role je, že je potřeba vytvořit celou řadu parserů pro každou platformu a pro veškerou síťovou aktivitu. Abyste pochopili, jak složité je vytvářet, dodávat a udržovat parsery, podívejte se na více než 1200 parserů od chlapců z Cisco.

Stručně řečeno, pro rozsáhlou automatizaci je velmi důležité získávat fakta ze zařízení a normalizovat je na páry klíč-hodnota, což je obtížné, když máte mnoho dodavatelů a síťových platforem.

Každý modul faktů sítě v Ansible 2.9 nyní dokáže analyzovat konfiguraci síťového zařízení a vrátit strukturovaná data — bez dalších knihoven, rolí Ansible nebo vlastních parserů.

Od Ansible 2.9 se při každém vydání aktualizovaného síťového modulu modul faktů zlepšuje, aby poskytoval data o této části konfigurace. To znamená, že vývoj faktů a modulů nyní probíhá stejným tempem a budou mít vždy společnou strukturu dat.

Konfiguraci zdrojů na síťovém zařízení lze extrahovat a převést na strukturovaná data dvěma způsoby. Oběma způsoby je možné shromáždit a převést konkrétní seznam zdrojů pomocí nového klíčového slova gather_network_resources. Názvy zdrojů odpovídají názvům modulů, což je velmi praktické.

Během sběru faktů:

Pomocí klíčového slova gather_facts lze extrahovat aktuální konfiguraci zařízení na začátku playbooku a poté ji používat po celou dobu playbooku. Uveďte jednotlivé zdroje, které je třeba extrahovat z zařízení.

- hosts: arista
  module_defaults:
    eos_facts:
      gather_subset: min
      gather_network_resources:
      - interfaces
  gather_facts: True

Mohli jste si všimnout něco nového v těchto příkladech, a to konkrétně — gather_facts: true nyní k dispozici pro nativní shromažďování faktů pro síťová zařízení.

Použití modulu pro shromažďování síťových faktů přímo:

- name: shromáždit fakta o konfiguraci rozhraní
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

Hrač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 extrahuje nativní konfiguraci z zařízení Arista a převádí ji na strukturovaná data, aby je použil ve formě standardních párů klíč-hodnota pro následné úkoly a operace.

Fakta o rozhraní lze přidat do uložených proměnných Ansible a použít je okamžitě nebo později jako vstup pro modul zdrojů eos_interfaces bez dalšího zpracování nebo konverze.

Moduly zdrojů

Takže jsme extrahovali fakta, normalizovali data, napsali je do standardizované interní struktury dat a získali hotový zdroj pravdy. Hurá! To je samozřejmě skvělé, ale stále potřebujeme nějakým způsobem převést páry klíč-hodnota zpět na konkrétní konfiguraci, kterou očekává konkrétní platforma zařízení. Nyní potřebujeme moduly pro specifické platformy, abychom splnili tyto nové požadavky na shromažďování faktů a normalizaci.

Co je modul zdroje? Sekce konfigurace zařízení lze chápat jako zdroje poskytované tímto zařízením. Moduly pro síťové zdroje jsou úmyslně omezeny na jeden zdroj a mohou být skládány jako kostky pro konfiguraci složitých síťových služeb. Výsledkem je, že požadavky a specifikace pro modul zdroje se přirozeně zjednodušují, protože modul zdroje může číst a konfigurovat konkrétní síťovou službu na síťovém zařízení.

Abychom vysvětlili, co modul zdroje dělá, podívejme se na příklad hrací desky, která ukazuje idempotentní operaci s použitím nových faktů síťového zdroje a modulu eos_l3_interface.

- název: příklad faktů, které jsou vráceny přímo zpět na zařízení.
  hostitelé: arista
  shromáždit_fakta: false
  úkoly:
  - název: získat fakta arista eos
    eos_fakta:
      shromáždit_podmnožinu: min
      shromáždit_sítové_zdroje: l3_interfaces

  - název: zajistit, aby informace o IP adrese byly přesné
    eos_l3_interfaces:
      konfigurace: "{{ ansible_network_resources['l3_interfaces'] }}"
      registrace: výsledek

  - název: zajistit, že konfigurace se nezměnila
    potvrdit:
      že: ne výsledek.změněné

Jak vidíte, shromážděná data z zařízení byla předána přímo do odpovídajícího modulu zdrojů bez transformace. Při spuštění přehrávače se hodnoty extrahují z zařízení a porovnávají se s očekávanými. V tomto příkladu odpovídající hodnoty splňují očekávání (tj. provádí se kontrola odchylek konfigurace) a je vydána zpráva, zda došlo ke změně konfigurace.

Ideálním způsobem, jak odhalit odchylky v konfiguraci, je uchovávat fakta v uložených proměnných Ansible a příležitostně je používat spolu s modulem zdroje v režimu kontroly. Tento jednoduchý způsob umožňuje zjistit, zda někdo hodnoty ručně nezměnil. Ve většině případů organizace povolují ruční změny a konfiguraci, přičemž mnohé operace probíhají prostřednictvím Ansible Automation.

Jak se nové moduly zdroje liší od předchozích?

Pro inženýra v oblasti automatizace sítí existují 3 hlavní rozdíly mezi moduly zdroje v Ansible 2.9 a předchozími verzemi.

1) Pro konkrétní síťový zdroj (který lze také chápat jako část konfigurace) se moduly a fakta vyvíjejí ve všech podporovaných síťových operačních systémech současně. Domníváme se, že pokud Ansible podporuje konfiguraci zdroje na jedné síťové platformě, měli bychom ji podporovat všude. To usnadňuje používání modulů zdrojů, protože inženýr v oblasti automatizace sítí nyní může nakonfigurovat zdroj (například LLDP) ve všech síťových operačních systémech s nativními a podporovanými moduly.

2) Moduly zdrojů nyní zahrnují hodnotu stavu.

  • sloučeno: konfigurace byla sloučena s poskytnutou konfigurací (výchozí);
  • vyměněno: konfigurace zdroje bude nahrazena poskytnutou konfigurací;
  • přepsáno: konfigurace zdroje bude nahrazena poskytnutou konfigurací; nadbytečné instance zdrojů budou odstraněny;
  • deleted: konfigurace zdroje bude ve výchozím nastavení odstraněna/obnovená.

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

3) Moduly zdroje nyní zahrnují stabilní vracené hodnoty. Když modul síťového zdroje provede (nebo navrhne) potřebné změny na síťovém zařízení, vrací stejné páry klíč-hodnota v playbooku.

  • before: konfigurace na zařízení ve formě strukturovaných dat před úkolem;
  • po: pokud se zařízení změnilo (nebo se může změnit, pokud je použit režim kontroly), výsledná konfigurace bude vrácena ve formě strukturovaných dat;
  • příkazy: jakékoli konfigurační příkazy spuštěné na zařízení, aby se dostalo 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é?

V tomto příspěvku je popsáno mnoho složitých konceptů, ale doufáme, že nakonec lépe pochopíte, co korporátní klienti požadují ohledně shromažďování faktů, normalizace dat a konfigurace cyklu pro platformu automatizace. Ale proč potřebují tyto vylepšení? V současnosti se mnoho organizací zabývá digitální transformací, aby učinily své IT prostředí pružnějšími a konkurenceschopnějšími. Ať už je to dobré nebo špatné, mnozí síťoví inženýři se stávají síťovými vývojáři - z vlastního zájmu nebo na příkaz vedoucích.

Organizace si uvědomují, že automatizace jednotlivých síťových šablon neřeší problém fragmentace a zvyšuje efektivitu pouze do určitého rozsahu. Platforma Red Hat Ansible Automation Platform poskytuje přísné a normalizované modely dat pro zdroje, aby programově spravovaly základní data na síťovém zařízení. To znamená, že uživatelé postupně opouštějí individuální způsoby konfigurace ve prospěch modernějších metod zaměřených na technologie (např. IP adresy, VLAN, LLDP atd.), a ne na konkrétní implementaci dodavatele.

Znamená to, že dny spolehlivých a ověřených modulů příkazů a konfigurací jsou sečteny? Rozhodně ne. Očekávané moduly síťových zdrojů nebudou použitelné ve všech případech a ne pro každého dodavatele, takže moduly příkazů a konfigurací budou stále potřebné síťovými inženýry pro specifické implementace. Cílem modulů zdrojů je zjednodušit velké šablony Jinja a normalizovat nestrukturované konfigurace zařízení do strukturovaného formátu JSON. S moduly zdrojů bude pro existující sítě snazší převádět své konfigurace na strukturované páry klíč-hodnota, které budou představovat snadno čitelný zdroj pravdy. Pokud použijete strukturované páry klíč-hodnota, můžete přejít od spuštění konfigurací na každém zařízení k práci s nezávislými strukturovanými daty a posunout sítě do popředí v přístupu „infrastruktura jako kód“.

Jaké moduly zdrojů se objeví v Ansible Engine 2.9?

Než podrobně probereme, co bude v Ansible 2.9, připomeňme si, jak jsme rozdělili celý objem práce.

Vyčlenili jsme 7 kategorií a každé přiřadili určité síťové zdroje:

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

Poznámka: zdroje vyznačené tučně byly plánovány a implementovány v Ansible 2.9.
Na základě zpětné vazby od firemních zákazníků a komunity bylo logické nejprve se zaměřit na moduly související 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 byly vyvinuty komunitou Ansible:

  • exos_lldp_global — od Extreme Networks.
  • nxos_bfd_interfaces — od Cisco
  • nxos_telemetry — od Cisco

Jak vidíte, koncept modulů zdrojů zapadá do naší strategie zaměřené na platformy. To znamená, že do samotného Ansible zahrnujeme potřebné schopnosti a funkce, abychom podpořili standardizaci při vývoji síťových modulů, a také zjednodušili práci uživatelů na úrovni rolí a playbooků Ansible. Abychom rozšířili vývoj modulů zdrojů, tým Ansible vydal nástroj Module Builder.

Plány na Ansible 2.10 a dál

Po vydání Ansible 2.9 se budeme věnovat dalšímu souboru modulů zdrojů pro Ansible 2.10, které budou použitelné pro další úpravy topologie a politiky sítě, například ACL, OSPF a BGPPlán rozvoje lze ještě upravit, takže pokud máte komentáře, dejte nám vědět v komunitě Ansible Network.

Zdroje a začátek práce

Tisková zpráva k Ansible Automation Platform
Blog Ansible Automation Platform
Budoucnost dodávek obsahu v Ansible
Úvahy o změně struktury projektu Ansible

Zdroj: habr.com

Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery 🔥 Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery | ProHoster