Ansible 2.1: сетевые модули и конфигурация Cisco в Git

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

Анонс говорил о поддержке Cisco IOS, IOS XR, NX-OS, EOS и Junos. У нас в управлении несколько Cisco Catalyst - показалось разумным попробовать ios_config и ios_command на чём-то реальном, а не на стенде.

Что было раньше

До этого конфигурация коммутаторов жила в голове сетевого инженера, в разрозненных текстовых файлах и частично в Ansible - но только в смысле «выгрузить show running-config куда-нибудь на сервер». Вносить изменения приходилось руками через консоль или SSH. История изменений - отдельный разговор: её фактически не было. Если что-то сломалось после правки VLAN-таблицы в пятницу вечером, надо было вспоминать что именно трогали.

Серверная часть инфраструктуры у нас давно в Git через Ansible playbook-и. Каждое изменение - коммит, ревью в GitLab, журнал. На сетевом уровне - анархия. Разрыв ощущался, но казалось что инструментов нет.

Как настраивали

Подключение к Cisco IOS в Ansible 2.1 делается через provider в задаче - отдельного connection plugin-а нет, всё идёт через local connection и сам модуль решает как достучаться до железки по SSH:

- name: настроить NTP-сервер
  ios_config:
    lines:
      - ntp server 192.168.1.1
    provider:
      host: "{{ inventory_hostname }}"
      username: "{{ ansible_user }}"
      password: "{{ ansible_password }}"
      transport: ssh

Первые запуски показали две вещи. Первое - ios_config idempotent. Если строка уже есть в running-config, модуль её не добавляет повторно. Это то самое поведение, которое делает Ansible приятным для серверов - и оно работает так же для IOS. Второе - модуль умеет parents. Можно указать контекст, внутри которого надо применить конфиг, например секцию интерфейса или access-list. Это важно, потому что конфигурация IOS иерархическая и без контекста строки могут лечь не туда.

Несколько часов ушло на то чтобы разобраться с привилегированным режимом (enable). В provider есть параметр authorize: yes и auth_pass для enable-пароля. Без этого часть команд просто не применялась без внятной ошибки - модуль молчал и возвращал changed: false. Когда разобрались - всё встало на место.

Что в итоге получилось

Написали небольшой playbook для стандартной настройки нового коммутатора: NTP, syslog, SNMP community, базовые AAA-параметры. Раньше это делалось руками по шпаргалке, занимало 20-30 минут и периодически что-то забывалось. Теперь - одна команда, минута работы, и результат воспроизводим.

Важнее другое: этот playbook живёт в том же Git-репозитории что и серверные роли. Pull request, ревью, комментарий «а почему мы отключаем CDP глобально» - всё это теперь работает одинаково для серверов и для коммутаторов.

Конфигурационный дрейф, которого все боятся - ситуация когда то что в Git и то что в show running-config расходятся - можно обнаружить через ios_config в режиме check. Это не полноценный compliance-аудит, но хоть что-то.

Что не понравилось

ios_command - модуль для выполнения произвольных команд и парсинга вывода - работает, но разбирать вывод show interfaces или show ip bgp через waitfor и регулярки неудобно. Если нужна реальная аналитика по состоянию сети, а не просто применение конфигурации, это пока решается неловко. Модулей для структурированного получения состояния в 2.1 меньше чем хотелось бы.

Ещё момент - скорость. SSH-сессия к каждому устройству открывается заново для каждой задачи, и на двух десятках коммутаторов это заметно. Для серверов эта проблема решена через SSH multiplexing и persistent connections - для сетевых модулей пока так не работает.

Где это применимо

Переход оказался проще чем ожидали - не потому что задача простая, а потому что Ansible-логика на сетевых устройствах работает так же как на серверах. Если команда уже знает Ansible для Linux, освоить ios_config - дело одного-двух дней.

Для managed-проектов это открывает возможность наконец-то закрыть разрыв между серверной автоматизацией и сетевым уровнем. На проектах где инфраструктура целиком под нами - серверы, виртуализация, сеть - теперь можно вести всё в одном репозитории с единым подходом к изменениям.

Пока работает на нескольких Catalyst в тестовом режиме. Прежде чем раскатывать на всё что есть, хочется пожить с этим ещё немного и убедиться что edge case-ы не всплывут в неожиданный момент.