GetNet

Типичный цикл эксплуатации выглядит так: конфигурация наливается на устройство, сеть запускается и работает — до первого обращения. Дальше инженер подключается к железке, ищет проблему, быстро её фиксит. Так накапливаются legacy-настройки и выключенные правила (в случае MikroTik — особенно заметно). Чем дольше устройство работает, тем сложнее его диагностировать: конфигурация всё дальше уходит от ожидаемой.

Для большой и долго живущей инфраструктуры решением становится подход «инфраструктура как код». Прежде чем применять настройки на оборудовании, их можно протестировать локально и раскатать на канареечной группе. Когда группа расширяется, изменения фиксируются коммитом в систему контроля версий и раскатываются дальше. Если что-то пошло не так — коммит откатывается, и раскатывается предыдущая версия конфигов.

Логичный вопрос: почему для настройки железок используется CLI, а не API? API — это интерфейс для взаимодействия одной системы с другой, а CLI — интерфейс для человека. Раскаткой конфигурации занимается человек: он пишет генератор на понятном ему синтаксисе и сразу видит, что делает. Разбирать JSON — задача для роботов. С таким выбором можно спорить, но на практике он показывает себя хорошо.

Порог входа невысокий. Есть подробный туториал; при наличии NetBox всё дальнейшее упрощается, а сам NetBox при необходимости разворачивается по инструкции, в том числе из Docker. Annet — набор Python-пакетов, устанавливается просто. Сервис gnetcli на Go также ставится без сложностей.

Есть и другие команды — например, генерация конфигурации с комментариями о том, в каком именно генераторе появилась та или иная настройка. Это позволяет быстро понять, в какой файл нужно вносить правку — скажем, при замене SNMP-хоста.

Вендоры сетевого оборудования — тоже по-своему художники и видят мир в своём свете. В RouterOS есть стандартная обёртка find, и, казалось бы, чтобы отменить команду, достаточно заменить add на remove, подставить find со скобками — и надеяться, что применится. На практике этот приём работает не всегда.

Отдельный случай: если на железку заходили руками и удалили интерфейсы, IP-адреса остаются висеть на интерфейсе *, и при чтении конфига это тоже приходится обрабатывать.
Для таких ситуаций в Annet есть rulebook и механизм logic — набор правил, позволяющих кастомно обработать конкретные строки конфигурации. Всё это, как и генераторы, пишется на
Python — языке, на котором можно почти тезисно записать желаемое и получить рабочий код. Правило описывается через logic, а сама «магия» выносится в функцию.

Примеры не оставлены за кадром: в репозитории Annet лежит развесистая конфигурация для RouterOS — с туннелями, IPsec, GRE поверх IPsec и резервированием провайдеров. Под такую инфраструктуру написан работающий набор правил. Например, функция обработки IP-адресов выцепляет адрес и интерфейс, при отсутствии маски подставляет дефолтную (/32 или /64 для IPv6), добавляет кавычки и формирует команду удаления либо по адресу, либо по паре «адрес + интерфейс», включая случай интерфейса *.

Разграничение прав. Разные команды отвечают за разные домены: сети дата-центров, офисные сети, Wi-Fi. Разграничение переложено на политики системы контроля версий — раз инфраструктура описана кодом, всё лежит в VCS (git или, как в Яндексе, Arc). Отдельный файл политик описывает, какая команда отвечает за какой генератор. Роли прорастают из общей IDM-системы, а коммиты проходят через ревью. Есть и общие файлы — например, для свитча в дата-центре без динамической маршрутизации: изменения в такой файл уходят на ревью команде DC. Раскатка возможна только после коммита.

Безопасность раскатки. Тестирование идёт на проде, но на канареечных группах: сначала одно устройство, затем пара, затем десяток. При проблеме — откат на предыдущий коммит и раскатка предыдущей версии, так же по канареечным группам. Это возможно потому, что инфраструктура зарезервирована на других уровнях и падение одного устройства не ломает ничего глобально.

Команды сгруппированы в отдельные генераторы: один для маршрутизации, другой для IP-адресов, третий для правил firewall. Их можно применять по отдельности и в нужной последовательности — например, сначала раскатать IP-адреса, а затем менять шлюз. Дополнительно можно подложить соломки в самом инвентаре, заведя запасные адреса для возврата на устройство. Это зона ответственности инженера: думать о том, как не потерять железку, нужно и при ручном применении конфигурации.

Safe mode RouterOS сознательно не используется: он может навредить сильнее, чем помочь.

Порог внедрения. Ориентировочная оценка: примерно от сотни роутеров вложение в такую систему уже окупается — особенно если за ними стоят точки доступа. При этом сам Annet спокойно живёт на одной виртуалке. К этому моменту в компании обычно уже есть отдельный инвентарь и система мониторинга — одного inventory-файла из Ansible недостаточно.