Ми не раз стикалися з ситуацією, коли 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 робить це за секунди.
| Критерій | Google Sheets | NetBox |
|---|---|---|
| Цілісність даних | Ні (ручне узгодження) | Так (реляційна БД, транзакції) |
| API / автоматизація | Ні | REST API, Python SDK, Webhooks |
| RBAC / аудит | Ні | Так (ролі, історія змін) |
| Пошук конфліктів IP | Ручний, 10–30 хв | Автоматичний, <1 сек |
Як ми налаштовуємо 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"
}| Тип події | Дія | Приклад інтеграції |
|---|---|---|
| IP створено | Запуск playbook Ansible | AWX, Tower |
| Змінено site | Синхронізація DNS | Ansible, Terraform |
| Пристрій виведено | Сповіщення в Slack | Webhook → Slack |
Що входить в роботу?
- Базове розгортання: 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 днів залежно від кількості інтеграцій. Вартість розраховується індивідуально після аудиту. Оцінимо проєкт — зв'яжіться з нами.
