Хабрахабр

[Перевод] The Inside Playbook. Сетевые функции в новом Ansible Engine 2.9

9 вас ждут впечатляющие улучшения, и некоторые из них описаны в этой статье. В предстоящем выпуске Red Hat Ansible Engine 2. Присоединяйтесь — загляните на доску задач на GitHub и изучите план развития для выпуска Red Hat Ansible Engine 2. Как обычно, мы разрабатывали улучшения Ansible Network в открытую, при поддержке сообщества. 9 на странице wiki для Ansible Network.

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

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

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

Чему мы научились

Еще мы узнали о том, как применяются артефакты платформы в плейбуках и ролях Ansible со стороны конечных пользователей. В последние четыре года мы много узнали о разработке платформы для автоматизации сети. И вот что мы выяснили:

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

Когда мы обсуждали наши долгосрочные планы развития больше года назад, наши корпоративные клиенты просили о следующем:

  • Сбор фактов нужно лучше стандартизировать и согласовать с рабочим процессом автоматизации для любых устройств.
  • Обновление конфигураций на устройстве тоже нужно стандартизировать и согласовать, чтобы модули Ansible обрабатывали вторую половину цикла после сбора фактов.
  • Нужны строгие и поддерживаемые методы преобразования конфигурации устройства в структурированные данные. На этой основе источник истины можно будет переместить с сетевого устройства.

Улучшения фактов

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

Естественно, 24 тысячи загрузок спустя роль Network Engine быстро стала одной из самых популярных ролей Ansible в Ansible Galaxy для сценариев автоматизации сети. Возможно, вы заметили, как мы работали над ролью Ansible Network Engine. 8, чтобы подготовиться к тому, что понадобится в Ansible 2. Прежде чем мы перенесли многое из этого в Ansible 2. 9, эта роль Ansible предоставила первый набор инструментов для помощи в парсинге команд, управлении командами и сборе данных для сетевых устройств.

Минус этой роли в том, что нужно создавать целую кучу парсеров для каждой платформы и для всей сетевой активности. Если вы разбираетесь в использовании Network Engine, это очень эффективный способ сбора, парсинга и стандартизации данных фактов для использования в Ansible. Чтобы понять, как сложно создавать, поставлять и обслуживать парсеры, посмотрите на 1200 с лишним парсеров от ребят из Cisco.

В двух словах, для масштабной автоматизации очень важно получать факты от устройств и нормализовать их в пары ключ-значение, но добиться этого сложно, когда у вас много вендоров и сетевых платформ.

9 теперь может анализировать конфигурацию сетевого устройства и возвращать структурированные данные — без дополнительных библиотек, ролей Ansible или кастомных парсеров. Каждый модуль фактов сети в Ansible 2.

9 при каждом выпуске обновленного сетевого модуля модуль фактов улучшается, чтобы предоставлять данные об этом разделе конфигурации. Начиная с Ansible 2. То есть развитие фактов и модулей теперь происходит в одном темпе, и у них всегда будет общая структура данных.

Обоими способами можно собрать и преобразовать определенный список ресурсов с помощью нового ключевого слова 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: "}" register: result - name: ensure config did not change assert: that: not result.changed

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

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

Чем новые модули ресурса отличаются от предыдущих?

9 от предыдущих версий. Для инженера по автоматизации сетей существуют 3 главных отличия модулей ресурса в Ansible 2.

Мы думаем, что, если Ansible поддерживает конфигурацию ресурса на одной сетевой платформе, мы должны поддерживать ее везде. 1) Для определенного сетевого ресурса (который также можно представить себе как раздел конфигурации) модули и факты будут развиваться во всех поддерживаемых сетевых операционных системах одновременно. Это упрощает использование модулей ресурсов, потому что инженер по автоматизации сетей теперь может настроить ресурс (например, LLDP) во всех сетевых операционных системах с нативными и поддерживаемыми модулями.

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

  • merged: конфигурация объединена с предоставленной конфигурацией (по умолчанию);
  • replaced: конфигурация ресурса будет заменена на предоставленную конфигурацию;
  • overridden: конфигурация ресурса будет заменена на предоставленную конфигурацию; лишние экземпляры ресурсов будут удалены;
  • deleted: конфигурация ресурса будет удалена/восстановлена по умолчанию.

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

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

Что все это значит? Почему это важно?

Но почему им нужны эти улучшения? В этом посте описывается много сложных концепций, но мы надеемся, что в конце концов вы лучше поймете, что корпоративные клиенты просят о сборе фактов, нормализации данных и конфигурации цикла для платформы автоматизации. Хорошо это или плохо, но многие сетевые инженеры становятся сетевыми разработчиками — из собственного интереса или по велению руководителей. Сейчас многие организации занимаются цифровой трансформацией, чтобы сделать свои ИТ-среды более гибкими и конкурентоспособными.

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

Ни в коем случае. Значит ли это, что дни надежных и проверенных модулей команд и конфигурации сочтены? Цель модулей ресурсов — упростить большие шаблоны Jinja и нормализовать неструктурированные конфигурации устройства в структурированный формат JSON. Ожидаемые модули сетевых ресурсов будут применимы не во всех случаях и не для каждого вендора, так что модули команд и конфигурации еще понадобятся сетевым инженерам для определенных реализаций. Если использовать структурированные пары ключ-значение, можно перейти от запуска конфигураций на каждом устройстве к работе с независимыми структурированными данными и вывести сети на первый план при подходе «инфраструктура как код». С модулями ресурсов существующим сетям будет проще преобразовывать свою конфигурацию в структурированные пары ключ-значение, которые будут представлять собой удобный для чтения источник истины.

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

9, давайте вспомним, как мы разделили весь объем работ. Прежде чем подробно рассказать, что будет в Ansible 2.

Мы выделили 7 категорий и каждой назначили определенные сетевые ресурсы:

9.
На основе отзывов от корпоративных клиентов и сообщества логично было сначала заняться теми модулями, которые связаны с протоколами топологии сети, виртуализацией и интерфейсами.
Следующие модули ресурсов разработаны командой Ansible Network и соответствуют платформам, которые поддерживает Red Hat: Примечание: ресурсы, выделенные жирным, были запланированы и реализованы в Ansible 2.

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

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

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

Планы на Ansible 2.10 и дальше

9 мы займемся следующим набором модулей ресурсов для Ansible 2. После выпуска Ansible 2. План развития еще можно корректировать, так что, если у вас есть комментарии, сообщите об этом в сообществе Ansible Network. 10, которые можно будет использовать для дальнейшей настройки топологии и политики сети, например ACL, OSPF и BGP.

Ресурсы и начало работы

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть