Комментарии 12
кто-то поправил конфиг...меняем интервалы запроса (interval:86400) для сохранения конфигурации раз в сутки
Я же правильно понимаю, вы так и не узнаете кто и почему исправил конфиг?
Мы пошли другим путем - инженер правит yml -> git commit\push --(дальше CI\CD) --> jinja2 генерит конфиг в формате коммутатора и заливает на фтп -> ansible через "copy ftp://config.server/sw1234567.cfg runnning-config" применяет настройки на коммуте -> ждет какое-то время\прогоняет тесты -> заливает конфиг в стартап.
Попутно всякие тесты выполняются чтобы не выстрелить себе в ногу.
Сейчас пилим автоматическое выгрузку и сравнение с эталоном (как раз от любителей исправить руками)
Да, этого не узнаем. Но если включать логирование команд и парсить сислог - узнаем. Отличное у вас решение, мы до такого пока не дошли)
А вы не смотрели в сторону TACACS+ для логирования кто и какие команды вводит?
Смотрели, уже прорабатываю.
TACACS+ не везде есть, второе - при коммите в гит пишется коммент который мало-мальски объясняет зачем эти изменения нужны (иногда, просто ID задачи). Плюс на критичное оборудование оформляется MR который проверяет коллега.
С syslog\TACACS ну увидим мы что джун ошибся октетом и вместо 10.145.233.31 ввел 10.145.233.13, дальше то все равно идти и чинить
NetBox может значительно улучшить и упростить описанный процесс, выполняя роль централизованного источника данных (Source of Truth) для всей инфраструктуры сети. В этом процессе NetBox может быть интегрирован следующим образом:
1. Централизация данных и управление конфигурацией
NetBox позволяет хранить информацию обо всех сетевых устройствах, включая:
Инвентаризацию оборудования (модели, серийные номера, версии ПО).
IP-адресацию и VLAN-ы.
Текущие и целевые параметры конфигурации устройств.
Физическое расположение оборудования (стойки, дата-центры).
Как это помогает:
Вместо редактирования YAML-файлов вручную, инженер может вносить изменения через удобный веб-интерфейс NetBox или через его API.
Уменьшается риск ошибок: NetBox проверяет данные на соответствие заданным ограничениям (например, правильность IP-адресации, отсутствие дублирующихся значений).
2. Автоматическое генерирование конфигурации
NetBox может интегрироваться с Jinja2 для генерации конфигурационных файлов на основе данных из базы. Скрипт может:
Получать данные из NetBox через его API.
Использовать шаблоны Jinja2 для создания конфигурации устройств на основе этих данных.
Как это помогает:
Исключается ручное редактирование YAML-файлов.
Конфигурации всегда соответствуют текущему состоянию сети, описанному в NetBox.
Легче поддерживать стандартизацию конфигураций.
3. Автоматизация CI/CD
NetBox интегрируется с CI/CD пайплайнами через API. Вместо ручного коммита и пуша YAML-файлов:
Скрипт может запрашивать из NetBox актуальные данные для конфигурации.
Сервис CI/CD автоматически генерирует конфигурации и помещает их на FTP.
Как это помогает:
Исключается необходимость хранить YAML-файлы в репозитории.
Все изменения фиксируются в истории NetBox, а не в Git.
4. Упрощение управления изменениями
NetBox поддерживает версионирование данных. Это позволяет:
Отслеживать историю изменений в параметрах устройства.
Быстро возвращаться к предыдущей конфигурации в случае ошибки.
Как это помогает:
Инженер всегда видит, какие параметры изменялись, и кто вносил изменения.
Легче проводить аудит и восстановление в случае ошибок.
5. Улучшение мониторинга и тестирования
После применения конфигурации Ansible может использовать данные из NetBox для автоматического:
Проверки текущего состояния устройств.
Сравнения состояния сети с целевым, указанным в NetBox.
Как это помогает:
Упрощается процесс тестирования изменений.
Устройства, отклонившиеся от целевого состояния, автоматически отмечаются.
Спасибо, пробовали, не понравилось - слишком перегружено. Мы пришли к KISS-подходу и постепенно срезали все лишнее.
Отдельный кайф yaml->jinja->gitlab->ansbile в том что можно сделать оффлайн копию выкинуть ci-cd gitlab'а и в автономке раскатать все, приехать в офис и синкануться двумя командой (pull-push)
Даже больше, если в филиале все пропало, можно сгенерировать конфиг файл и отправить голубиной почтой с инструкций - зайди в веб-морду и загрузи файл.
Вместо редактирования YAML-файлов вручную, инженер может вносить изменения через удобный веб-интерфейс
Это вообще сомнительно. Если инженер не может в yml то его явно не стоит пускать к оборудованию. Ну и это... менять на 200 коммутаторах сервер времени через веб-морду - такое себе.
менять на 200 коммутаторах сервер времени через веб-морду - такое себе.
Это тоже в нетбоксе автоматизируется.
И даже если можно через Selenium, :)
Отдельный кайф yaml->jinja->gitlab->ansbile в том что можно сделать оффлайн копию выкинуть ci-cd gitlab'а и в автономке раскатать все, приехать в офис и синкануться двумя командой (pull-push)
Это только вы упомянули гитлаб :)
И нетбокс вполне себе умеет выгружать конфиг и на диск.
Супер, выглядит очень неплохо. А можете рассказать подробности?
Какие этапы в пайплайне? Какие тесты делаете и как?
Управление конфигурациями сетевого оборудования Eltex | Oxidized