Внатрешната игротека. Карактеристики за вмрежување во новиот Ansible Engine 2.9

Претстојното издание на Red Hat Ansible Engine 2.9 носи возбудливи подобрувања, од кои некои се дискутирани во овој напис. Како и секогаш, отворено ги развиваме подобрувањата на Ansible Network, со поддршка од заедницата. Придружете ни се - погледнете табла за издавање на GitHub и проучување на планот за развој за издание на Red Hat Ansible Engine 2.9 на вики страницата за Ансибилна мрежа.

Како што неодамна објавивме, Платформа за автоматизација на Ред Хет сега ги вклучува Ansible Tower, Ansible Engine и целата содржина на Ansible Network. Во денешно време, најпопуларните мрежни платформи се имплементираат преку Ansible модулите. На пример:

• Ариста ЕОС
• Cisco IOS
• Cisco IOS XR
• Cisco NX-OS
• Џунипер Јунос
• 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

Playbook ги враќа следните факти за интерфејсот:

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 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
Блог за платформа за автоматизација на Ansible
Иднината на испорака на содржина во Ansible
Размислувања за промена на структурата на проектот Ansible

Извор: www.habr.com