Настройка NetBox для CMDB и управления инфраструктурой

Мы не раз сталкивались с ситуацией, когда spreadsheet с IP-адресами, который «все знают», в какой-то момент перестаёт работать. Кто-то выдал 10.20.30.50 новому серверу, не зная, что этот адрес уже занят. Кто-то не обновил документ после переезда оборудования. Terraform пытается создать ресурс с адресом, который уже есть в DNS, — и падает. NetBox решает эту проблему: единственный источник истины для IP-адресации, инвентаря оборудования, кабельной документации и связи между сетевыми объектами. За 5 лет работы мы внедрили NetBox на более чем 20 проектах — от небольших стартапов до enterprise с тысячами устройств.

Почему NetBox лучше обычных таблиц?

Таблицы не обеспечивают целостности ссылок: один инженер меняет IP, другой не видит обновления. NetBox использует реляционную модель: Prefix → IP Address → Interface → Device → Site. Любое изменение сразу видно всем, а API исключает ручные ошибки. Сравните: ручная проверка конфликтов IP в таблице занимает 10–30 минут, NetBox делает это за секунды.

Как мы настраиваем NetBox под ключ?

Мы берём на себя полный цикл: от развёртывания до обучения команды.

Развёртывание и первичная настройка

NetBox устанавливается через Docker или напрямую на Linux. Docker-вариант проще в обслуживании:

# docker-compose.yml (фрагмент)
services:
  netbox:
    image: netboxcommunity/netbox:v3.7
    environment:
      - DB_HOST=postgres
      - DB_NAME=netbox
      - DB_USER=netbox
      - DB_PASSWORD=${DB_PASSWORD}
      - SECRET_KEY=${SECRET_KEY}
      - ALLOWED_HOSTS=netbox.internal
    volumes:
      - ./config/configuration.py:/etc/netbox/config/configuration.py
    depends_on:
      - postgres
      - redis

В configuration.py важно прописать ALLOWED_HOSTS, настроить LDAP/SSO если нужна интеграция с Active Directory, и определить REMOTE_AUTH_BACKEND для SSO через SAML или OAuth2. Без этого пользователи создаются вручную — в проде так не работают.

Структура данных: от физики к логике

NetBox моделирует инфраструктуру слоями. Физический уровень: Sites → Racks → Devices. Логический: IP Address → Prefix → VRF → RIR. Связь между ними: у устройства есть Interfaces, у интерфейса — IP-адрес из конкретного Prefix.

Для новой инфраструктуры порядок такой: создаём Site, добавляем Rack (с указанием высоты юнитов), регистрируем Device Types (можно импортировать из официальной библиотеки netbox-community/devicetype-library). Device Types — это шаблоны: указывает какие интерфейсы, блоки питания и слоты есть у конкретной модели сервера. При создании Device из типа все компоненты создаются автоматически.

Для IP-адресации: создаём RIR (RFC 1918 для приватного), добавляем Aggregates (10.0.0.0/8), разбиваем на Prefixes по назначению — /24 для каждого VLAN. При выдаче адреса через UI или API NetBox сам выбирает следующий свободный в указанном Prefix.

API как основной инструмент интеграции

Ценность NetBox не в красивом UI, а в REST API и Python SDK. Пример через pynetbox:

import pynetbox
nb = pynetbox.api('https://netbox.internal', token='abc123...')

# Найти следующий свободный IP в prefix
prefix = nb.ipam.prefixes.get(prefix='10.20.30.0/24')
next_ip = prefix.available_ips.create()
print(next_ip)  # {'address': '10.20.30.12/24', 'family': 4}

# Зарегистрировать новый сервер
device = nb.dcim.devices.create(
    name='node-07',
    device_type=nb.dcim.device_types.get(model='PowerEdge R640').id,
    site=nb.dcim.sites.get(slug='dc-main').id,
    device_role=nb.dcim.device_roles.get(slug='server').id,
    status='active'
)

Этот код вызывается из Ansible playbook при провижининге нового сервера — IP выдаётся автоматически, хост регистрируется в CMDB, и дальше Terraform или другие инструменты читают инфраструктуру из NetBox как источника правды.

Динамический инвентарь Ansible через NetBox:

# inventory/netbox.yml
plugin: netbox.netbox.nb_inventory
api_endpoint: https://netbox.internal
token: "{{ lookup('env', 'NETBOX_TOKEN') }}"
group_by:
  - device_roles
  - sites
  - tags

ansible-inventory -i inventory/netbox.yml --list вернёт все устройства со статусом active, сгруппированные по ролям и сайтам.

Кастомные поля и webhooks

Для специфичных атрибутов (например, номер заявки на закупку, ответственный инженер, дата истечения warranty) используются Custom Fields — добавляются через UI или API без изменения схемы БД.

Webhooks позволяют реагировать на события: при создании нового IP-адреса можно отправить POST-запрос в Ansible AWX для запуска playbook, или в JIRA для создания задачи. Настраивается через NetBox → Customization → Webhooks:

{ "name": "New IP → AWX", "type_create": true, "object_type": "ipam.ipaddress", "url": "https://awx.internal/api/v2/job_templates/42/launch/", "http_method": "POST", "http_content_type": "application/json", "secret": "webhook-secret" } 

Что входит в работу?

• Базовое развёртывание: Docker-инфраструктура, LDAP/SSO, настройка резервного копирования.
• Импорт данных: перенос существующей IP-адресации, устройств, соединений (скрипты или ручной ввод).
• Интеграции: Ansible (динамический инвентарь), Terraform (data sources), webhooks для CI/CD.
• Документация: описание модели данных, инструкции для команды, runbook типовых операций.
• Обучение: 2–3 сессии для администраторов и разработчиков.
• Поддержка: 1 месяц пост-релизной поддержки.

Сроки и стоимость

Базовое развёртывание с Docker, настройка LDAP, импорт Device Types — 2–3 рабочих дня. Заполнение существующей инфраструктуры (IP-адресация, устройства, стойки) зависит от объёма: 50–100 устройств вручную или через скрипт импорта — ещё 2–5 дней. Интеграция с Ansible, Terraform, настройка webhooks — отдельный блок от 1 до 3 дней в зависимости от количества интеграций. Стоимость рассчитывается индивидуально после аудита. Оценим проект — свяжитесь с нами.