The Inside Playbook. Мрежови функции в новия Ansible Engine 2.9

В предстоящото издание на Red Hat Ansible Engine 2.9 ви очакват впечатляващи подобрения, и някои от тях са описани в тази статия. Както обикновено, ние разработваме подобренията на Ansible Network открито, с помощта на общността. Присъединете се — надникнете на дъската с задачи на GitHub и разгледайте плана за развитие за изданието Red Hat Ansible Engine 2.9 на уеб страницата за wiki за Ansible Network.

Както наскоро обявихме, Red Hat Ansible Automation Platform сега включва Ansible Tower, Ansible Engine и всичко съдържание на Ansible Network. В момента повечето популярни мрежови платформи се реализират чрез Ansible модули. Например:

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

Пълен списък на платформите, които Red Hat напълно поддържа чрез абонамента Ansible Automation, е публикуван тук.

Какво научихме

През последните четири години научихме много за разработването на платформа за автоматизация на мрежата. Освен това, открихме, как как артефактите на платформата се използват в плейбуци и роли на Ansible от страна на крайните потребители. И ето какво установихме:

• Организациите автоматизират устройства не само от един, а от множество производители.
• Автоматизацията е явление, не само техническо, но и културно.
• Масовата автоматизация на мрежите е по-сложна, отколкото изглежда, заради основните архитектурни принципи на проектиране на автоматизация.

Когато обсъждахме дългосрочните ни планове за развитие преди повече от година, нашите корпоративни клиенти поискаха следното:

• Събирането на факти трябва да бъде по-добре стандартизирано и синхронизирано с работния процес на автоматизация за всякакви устройства.
• Актуализацията на конфигурациите на устройства също трябва да бъде стандартизирана и синхронизирана, за да могат Ansible модулите да обработват втората половина на цикъла след събирането на факти.
• Необходими са строги и поддържани методи за преобразуване на конфигурацията на устройството в структурирани данни. На тази основа, източникът на истината ще може да бъде преместен от мрежовото устройство.

Подобрения в събирането на факти

Събирането на факти от мрежовите устройства с помощта на Ansible често става на произволен принцип. Мрежовите платформи в различна степен са оборудвани с възможности за събиране на факти, но почти нямат — или дори съвсем нямат — функции за парсване и стандартизиране на представянето на данни в двойки ключ-стойност. Четете пост Кен Селенца (Ken Celenza) за това колко трудно и мъчително може да бъде анализирането и стандартизиране на данните от факти.

Възможно е да сте забелязали как работихме по ролята Ansible Network Engine. Естествено, след 24 хиляди изтегляния ролята Network Engine бързо стана една от най-популярните роли Ansible в Ansible Galaxy за автоматизационни сценарии в мрежата. Преди да прехвърлим много от това в Ansible 2.8, за да се подготвим за необходимостите в Ansible 2.9, тази роля Ansible предостави първия набор от инструменти за помощ при парсинг на команди, управление на команди и събиране на данни за мрежови устройства.

Ако разбирате как да използвате Network Engine, това е много ефективен способ за събиране, парсинг и стандартизиране на факти за данни за употреба в Ansible. Недостатък на тази роля е, че трябва да се създаде множество парсери за всяка платформа и за всяка мрежова активност. За да разберете колко сложно е да се създават, доставят и поддържат парсери, разгледайте повече от 1200 парсера от екипа на Cisco.

С две думи, за мащабна автоматизация е много важно да се получават факти от устройствата и да се нормализират в двойки ключ-стойност, но постигането на това е трудно, когато имате много доставчици и мрежови платформи.

Всеки модул за факти в Ansible 2.9 сега може да анализира конфигурацията на мрежовото устройство и да връща структурирани данни — без допълнителни библиотеки, роли Ansible или персонализирани парсери.

Започвайки от Ansible 2.9 с всяко издание на актуализиран мрежов модул, модулът за факти се подобрява, за да предоставя данни за този раздел от конфигурацията. Тоест развитието на фактите и модулите сега тече в един и същи ритъм, и те винаги ще имат обща структура на данните.

Конфигурацията на ресурсите на мрежовото устройство може да бъде извлечена и преобразувана в структурирани данни по два начина. И в двата случая можете да събирате и преобразувате определен списък от ресурси с помощта на новата ключова дума gather_network_resources. Имената на ресурсите съответстват на имената на модулите, което е много удобно.

По време на събиране на факти:

С помощта на ключовата дума gather_facts можете да извлечете текущата конфигурация на устройството в началото на плейбука, а след това да я използвате през целия плейбук. Посочете отделните ресурси, които трябва да бъдат извлечени от устройството.

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

Може да сте забелязали нещо ново в тези примери, а именно — събиране_на_факти: вярно вече е налично за нативно събиране на факти за мрежови устройства.

Използване на модула за мрежови факти директно:

- име: събиране на факти за конфигурацията на интерфейса
  eos_facts:
    gather_subset: мин
    gather_network_resources:
    - интерфейси

Плейбукът връща следните факти за интерфейса:

ansible_facts:
   ansible_network_resources:
      интерфейси:
      - enabled: вярно
        име: Ethernet1
        mtu: '1476'
      - enabled: вярно
        име: Loopback0
      - enabled: вярно
        име: Loopback1
      - enabled: вярно
        mtu: '1476'
        име: Tunnel0
      - enabled: вярно
        име: Ethernet1
      - enabled: вярно
        име: Tunnel1
      - enabled: вярно
        име: Ethernet1

Обърнете внимание, как Ansible изтегля нативната конфигурация от устройството Arista и я преобразува в структурирани данни, които могат да се използват като стандартни двойки ключ-стойност за последващи задачи и операции.

Фактите за интерфейса могат да се добавят в съхранявани променливи на Ansible и да се използват веднага или по-късно като входни данни за модула за ресурси eos_interfaces без допълнителна обработка или преобразуване.

Модулите за ресурси

И така, ние извлякохме факти, нормализирахме данните, вписахме ги в стандартизирана вътрешна схема на структура данни и получихме готов източник на истина. Ура! Това е страхотно, но все пак трябва да преобразим двойките ключ-стойност обратно в конкретната конфигурация, която очаква конкретната платформа на устройството. Сега ни трябват модули за определени платформи, за да отговорим на тези нови изисквания за събиране на факти и нормализация.

Какво е модул за ресурси? Разделите на конфигурацията на устройството могат да се представят като ресурси, предоставяни от това устройство. Модулите за мрежови ресурси умишлено са ограничени до един ресурс и могат да се сглобяват, като строителни блокчета, за настройка на сложни мрежови услуги. В резултат изискванията и спецификацията за модула за ресурси се опростяват, тъй като модулът за ресурси може да чете и да настрои конкретна мрежова услуга на мрежовото устройство.

За да обясним какво прави модулът за ресурси, нека да разгледаме пример на плейбук, който показва идеоматичната операция с използването на новите факти за мрежов ресурс и модула eos_l3_interface.

- име: пример на факти, които се изпращат обратно към устройството.
  хостове: arista
  събиране_факти: false
  задачи:
  - име: вземане на факти от arista eos
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

  - име: уверете се, че информацията за IP адреса е точна
    eos_l3_interfaces:
      config: "{{ ansible_network_resources['l3_interfaces'] }}"
      register: result

  - име: уверете се, че конфигурацията не е променена
    assert:
      that: not result.changed

Както виждате, събраните данни от устройството се предават директно на съответния модул на ресурсите без преобразуване. При изпълнение на плейбука, стойностите се извличат от устройството и се сравняват с очакваните. В този пример получените стойности съвпадат с очакваните (т.е. извършва се проверка за отклонения в конфигурацията) и се издава съобщение дали конфигурацията е променена.

Идеалният начин да се открие отклонение в конфигурацията е да се запазват фактите в хранилищата на Ansible и периодично да се използват заедно с модула на ресурса в режим на проверка. Това е прост метод за наблюдение дали някой е променил стойностите ръчно. В повечето случаи организациите позволяват промени и конфигурация ръчно, въпреки че много операции се извършват чрез Ansible Automation.

Какви са разликите между новите модули на ресурсите и предишните?

За инженер по автоматизация на мрежи, има 3 основни разлики в модулите на ресурсите в Ansible 2.9 спрямо предишните версии.

1) За определен мрежов ресурс (който може да се представи и като секция от конфигурацията) модулите и фактите ще се развиват едновременно във всички поддържани мрежови операционни системи. Смятаме, че ако Ansible поддържа конфигурация на ресурс на една мрежова платформа, трябва да я поддържаме навсякъде. Това опростява използването на модулите на ресурсите, защото инженер по автоматизация на мрежи сега може да настрои ресурс (например, LLDP) във всички мрежови операционни системи с местни и поддържани модули.

2) Модулите на ресурсите вече включват стойност на състоянието.

• обединен: конфигурацията е обединена с предоставената конфигурация (по подразбиране);
• заменен: конфигурацията на ресурса ще бъде заменена с предоставената конфигурация;
• презаписан: конфигурацията на ресурса ще бъде заменена с предоставената конфигурация; излишните екземпляри на ресурсите ще бъдат премахнати;
• изтрит: конфигурацията на ресурса ще бъде изтрита/възстановена по подразбиране.

3) Модулите на ресурса вече включват стабилни връщащи стойности. Когато модулът на мрежовия ресурс внесе (или предложи) необходимите промени в мрежовото устройство, той връща същите двойки ключ-стойност в плейбука.

• before: конфигурация на устройството под формата на структурирани данни до задачата;
• след: ако устройството е променено (или може да бъде променено, ако се използва режим на проверка), получената конфигурация ще бъде върната под формата на структурирани данни;
• команди: всякакви команди за конфигурация, изпълнени на устройството, за да го приведат в желаното състояние.

Какво означава всичко това? Защо е важно?

В този пост се обсъждат много сложни концепции, но се надяваме, че в крайна сметка ще разберете по-добре какво искат корпоративните клиенти относно събиране на факти, нормализация на данни и конфигурация в цикъл за платформата за автоматизация. Но защо им трябват тези подобрения? В момента много организации извършват цифрова трансформация, за да направят ИТ-средите си по-гъвкави и конкурентоспособни. Дали това е добре или лошо, но много мрежови инженери стават мрежови разработчици — по собствено желание или по указания на ръководството.

Организациите разбират, че автоматизацията на отделни мрежови шаблони не решава проблема с разпокъсаността и увеличава ефективността само до определен предел. Платформата Red Hat Ansible Automation Platform предоставя стриктни и нормализиращи модели на данни за ресурсите, за да управлява програмно основните данни на мрежовото устройство. Тоест потребителите постепенно се отказват от индивидуалните методи на конфигурация в полза на по-съвременни техники, акцентирайки на технологиите (например, IP адреси, VLAN, LLDP и т.н.), а не на конкретното изпълнение на доставчика.

Нима това означава, че дните на надеждните и проверени модули за конфигурация и команди са преброени? В никакъв случай. Очакваните модули за мрежови ресурси ще бъдат приложими не във всички случаи и не за всеки доставчик, така че модулите за команди и конфигурации все още ще бъдат необходими на мрежовите инженери за специфични реализации. Целта на модулите за ресурси е да опростят големи Jinja шаблони и да нормализират неструктурираните конфигурации на устройството в структурирания формат JSON. С модулите за ресурси съществуващите мрежи ще могат да преобразуват конфигурацията си в структурирани ключ-стойност двойки, които ще представляват лесен за четене източник на истина. Използвайки структурирани двойки ключ-стойност, можем да преминем от настройка на конфигурации на всяко устройство към работа с независими структурирани данни и да изведем мрежите напред в подхода "инфраструктура като код."

Кои модули за ресурси ще се появят в Ansible Engine 2.9?

Преди да разкажем подробно какво ще включва Ansible 2.9, нека си припомним как разделихме целия обем работа.

Да отделим 7 категории и да назначим определени мрежови ресурси за всяка от тях:

Забележка: Ресурсите, подчертаните с удебелен шрифт, бяха планирани и реализирани в Ansible 2.9.
На база на отзивите от корпоративни клиенти и общността беше логично първо да се вземат под внимание модулите, свързани с протоколи за мрежова топология, виртуализация и интерфейси.
Следните модули за ресурси са разработени от екипа на Ansible Network и съответстват на платформите, поддържани от Red Hat:

Следните модули са разработени от общността на Ansible:

• exos_lldp_global — от Extreme Networks.
• nxos_bfd_interfaces — от Cisco
• nxos_telemetry — от Cisco

Както виждате, концепцията за модули за ресурси се вписва в нашата стратегия за платформа. Тоест, интегрираме необходимите функции и възможности в самия Ansible, за да подкрепим стандартизацията при разработката на мрежови модули и да улесним работата на потребителите на ниво роли и плейбуци на Ansible. За да разширим разработката на модулите за ресурси, екипът на Ansible пусна инструмента Module Builder.

Планове за Ansible 2.10 и след това

След пускането на Ansible 2.9 ще се заемем с нов набор модули за ресурси за Ansible 2.10, които ще могат да се използват за допълнителна настройка на топологията и политиките на мрежата, например ACL, OSPF и BGP. Плана за развитие все още може да бъде коригиран, така че, ако имате коментари, уведомете ни за това в общността Ansible Network.

Ресурси и старт на работа

Прессъобщение за Ansible Automation Platform
Блог на Ansible Automation Platform
Бъдещето на доставката на съдържание в Ansible
Размисли за промяна на структурата на проекта Ansible

Източник: habr.com