ADG Оставить заявку
Блог Автоматизация 4 мин чтения

Ansible 2.3 и сетевые модули: Cisco IOS/NX-OS под version control

Ansible 2.3 расширил модули для Cisco IOS и NX-OS, улучшил delegate_to для сетевых задач. Переводим 40 устройств под IaC: ios_config, ios_facts, конец ручной правке ACL.

Контекст момента

Ansible 2.3 - расширенные модули для сетевого оборудования Cisco IOS/NX-OS, улучшен delegate_to для network-задач

Год назад мы пробовали ios_config на нескольких Catalyst и написали что «пока работает в тестовом режиме, хочется пожить ещё немного». Пожили. Ansible 2.3 вышел в мае, подтянул сетевые модули заметно, и мы наконец закончили то что откладывали: все 40 устройств под version control, ACL и VLAN-конфигурация управляется через плейбуки.

Что именно изменилось в 2.3

Главное для нас - два направления.

ios_facts и nxos_facts. В 2.1 получить структурированное состояние с железки было мучением: ios_command выполнял show и возвращал сырой текст, который потом приходилось разбирать вручную. Теперь ios_facts собирает стандартный набор - интерфейсы, соседей LLDP/CDP, версию IOS, серийники - в нормальные переменные Ansible. Это позволяет писать плейбуки которые адаптируются к тому что реально есть на устройстве, а не хардкодить предположения.

delegate_to с network-задачами. В прошлых версиях delegate_to: localhost для сетевых модулей работал с оговорками - часть переменных терялась при делегировании, connection-параметры приходилось дублировать. В 2.3 это починили, и паттерн стал предсказуемым: задача делегируется на management-хост, который сам строит SSH-сессию к устройству. Для нас это важно потому что сетевые устройства не всегда доступны напрямую с машины где крутится Ansible-runner.

NX-OS модули. Добавились nxos_vlan, nxos_interface, nxos_acl и несколько других. У нас есть два Nexus в ядре - раньше они конфигурировались отдельно от Catalyst-ов, теперь в одном пайплайне.

Как выглядит задача перевода 40 устройств

Предыстория: конфигурация ACL и VLAN на этих устройствах жила в головах сетевых инженеров и частично в разрозненных текстовых файлах. Никакой истории изменений. «Кто добавил этот permit в access-list» - риторический вопрос без ответа. Несколько раз это стоило нам внепланового разбора полётов.

Серверная инфраструктура к этому моменту уже жила в Git через Terraform и Ansible. Сеть оставалась анахронизмом.

Переход делали поэтапно. Не «всё сразу», а по группам: сначала access-слой (коммутаторы доступа, меньший риск), потом distribution, потом Nexus в ядре.

Первый этап - ios_facts как аудит. Перед тем как трогать конфигурацию, прогнали ios_facts по всем устройствам и собрали inventory реального состояния. Обнаружили несколько занимательных вещей: на трёх коммутаторах VLAN 99 был определён по-разному, на двух - NTP указывал на уже не существующий сервер. Всё это висело незамеченным.

Второй этап - описание желаемого состояния. Написали роль cisco-baseline с переменными для каждой группы устройств. ACL описываются как списки в YAML, VLAN-таблица - тоже. Плейбук принимает это как желаемое состояние и применяет через ios_config.

Фрагмент для ACL выглядит примерно так:

- name: применить ACL на интерфейсы
  ios_config:
    parents: "ip access-list extended {{ item.name }}"
    lines: "{{ item.rules }}"
    match: strict
  loop: "{{ acl_definitions }}"
  delegate_to: localhost

match: strict здесь принципиален: без него ios_config в режиме line может не заметить что порядок правил в ACL изменился, а для access-list порядок - это логика.

Третий этап - CI и review. Изменения в конфигурацию сети теперь идут через pull request в тот же infra-репозиторий. Перед мержем запускается --check против реальных устройств - видно что именно изменится. Это то чего мы давно хотели: сетевое изменение проходит тот же review что и серверное.

Что скрипит

ios_config с match: strict и replace: block - это мощно, но требует аккуратности. Если блок конфигурации на устройстве отличается от ожидаемого даже в порядке строк - модуль сгенерирует diff который может быть неожиданно большим. На первых прогонах несколько раз получали изменения больше чем планировали, и приходилось разбираться почему.

Скорость работы с большим парком устройств - по-прежнему слабое место. SSH-сессия на каждую задачу к каждому устройству последовательно. На 40 устройствах это заметно. Спасает serial и разбивка по группам, но не радикально.

ios_facts собирает стандартный набор, но не всё что нужно. Ряд специфических параметров - маршрутная таблица в полном объёме, детальная статистика интерфейсов - ios_command с парсингом вывода. Это работает, просто менее элегантно.

Итог на сейчас

40 устройств под Ansible. ACL и VLAN-конфигурация живёт в Git, изменения - через pull request с --check против prod-оборудования. Конфигурационный дрейф обнаруживается прогоном в --check без apply.

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

NX-OS модули ещё не получили того же полного прогона на Nexus - там осторожничаем и проверяем тщательнее перед каждым шагом. Ядро есть ядро.

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.