Комментарии 12
Приветствую.
Не планируете ли вы зарелизить Racks для community? Это было бы интересным решением для многих.
Мы тоже смотрим в сторону Netbox, но ему не хватает еще многих вещей, не смотря на наличие некоторого количества плагинов.
Не рассматривали ли вы Device42, они и 10 лет назад были хороши, а сейчас стали еще лучше, но не хватает возможности писать свои плагины (или плохо смотрел)
Так же Netbox недавно форкнули те, кто спонсировал его разработку и параллельно активно пишут на его базе Nautobot с упором на автоматизацию и configuration management (например, там очень интересный плагин https://github.com/nautobot/nautobot-plugin-golden-config) И мы сейчас в раздумьях, стоит ли их рассматривать или нет.
Еще отмечу, что только у D42 красиво и удобно решен вопрос с cables/patch panels, всеми соединениями и прочим, почему мы их и использовали (не 10 лет назад, соврал, лет 7): https://docs.device42.com/connectivity/patch-panels/patch-panel-cable-management-definitions-and-legends-2/
Пока не планировали. Всё таки система заточена под нашу инфраструктуру и имеет много специфичных штук
А что конкретно? Netbox последнее время очень динамично развивается за счет увеличения команды и, вероятно, соперничества с Nautobot (мультитенантность, поддержка плагинов, preferences, journal entries ...)
Мы как раз уехали от D42 в сторону Netbox по причине того, что нам не подошли многие вещи. Однако, это мощный инструмент автодискаверинга и если вас устраивает такой подход к учету оборудования, то D42 может подойти.
Жаль. Был бы весьма неплохой игрок на рынке, кругом очень много bloatware.
Ну, например, банальных BGP/Tunnels всяких видов. BGP plugin есть от нашего соотечественника, небольшой. Tunnels тоже был, но не развивается. В команде у них, такое ощущение, один Jeremy, от него только коммиты и релизы.
Ну вот да, он как бы всякое умеет, но шаг в сторону - и уже ничего не сделаешь. Поэтому смотрим на него сейчас, но как-то не очень уверены, стоит ли. Нам как раз автодискаверинг особо не нужен.
Была, конечно, и ложка дегтя. У NetBox – слишком медленный API для больших объемов данных, которые у нас были. Загрузка информации по серверным со всем оборудованием занимала непростительно большое количество времени. К счастью, нам удалось обойти это ограничение.
-------------
Интересно узнать, как вы это обошли
Основной проблемой было получение больших объемов данных сервером Racks. К примеру, загрузка комнаты с несколькими сотнями стоек, заполненных оборудованием. В дополнение к медленной загрузке множества объектов добавлялись классические проблемы REST вроде 1+N.
Такие весомые трудности вынудили нас использовать "запрещённый приём". Мы открыли серверу Racks read-only доступ к базе NetBox и написали модуль с готовыми сложными SQL запросами и методы API для их запуска и параметризирования.
Проблемы этого решения очевидны:
При обновлении NetBox зачастую приходится обновлять код нашего модуля в Racks
Появляется бэкдор в базу NetBox. Хотя доступ только RO и организован безопасно, но сам факт не особо приятен.
Зато прирост в скорости получился колоссальный. Доли секунды против десятков секунд для API запросов.
Мы очень ждем NetBox 3.0, в котором обещают ввести GraphQL API. Надеемся, это позволит значительно увеличить скорость получения данных "законным" путём.
Кстати, сегодня вышла beta Netbox 3.0 с переработанным интерфейсом и GraphQL API)
я уже было подумал, что в конце будет какой-то source code , но нет
красиво описано, но как роман Толстого - прочел и забыл
DCIM-платформа Racks: почему мы отказались от энтерпрайз-решения в пользу самописного приложения