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

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

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

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

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

ansible_facts:
   ansible_network_resources:
      interfaces:
      - enabled: вярно
        name: Ethernet1
        mtu: '1476'
      - enabled: вярно
        name: Loopback0
      - enabled: вярно
        name: Loopback1
      - enabled: вярно
        mtu: '1476'
        name: Tunnel0
      - enabled: вярно
        name: Ethernet1
      - enabled: вярно
        name: Tunnel1
      - enabled: вярно
        name: 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) Модулите на ресурсите сега включват стойност на състоянието.

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

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