OPS Автоматизация сети: API, Python, Ansible, NetDevOps

Настроить один роутер руками — навык. Настроить двести одинаково, без ошибок, к утру — уже невозможно вручную. Здесь заканчивается «кликающий инженер» и начинается NetDevOps: сеть описывают кодом, катят через pipeline и хранят в git, как обычную инфраструктуру. Это блок автоматизации CCNA 200-301 и — главное — прямой мост из СПД в DevOps. Тот самый переход, ради которого ты шёл «снизу»: ты уже понимаешь пакеты, теперь добавишь код.

Что узнаешь

Почему CLI/SNMP не годятся для автоматизации и что пришло: NETCONF/RESTCONF, YANG, gNMI
Форматы данных: JSON / XML / YAML — язык машин
REST API: методы, коды ответа, токены — как программно управлять контроллером
Python для сети: requests, Netmiko/NAPALM
Ansible: playbook, inventory, идемпотентность — декларативно
SDN / controller-based: control vs data plane, southbound/northbound
Infrastructure as Code и CI/CD для сети (NetDevOps)
Мини-лаба с настоящим REST API и плейбук безопасного массового изменения

Вспомни из прошлых модулей

Модуль 11: у Junos модель candidate→commit→rollback — концептуальный предок «инфраструктуры как кода». Модуль 17: структурированные данные и telemetry (YANG/gNMI) — сегодня они же несут конфигурацию. Модуль 15/16: одну и ту же настройку на сотнях устройств руками не раскатать — вот зачем автоматизация. Это финал трека: собираем всё в «сеть как код».

1. Заявка: «добавить VLAN на 200 коммутаторов к утру»

Задача №10044

«Новый отдел — нужен VLAN 55 и его SVI на всех 200 коммутаторах доступа в 6 филиалах. Плюс поменять SNMP на v3 везде. Срок — к утру. Ошибок быть не должно: прошлый раз руками пропустили 10 устройств, и полдня искали, где».

Руками — это 200 SSH-сессий, копипаст, неизбежные опечатки и пропуски. Автоматизацией — один прогон на несколько минут, одинаково на всех, с проверкой. Разница между «инженер, которого хватает на 20 устройств» и «инженер, который управляет тысячами» — вот в этом модуле.

2. Почему CLI не масштабируется

Ручной CLI упирается в три стены, и каждую закрывает автоматизация:

Проблема ручного CLI	Что даёт автоматизация
Не масштабируется: 200 устройств × ручной ввод	один прогон на все сразу
Человеческие ошибки: опечатки, пропуски	один проверенный шаблон, применённый одинаково
Нет воспроизводимости и истории «кто что менял»	конфиг в git: ревью, история, откат
CLI-вывод — текст для человека, парсить хрупко	структурированные данные (JSON/XML) через API

Ключевой сдвиг мышления: от императивного «введи эти команды» к декларативному «вот желаемое состояние — приведи к нему». И от «текста для глаз» к структурированным данным для машин. На этих двух идеях стоит весь NetDevOps.

3. API устройств: NETCONF, RESTCONF, gNMI

CLI придуман для человека — его формат меняется между версиями, и скрипт, парсящий «простыню», ломается. Поэтому появились программные интерфейсы со структурированными данными, описанными моделями YANG (единая схема, что у устройства можно читать/менять):

NETCONF — управление конфигурацией по XML поверх SSH; есть candidate/commit и rollback (как у Junos из модуля 11).
RESTCONF — то же по HTTP (REST-стиль), данные в JSON/XML — проще для веб-мира.
gNMI — современный gRPC-интерфейс: и конфигурация, и стриминговая телеметрия (модуль 17).

Суть одна: машина говорит с машиной структурированными данными, без парсинга текста.

4. Форматы данных: JSON, XML, YAML

Автоматизация — это перекладывание структурированных данных. Три формата, которые надо узнавать:

# JSON — язык API (машинный, компактный) { "vlan": { "id": 55, "name": "SALES", "svi": "10.55.0.1/24" } } # YAML — язык конфигов и Ansible (человекочитаемый; отступы значимы!) vlan: id: 55 name: SALES svi: 10.55.0.1/24 # XML — формат NETCONF <vlan><id>55</id><name>SALES</name></vlan>

JSON — в REST-ответах и телеметрии; YAML — в Ansible-плейбуках и inventory; XML — в NETCONF. Все три описывают одни и те же вложенные «ключ → значение», просто разным синтаксисом.

5. REST API — как программно управлять сетью

Контроллеры (Cisco Catalyst/DNA Center, облачные панели, SDN) управляются по REST API поверх HTTPS. Клиент шлёт запрос методом, сервер возвращает данные и код статуса:

Метод	Действие
`GET`	прочитать ресурс	GET /api/vlans → список
`POST`	создать	POST /api/vlans (тело — JSON)
`PUT/PATCH`	изменить	PUT /api/vlans/55
`DELETE`	удалить	DELETE /api/vlans/55

Коды ответа: 2xx — успех (200 OK, 201 Created), 4xx — ошибка клиента (401 не авторизован, 403 запрещено, 404 не найдено), 5xx — ошибка сервера. Доступ обычно по токену (сначала логин → получил токен → шлёшь его в заголовке).

6. Python для сети

Python — лингва франка сетевой автоматизации. Три кита:

# requests — обращение к REST API import requests r = requests.get("https://dnac/api/vlans", headers={"X-Auth-Token": token}, verify=False) vlans = r.json() # сразу структура Python, без парсинга текста

requests — HTTP/REST к контроллерам и сервисам.
Netmiko — если устройство умеет только SSH/CLI: шлёт команды и аккуратно собирает вывод (мост из «старого мира» в скрипты).
NAPALM — единый интерфейс к разным вендорам (get facts, загрузка конфигурации, diff, откат) — пишешь код один раз, работает на Cisco/Juniper/Arista.

7. Ansible — декларативно и идемпотентно

Ansible описывает желаемое состояние в YAML-playbook и приводит к нему устройства из inventory (список хостов). Не нужен агент на устройстве — Ansible ходит по SSH/API. Ключевое свойство — идемпотентность:

# playbook.yml — добавить VLAN 55 на все коммутаторы доступа - hosts: access_switches tasks: - name: Ensure VLAN 55 exists cisco.ios.ios_vlans: config: - name: SALES vlan_id: 55 state: merged

Описываешь состояние, а не шаги

«VLAN 55 должен существовать» — а не «введи команду vlan 55». Ansible сам проверит и добавит, если нет.

Идемпотентность: повтор безопасен

Запустил ещё раз — где уже настроено, изменений ноль (changed=0). Никаких «дважды применил — сломал». Прогон предсказуем и безопасен.

Один прогон — все 200 устройств

Inventory группирует хосты; задача применяется ко всей группе одинаково. Та самая заявка «VLAN на 200 коммутаторов» закрывается одним ansible-playbook.

8. SDN и controller-based networking

Классически «мозг» (принятие решений — control plane) и «мышцы» (пересылка пакетов — data plane) живут в каждом устройстве. SDN (Software-Defined Networking) выносит мозг в контроллер: он держит общую картину и раздаёт политику, а устройства только пересылают трафик.

Southbound — «вниз», к устройствам

Контроллер программирует устройства через NETCONF/OpenFlow: раздаёт правила пересылки и политику.

Northbound — «вверх», к приложениям

Приложения и автоматизация управляют контроллером через REST API. Так сеть настраивается как единое целое: «дай отделу продаж связность» — а не 200 ручных конфигов.

Для CCNA достаточно понимать разделение плоскостей и идею northbound/southbound; на практике это Cisco SD-Access/DNA Center, Meraki, а в ЦОД — фабрики с контроллером.

9. NetDevOps: сеть как код в CI/CD

Финальная сборка идей — Infrastructure as Code для сети:

Конфиг живёт в git

Желаемое состояние (шаблоны, переменные, playbook'и) — в репозитории. Изменение — через pull request с ревью коллеги.

Pipeline проверяет до применения

CI прогоняет линт, валидацию синтаксиса, тесты в лабе/симуляции — ошибка ловится ДО прода.

Раскатка и откат

Прошло проверки — Ansible применяет на парк. Что-то не так — откат к прошлой версии из git. Всё воспроизводимо и с историей.

Это ровно тот же CI/CD, что катит приложения в DevOps, — только «артефакт» здесь конфигурация сети. Ты пришёл к DevOps не «сверху» (как большинство, кто плавает в основах), а снизу: сначала пакеты и протоколы, теперь код поверх них. Комбинация «глубоко понимаю сеть + умею автоматизировать» — редкая и дорогая.

10. Мини-лаба: потрогай настоящий REST API

# GET к публичному API — увидишь структурированный JSON-ответ (как от контроллера) $ curl -s https://api.github.com/repos/torvalds/linux | head -20 # поля name, owner, stargazers_count... — это и есть «ресурс» через REST # свой публичный IP через API (JSON) — и код ответа $ curl -s https://api.ipify.org?format=json $ curl -s -o /dev/null -w "%{http_code}\n" https://api.github.com # 200 = OK

# то же на Python — три строки, и данные уже структура $ python3 -c "import requests; print(requests.get('https://api.ipify.org?format=json').json())"

Что понять: ты сейчас сделал ровно то, что делает сетевая автоматизация — запросил ресурс по REST и получил JSON, готовый к обработке, без единой строки парсинга «простыни». Отсюда до «GET список VLAN с контроллера» — один шаг.

11. Плейбук: безопасно катить изменение на парк

Прежде чем идти по шагам, договоримся о главном принципе зрелой автоматизации — единый источник правды (source of truth). Желаемое состояние сети живёт в одном месте: конфигурации и переменные — в git, инвентарь устройств (адреса, роли, площадки) — в системе вроде NetBox. Устройство больше не «источник истины», а его отражение: если чей-то ручной хотфикс разошёлся с git, это дрейф конфигурации — его находят регулярным сравнением (diff) и возвращают сеть к описанному состоянию. Без этого принципа автоматизация быстро превращается в генератор сюрпризов: скрипт уверенно катит «правильный» конфиг поверх чужой ночной правки. С ним — каждое изменение проходит один и тот же безопасный конвейер:

Опиши изменение как код и сделай ревью

Правка в git, pull request, второй инженер смотрит diff. Не «на живую в консоли».

Прогони в лабе/симуляции и dry-run

Ansible --check (dry-run) покажет, что изменится, ничего не применяя. Проверь на тестовом устройстве.

Катай волнами (canary), а не всё сразу

Сначала 1–2 устройства → проверил → небольшая группа → весь парк. Так авария не накрывает всё разом.

Держи путь отката

Прошлая версия в git, бэкап конфигов до изменения. Что-то не так — быстрый откат, а не паника.

12. Частые ошибки и вопрос с собеседования

Грабли

1) Парсить CLI-вывод регулярками вместо API → ломается на новой версии IOS. 2) Не использовать dry-run/canary → одна ошибка кладёт весь парк. 3) Хранить пароли/токены в открытом виде в репозитории → утечка (нужны vault/секреты). 4) Забыть про идемпотентность и «слепо» гнать команды → непредсказуемый результат при повторе.

Собеседование: «Зачем API, если всё можно сделать скриптом, который вводит команды по SSH?»

SSH+CLI (Netmiko) — рабочий мост для старых устройств, но он парсит текст, который меняется между версиями, и не даёт структурированного ответа. API (NETCONF/RESTCONF/REST по моделям YANG) возвращает структурированные данные и поддерживает транзакции/откат — это надёжнее, стабильнее и масштабируемее. На практике комбинируют: API где есть, Netmiko где нет.

13. Словарик модуля

Термин	По-английски	Смысл в одну строку
Императивно/декларативно	imperative / declarative	«введи команды» vs «вот желаемое состояние»
Идемпотентность	idempotency	повтор не делает лишних изменений
IaC	infrastructure as code	конфигурация в git: ревью, история, откат
NETCONF/RESTCONF	NETCONF/RESTCONF	API управления конфигом (XML/JSON, модели YANG)
YANG	YANG	модель данных: что у устройства можно читать/менять
REST API	REST	GET/POST/PUT/DELETE поверх HTTP, коды 2xx/4xx/5xx
JSON / YAML / XML	—	форматы структурированных данных
Netmiko / NAPALM	—	Python-библиотеки для CLI/мультивендорной автоматизации
Ansible playbook	playbook	YAML-описание желаемого состояния
SDN / control plane	software-defined networking	«мозг» в контроллере, устройства — пересылка
Southbound/Northbound	—	API контроллера вниз (к железу) и вверх (к приложениям)

1. Скрипт на регулярках, разбирающий вывод show ip int brief, сломался после апгрейда IOS. Как надо было?

Не парсить текст, а брать структурированные данные через API (RESTCONF/NETCONF по YANG) или, если только CLI, — через библиотеки вроде Netmiko/TextFSM с готовыми шаблонами. Текстовый вывод меняется между версиями; API — стабильный контракт. Отсюда правило: «данные для машины — из API, не из глаз».

2. Playbook добавляет VLAN. Его случайно запустили дважды. Что произойдёт при идемпотентности?

Ничего плохого: первый прогон добавит VLAN (changed=1), второй увидит, что он уже есть, и не сделает изменений (changed=0). В этом смысл декларативности — описано желаемое состояние, а не «слепые» команды, которые при повторе могли бы навредить.

3. Нужно раскатать рискованное изменение на 200 устройств. Как минимизировать риск?

Ревью diff в git → dry-run (--check) → тест в лабе → canary (1–2 устройства, потом небольшая группа, потом всё) → держать путь отката (прошлая версия в git, бэкап конфигов). Не «всё разом на живую» — так одна ошибка не кладёт всю сеть.

4. Чем «мозг» в SDN-контроллере отличается от обычной сети, и что такое northbound?

В обычной сети control plane (решения) есть в каждом устройстве; в SDN он вынесен в контроллер с общей картиной, а устройства — только data plane (пересылка). Northbound — это REST API контроллера «вверх», через который приложения/автоматизация управляют всей сетью как единым целым; southbound — «вниз», к устройствам (NETCONF/OpenFlow).

NetDevOps — это два сдвига: от императивного к декларативному («желаемое состояние») и от текста к структурированным данным (API вместо парсинга CLI). Инструменты: API (NETCONF/RESTCONF/REST по YANG), Python (requests/Netmiko/NAPALM), Ansible (идемпотентные playbook'и), SDN-контроллеры и git-based CI/CD. Сеть перестаёт быть «руками по устройствам» и становится кодом.

🎓 Ты прошёл трек уровня CCNA → CCNP

От электрического импульса в кабеле — до автоматизации сети кодом. Ты умеешь считать подсети, поднимать OSPF и BGP, читать дампы, строить услуги оператора, защищать порты, наблюдать за сетью и программировать её. Это фундамент, которого нет у большинства, кто приходит в DevOps «сверху». Дальше — этап II маршрута: DevOps. Он уже проложен: Linux вглубь, Bash/Python, Git, Docker, Nginx и Облако AWS — а твоя сетевая база (VPC, маршрутизация, security groups) станет там суперсилой. Один клик «Продолжить» ждёт на дашборде, а вся карта маршрута — на этапе II. Не забывай про повторение — знания держатся, когда к ним возвращаешься.