Компьютерные сети
Автоматизация сети
Facebook управляет сетью из 300000 устройств командой из ~20 сетевых инженеров. Как? Они не настраивают устройства - они пишут код, который это делает.
- **Netflix** использует Python и NAPALM для управления сетью datacenter'ов. Изменения проходят через code review как обычный код.
- **LinkedIn** с помощью Ansible развёртывает конфигурации на 5000+ сетевых устройств за минуты. Раньше это занимало дни.
- **Cloudflare** автоматизирует настройку 300+ edge locations. Новая точка присутствия поднимается автоматически по push в Git.
Предварительные знания
Network Automation
**Network Automation** - это замена ручной настройки сети через CLI на программное управление. Вместо того чтобы заходить на каждый роутер и вводить команды, мы описываем желаемое состояние сети в коде и применяем его автоматически.
Почему это важно? Сеть из 10 устройств можно настроить руками. Сеть из 1000 устройств - нельзя. Ручная настройка = ошибки, drift конфигураций, часы даунтайма при изменениях. Автоматизация = consistency, скорость, auditability.
**Три принципа IaC для сетей**: 1) **Declarative** - описываем 'что хотим', не 'как сделать'. 2) **Idempotent** - повторное применение не меняет уже правильное состояние. 3) **Version controlled** - конфигурация в Git, code review, rollback.
Инструменты: **Ansible** (agentless, SSH/NETCONF), **Terraform** (cloud и некоторые сетевые vendor'ы), **Nornir** (Python framework), **NAPALM** (network device abstraction). Для CI/CD: GitLab CI, Jenkins, GitHub Actions.
Почему idempotency важна для network automation?
NETCONF Protocol
**NETCONF** (Network Configuration Protocol) - стандартный протокол для программного управления сетевыми устройствами. В отличие от CLI (текстовый вывод, screen scraping), NETCONF использует структурированный XML и транзакции.
NETCONF работает поверх SSH (порт 830) и предоставляет операции: **get** (чтение состояния), **get-config** (чтение конфигурации), **edit-config** (изменение), **copy-config**, **delete-config**, **lock/unlock** (транзакционность).
**Datastores в NETCONF**: **running** - текущая активная конфигурация, **candidate** - staged изменения (можно откатить до commit), **startup** - конфигурация после перезагрузки. Это как Git staging area для сетевых устройств.
Какое преимущество NETCONF перед SSH/CLI для автоматизации?
YANG Data Models
**YANG** (Yet Another Next Generation) - язык моделирования данных для сетевых конфигураций. YANG определяет структуру, типы данных и constraints для NETCONF/RESTCONF. Это как JSON Schema, но для сетевого оборудования.
YANG модели бывают: **IETF стандартные** (ietf-interfaces, ietf-routing - vendor-agnostic), **OpenConfig** (от Google и др. - унифицированные для multi-vendor), **Vendor-specific** (cisco-ios-xe, juniper-junos - проприетарные фичи).
**OpenConfig vs Vendor YANG**: OpenConfig - попытка создать единый API для всех вендоров (Cisco, Juniper, Arista поддерживают). Но vendor-specific модели полнее - содержат все фичи устройства. Компромисс: OpenConfig для общего + vendor YANG для специфики.
Зачем нужны YANG модели если есть NETCONF?
Ansible for Network
**Ansible** - самый популярный инструмент для network automation. Agentless (не нужен агент на устройствах), работает через SSH или NETCONF, декларативные playbook'и в YAML. Модули для Cisco, Juniper, Arista, F5 и десятков других вендоров.
Архитектура: **Inventory** (список устройств), **Playbook** (что делать), **Roles** (переиспользуемые наборы tasks), **Modules** (network_cli, netconf, ios_config и т.д.). Для сетей используются специальные connection plugins: network_cli, netconf, httpapi.
**Resource modules** (cisco.ios.ios_interfaces, ios_vlans, ios_acls) - современный подход: desired state, idempotent, можно сравнивать с running config. **Config modules** (ios_config) - legacy: отправляют команды как в CLI, менее предсказуемы.
Network automation требует агентов на сетевых устройствах
Ansible и большинство инструментов agentless - работают через SSH, NETCONF или API
Сетевые устройства обычно закрыты (embedded OS) - установить агент нельзя или сложно. Поэтому сетевая автоматизация исторически agentless. Ansible подключается к устройству, выполняет команды и отключается.
Что делает параметр state: merged в Ansible network module?
Итоги
- **Network Automation** - замена ручного CLI на Infrastructure as Code. Декларативно, идемпотентно, версионируемо
- **NETCONF** - стандартный протокол с XML и транзакциями. Datastores: running, candidate, startup
- **YANG** - язык моделирования схемы данных. OpenConfig для multi-vendor, vendor YANG для специфики
- **Ansible** - agentless automation через SSH/NETCONF. Resource modules (ios_interfaces) для declarative state
- **Workflow**: Git → CI/CD → Ansible → NETCONF → Devices. Изменения как код, rollback через Git revert
Связанные темы
Network Automation связывает сети с DevOps практиками:
- SDN — SDN контроллер - это программный API для сети. Автоматизация может управлять через него
- Cloud Networking — Cloud сети (VPC, Security Groups) изначально управляются через API/Terraform
Вопросы для размышления
- Какие задачи в вашей сети выполняются вручную и могли бы быть автоматизированы?
- Как бы вы организовали rollback если автоматизация сломала сеть?
- Какие риски несёт автоматизация? Как их минимизировать (staging, canary, dry-run)?