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

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

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

• Ариста EOS
• Cisco IOS
• Cisco IOS XR
• Cisco NX-OS
• Juniper Junos
• VyOS

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

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

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

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

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

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

Фактически подобрения

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

Може да сте забелязали, че работим върху ролята на Ansible Network Engine. Естествено, 24K изтегляния по-късно, ролята на 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

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

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

- name: collect interface configuration facts
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

Наръчникът връща следните факти за интерфейса:

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

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

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

Ресурсни модули

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

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

За да обясним какво прави модулът за ресурси, нека да разгледаме примерна книга, която показва идемподентна операция, използвайки нови факти за мрежови ресурси и модул 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

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

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

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

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

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

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

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

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

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

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

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

Организациите осъзнават, че автоматизирането на отделни мрежови шаблони не решава проблема със силозите и само повишава ефективността до известна степен. Платформата за автоматизация Red Hat Ansible предоставя строги и нормативни модели на данни за ресурси за програмно управление на основните данни на мрежово устройство. Това означава, че потребителите постепенно изоставят индивидуалните методи за конфигуриране в полза на по-модерни методи с акцент върху технологиите (например 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 roles и playbooks. За да разшири разработката на ресурсни модули, екипът на Ansible пусна инструмента Module Builder.

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

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

Ресурси и започване

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

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