- Местами информация взята из собственного достаточно богатого опыта, местами из статьи habr и подкастов linkmeup
- `Автоматизация позволяет допускать меньше ошибок за счет учета алгоритмами типовых вещей, с другой стороны, если в самой автоматизации будет допущена ошибка, масштаб этой ошибки может быть очень глобальным (на моей памяти были примеры массовых окирпичиваний :)) – поэтому скорость деплоя зачастую не так важна при работе с сетевыми устройствами (в том числе поэтому от использования cli интерфейса для автоматизации не слишком страдают) и администраторы кучу раз перестраховываются перед массовым деплоем в прод, в том числе разнося изменения по времени.
- Сетевики с навыками кодинга нужны/есть во всех крупных компаниях – google, microsoft, facebook. За автоматизицию с опенсорсом сетевик может зарабатывать вплоть до 350к долларов (silicon valley). Автоматизация в таких компаниях достигает зачастую такого уровня, что исключает ручной ввод команд на устройстве полностью – между администратором и устройством есть прослойки, реализующие множество вещей
- не привязанные к вендору абстракции, управляющие модулями/драйверами, заточенными под конкретных вендоров
- деплой изменений в тестовой зоне,
- проверки корректности деплоя в тестовой зоне,
- проверки / фиксации первичного состояния прода,
- деплой в проде,
- коммит изменений в VCS
- проверки корректности деплоя и при необходимости быстрый откат на предыдущую версию
- Полный ZTP – от автовыделения адреса в IPAM до заливки прошивки и прод конфигурации и маршрутизация трафика девайсом в проде (через консольный интерфейс/DHCP/PXE/TR-069/Netconf/CloneZilla/etc)
- (дублируется в мониторинге и автоматизации сети) Автоматизация зачастую затрагивает интеграцию множества систем между собой. К примеру, на современные мониторинг системы зачастую ложится задача помимо самого мониторинга/оповещения/заведения инцидентов интеграция с системами провишенинга – напр. для реализаций сценариев по событию мониторинга:
- запускается некая healing логика (напр. деплой с нуля нового компонента/виртуальной машины вместо упавшего, поднятие бекапа)
- собирается доп.информация в инциденты
- проч автоматизированные интеграции
- Инструменты, часто используемые для автоматизации в целом и сети в частности: ansible, puppe, gitlab, jenkins, saltstack, pappet, chef (подробнее в отдельной статье, там же описаны плюсы python/python + nornir в сравнении с ansible)
- Протоколы и методы так же разные – от cli/snmp, до netconf/restconf (подробнее в отдельной статье)
- Ci/cd в сети – проверка необходимости изменения, деплой в тестовом контуре и автоматизированный анализ результатов, деплой в проде с кучей проверок.
- Главное это решение реальных задач, а не перфекционизм. Поэтому Expect/pexpect CLI – это зачастую нормальные/рабочие способы автоматизации! На тех же серверах так и делается зачастую. Можно даже сказать большее – зачастую средства самих вендоров по api под капотом предоставляя другой интерфейс снаружи по факту внутри используют cli 🙂 по сути просто метод доставки конфига/команд.
- Билайн, амазон, яндекс, одноклассники – да по сути почти все используют самописные утилиты, в том числе, часть или все операции зачастую там реализуются через CLI интерфейс (зачастую через прослойки типо nornir или почти напрямую через paramiko) и ничего постыдного в этом нет.
- ASA поддерживает REST (CRUD).
- У CUCM есть поддержка SOAP.
- Уже миллионы лет есть библиотеки по управлению сетевым оборудованием через CLI.
Для Perl существует модуль Net::Telnet Описание на www.cpan.org Для Python существует библиотека telnetlib Описание на www.python.org Также существуют аналогичные модули для работы с FTP, SSH и другими сетевыми протоколами.
- Программирование крайне важно сейчас для сетевых инженеров, которые поддерживают крупные сети. Используя api + скрипты можно изменять конфигурации максимально масштабируемо на современных устройствах Cisco. Скрипты можно писать на python, go и даже php, perl, javascript, swift. Первым и зачастую единственным языком рекомендуется python. При подключении к rest api очень часто используется связка python + requests library.
- Cisco добавила темы по автоматизации в сертификацию CCNA R&S. И отдельный трек по автоматизации devnet. Конечно во многом они пиарят там свои платформы – Cisco ACI (Application Centric Infrastructure), Cisco NSO (Network Services Orchestrator, на базе tail-f) для реализации сервисов OSS и говорят что кодинг (custom coding) с ними, по сути, не нужен. Но это безусловно в первую очередь касается стандартных кейсов использования поддерживаемых платформой устройств и чаще всего вендор лок в виде Cisco.
Automation and Programmability
Cisco has acquired Tail-f Systems, a leading provider of multi-vendor network service orchestration solutions for traditional and virtualized networks.
- Плагины в IDE поддерживают синтаксис оборудования передачи данных 🙂 Красота.
https://marketplace.visualstudio.com/items?itemName=codeout.vscode-junos
как делать ролбек/узнавать автоматизировано о проблемах после работ
++++ я так и делал чисто своим кодом – выгружал всю нужную инфу перед работами и сравнивал диф после работ. Но без авто ролбеков и заливку даже минорных изменений делал обычно аккуратно-пачками с инкрементом с проверкой перед следующей заливки успешности предыдущей – один свич, 3 свича, 10 свичей… 10000 свичей ++++
Поделитесь, пожалуйста, экспертизой в плане сетевых тестов, не знаю как сделать нормально. Вот есть у меня ансибл деплой который сначала катит дифф конфигурации, а затем после того как я просмотрел дифф и убедился, что там всё ок - прожал кнопку, затем катится боевая конфигурация на свитчи. В момент деплоя боевой конфигураци я хочу понимать, что у меня доступы никуда не теряются, прод стабильно работает и нигде никакие стойки не отвалились. Я качу изменение на свитчи и хочу автоматикой убеждаться, что у нас все хорошо после деплоя и в случае если не хорошо автоматический роллбек делать (благо джуниперы мне дают такую возможность). У нас есть мониторинг и с ним всё ок, тут имеется ввиду импакт на прод в процессе деплоя.
То есть понятно, что я могу открыть дашборд и смотреть в него, но хочу чтобы это делала автоматика и как-то считывала проблему и роллбечила.
У меня будут тесты перед деплоем, типа собрать конфигурацию в контейнерлабе и потестить какой-то базовый функционал, что есть связанность между свитчами там и т.п. Но это никак не защищает меня от каких-то ошибок на проде в момент деплоя.
Какие тесты я могу прикрутить кроме условного чека icmp, tcp до свитчей/серверов?
Имхо я бы посмотрел в сторону подергать системы мониторинга через апишку сохранить в стейт до change, после change сделать то же самое просмотреть diff и если есть отличия то опциально запустить rollback
Если хотите делать через ansible то придется писать Python модуля для ansible для такого функционала, либо что лучше взять pytest с testinfra. Suzieq и baitfish выше предлагали - тоже стоит на них посмотреть.
Ответ на вопрос сильно зависит от того, что вы вкладываете в понятие "все хорошо" и еще более зависит от того что вы вкладываете в понятие "нормально".
- доступность определенных узлов из определенного места?
- процент потери пакетов (откуда-куда)?
- jitter/latency ?
- определенные stp cost для определнных портов?
- наличие или отсутствие:
- маршрутов в таблице маршрутиации?
- определенных маков в определенном влане?
список можно продолжить.
Желательно определиться с тем что конкретно вы хотите проверять и какими средствами (везде ли есть доступ и по каким каналам (serial, snmp, ssh, grpc etc)), тогда под ваши запросы можно выбрать инструменты.
Дальше субьективное мнение:
Деплоить конфиг целиком в свичи есть смысл только в случае когда из коробки есть нормальный rollback. Если вам повезло и у вас так, то поздравляю. В таком разе да, можно накатить любую дичь и автоматом откатить обратно если не взлетело. (ну если вам все равно что будет простой конечно).
Во всех остальных случаях есть смысл пользоваться тем что в ansible назывется идемпотентностью и катить каждую технологию в отдельности (т.е. делать конфигурацию чуть более гранулярной). Тогда и площать поражения в случае факапа меньше и можно разделить условно "опасные" и условно "безопасные" части конфиграции.
Пример типового создания ci/cd pipeline / IaC подхода для сетевой инфраструктуры
Если +- коротко то вот так сейчас работает
⁃ Всё в нетбоксе (свитчи, айпишники, порты и т.п.)
⁃ В гитхабэкшен запускается джоба, которая собирает все данные из нетбокса и на их основе генерирует конфигурацию
⁃ Конфигурация попадает в дев бранч
⁃ Делаешь пул реквест из дев бранча в мастер для ревью
⁃ После ревью код пушится в мастер
⁃ Создаётся релиз в системе CI/CD
⁃ Запускает деплой в котором ансибл запускает плейбук с конфигурацией в check режиме и с выводом diff
⁃ После завершения генерируется вывод изменений которые нужно подвердить прожатием кнопки
⁃ Деплой конфигурации на свитчи без check мода
** в гитхабе только генерация конфига. Деплоится у нас другой системой.
- У нас для этого ((судя по всему имеется ввиду выработка конфигурации)) есть виртуальные стейджинг свитчи, там проверяешь функционал и потом уже код пишешь который потом зальётся так же на эти стейджинги а затем в прод.
- Это виртуальный стейджинг повторят полностью прод? Ответ нет.
- Если не секрет как в этом пайплайне вы проверяете, что строчки которые вы скормите ansible реально можно загрузить на устройство? check-mode ведь изменений не вносит, он только генерит эти самые изменения и показывает вам... Мы используем модуль вот этот https://docs.ansible.com/ansible/latest/collections/junipernetworks/junos/junos_config_module.html#parameter-check_commit и он умеет в check
Благодарю. Документация прямо говорт. Умеет синтаксис проверять без загурзки в железо. Что огромый плюс.
check_commit (bool): This argument will check correctness of syntax; do not apply changes. Note that this argument can be used to confirm verified configuration done via commit confirmed operation
Netbox из коробки все в конфигурации не поддерживает, приходится делать костыль в виде использования local config context data.
Я так понимаю, что Вы не полностью генерите конфигурацию, у Вас деплой это слияние части конфиги с dcbox с конфигой на железке? нет, фулл конфиг генерируем из нетбокса, в локальный контекст мы добавляем только тот функционал которого нет в нетбоксе типа статической маршрутизации, юзерменеджмента, различных vcp,vlt и т.п
Заранее прошу прощения за возможно дилетантский вопрос, но возможно ли в нетбоксе описать всю конфигурацию роутера/свича, с интерфейсами и айпи еще ладно, а как быть с конструкциями типа туннельных интерфейсов, bgp пирингов, IPsec туннелей?
Для бгп есть классный плагин https://github.com/k01ek/netbox-bgp
А остальное можно сделать через какие-нибудь доп поля или local config context data на девайсе
>> Представляю себе редактирование local config context data в веб формочке нетбокса не видя как железка отреагирует на эти изменения, инженерам эксплуатации нужно медаль за это давать 😁 - это не комфортная эксплуатация от слова совсем
Заливка полного конфига плохой вариант (кто бы мог подумать а🤣)
И самое главное крутить целиком конфиг, если нужно поправить например description на интерфейсе или syslog destination - не очень вариант.