Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Как получить доступ к базе данных UniFi, UniFi Network
 
Мне нужен был доступ к UniFi mongodb. Я использую клиент Robomongo, чтобы подключиться к базе данных на порту 27117, но не смог установить соединение с сервером. Мой сервер размещён на DigitalOcean, поэтому у меня нет физического доступа к нему. Какие настройки нужны для доступа к базе? Нужно ли вводить учетные данные для аутентификации? Спасибо за помощь, Джек.
 
Туннель через ssh: ssh -L 27117:127.0.0.1:27117 unifiserver.fqdn  
Затем подключитесь к порту 27117 на вашем локальном компьютере.
 
Извиняюсь за ваш опыт. Желаю удачи с вашими производственными системами. Мне не нужно что-то доказывать вам. Я участвовал во множестве проектов по разработке, планированию развертывания, выполнению тестов, поддержке в продакшене и так далее. Жаль, если мой опыт не совпал с вашим, но из-за этого меня не стоит оскорблять.
 
Я много работал в очень крупных корпоративных средах (читай: свыше полумиллиона рабочих столов и более четверти миллиона физических серверов, на которых размещены миллионы виртуальных инстансов, и более четверти миллиона сотрудников). Сейчас UBNT предлагает выбор: либо использовать экземпляр базы данных, управляемый UniFi-контроллером полностью, либо свой собственный экземпляр БД, который UniFi-контроллер вообще не трогает. Тем, кто не умеет настраивать и управлять MongoDB, лучше выбрать первый вариант. Тем, кто умеет — проблем с вторым не будет. У каждого варианта есть свои плюсы и минусы, и на твоём примере: при первом варианте UniFi запускает и останавливает базу вместе с контроллером. При втором варианте администратор сам должен следить, чтобы БД была всегда запущена, когда это нужно. Для корпоративной среды это должно быть само собой разумеющимся. Если это не так — возможно, первый вариант будет лучше. Учти, что в корпоративных средах MongoDB обычно запускается на отдельной ОС от той, где работает UniFi-контроллер.

Ты хочешь третий вариант, где UniFi контролирует запуск и остановку базы, но при этом полностью оставляет её настройку пользователю? Не уверен, что это сильно полезно при двух уже доступных вариантах. И не представляю, как это могло бы работать, если MongoDB находится на другой ОС — это довольно сложное решение. Если MongoDB запускается локально — на той же ОС, что и UniFi, зачем выходить за рамки полного контроля UniFi? Если нужна настройка — второй вариант отлично справится.

А если те, кто обслуживает систему, не очень заинтересованы в своей работе, им однозначно лучше выбрать первый вариант с полным управлением базы UniFi. Такие люди, исходя из описания, не будут прилагать дополнительные усилия для второго варианта или даже другого варианта, если есть первый.

К слову, современные платформы обычно поддерживают зависимости сервисов. Например, пару строчек в unit-файле systemd на Linux достаточно, чтобы гарантировать запуск локальной MongoDB перед запуском UniFi-контроллера. Это, пожалуй, проще, чем заморачиваться с третьим вариантом в самом UniFi.
 
Не пытайся меня угадать. И не оскорбляй мой интеллект, повторяя то, что видел на чьей-то презентации в PowerPoint. Во многих случаях именно политика в больших корпоративных системах мешает воплотить в жизнь то, что теоретически возможно. Твой комментарий про продвижение из тестовой среды выдает тебя — ты бы удивился, как часто в реальной динамичной среде тестовая цепочка лишь приближённо совпадает с производственной, несмотря на все усилия.
 
В реальной производственной среде никто не будет вручную вводить команды или менять пути к хранилищу базы данных. Всё должно продвигаться из тестовых сред и, желательно, управляться с помощью Chef или другой системы конфигурирования.
 
В устойчивой среде, если UniFi — единственный пользователь MongoDB и он ещё не запущен, нужно иметь возможность указать конфигурационный файл Mongod, чтобы хранилище документов запустилось корректно. В общем, можно предположить, что люди, которые следят за системами, не слишком заинтересованы в том, что делают. Если в инструкции по запуску контроллера unifi написано «запустите базу данных MongoDB с помощью следующей команды...», то разумный системный администратор будет считать, что специалист, отвечающий за поддержку, максимум сделает что-то неправильно или просто проигнорирует/ошибётся при вводе команды.  

В крупной корпоративной среде с высоким уровнем изменений ПО, например, у оператора фиксированной и мобильной связи с тестовым центром, который работает почти весь рабочий день, такая организация софта просто не прошла бы в продакшен. В корпоративном мире надо изначально предполагать, что, когда начинается настоящий бардак, люди будут ошибаться. Это не оптимистично, а совсем наоборот — планируешь самую страшную катастрофу и надеешься, что не слишком пессимистичен.  

Дилберт — это не просто комикс.  
R+C
 
Ну, ты и не смотрел — возможно, Mongod настроен на разрешение нескольких подключений с разных IP, это есть в документации MongoDB. Например — bind_ip = 127.0.0.1,10.8.0.10,192.168.4.24. R+C
 
С решением из того поста конфигурация UniFi указывает на вашу собственную MongoDB, которой вы полностью управляете. Когда вы используете это решение, UniFi отказывается от любого контроля над MongoDB и полностью оставляет это на ваше усмотрение. Вы используете свою собственную инстанцию MongoDB с собственной конфигурацией на ваш выбор, которую запускаете и останавливаете любым удобным для вас способом.

В дальнейшем это даст два варианта: все вместе, когда контроллер UniFi владеет и управляет своей собственной MongoDB, или отдельные контроллер UniFi и MongoDB, которые управляются и настраиваются независимо друг от друга.
 
К сожалению, если взглянуть на то, что позволяет ссылка, которую вы опубликовали, то видно, что, несмотря на множество полезных функций, возможности указать имя и расположение конфигурационного файла MongoDB там нет. Конфигурационные файлы используются для настройки среды MongoDB и её работы. Зачем кому-то настраивать окружение MongoDB через конфигурационный файл UniFi? Это по сути ненадежно. То, что вы опубликовали, — хороший старт... R+C
 
Тебе стоит прочитать ссылку, которую я выложил...
 
Это кажется довольно радикальным. Почему просто не использовать поддерживаемое решение? Потому что это не то, что изначально просили (требовалось корпоративное решение). Всё, что касается настройки инстансов MongoDB, должно быть в соответствующих конфигурационных файлах Mongod/Mongos, потому что в реальной жизни, когда проблемы решают в три часа ночи, люди могут не заметить, что многие команды настройки находятся не в конфигурационном файле Mongod, а в конфигурационном файле UniFi. R+C
 
Это довольно радикально. Почему бы просто не использовать поддерживаемое решение?
 
mongod запускается из процесса контроллера UniFi с аргументом командной строки "--bind_ip 127.0.0.1", который обычно переопределяет значения в конфигурационном файле. Я не знаю, как mongod обрабатывает это, и не могу найти информации об этом при быстром просмотре документации. Ты проверял, что всё работает так, как ты предлагаешь?

Немного покопавшись в настройках, можно подправить конфигурацию. Некоторые перехватывают и обрабатывают любые команды запуска, остановки или изменения настроек, исходящие от UniFi, и подают изменённые команды. Ещё хорошей идеей будет настроить репликацию и запускать другое ПО на реплицированной копии.

У большинства из нас есть доступ к битовым редакторам и дизассемблерам. Всё должно стать проще, когда контроллер изменят так, чтобы MongoDB можно было настраивать отдельно на машине по выбору хозяина. R+C
 
mongod запускается из процесса контроллера Unifi с аргументом командной строки «--bind_ip 127.0.0.1», который обычно переопределяет значения в конфигурационном файле. Я не знаю, как mongod это обрабатывает, и не смог быстро найти подтверждение в документации. Вы проверили, что это работает так, как вы предполагали?
 
Это можно сделать легко и без «бэкапа», потому что это ужасный способ. Не знаю, связано ли это с тем, что в момент написания этого поста robomongo не поддерживал SSH-соединения, но теперь он это умеет. Если у вас контроллер на Linux и он где-то вроде AWS, Linode или DigitalOcean, то всё должно быть понятно.

В Robomongo настройте подключение через SSH. Обязательно укажите пользователя и SSH-ключ*, который вы используете для входа на удалённый сервер.  
Поменяйте порт localhost на 27117, затем протестируйте — и вот, всё работает.  

*В наше время уже не стоит использовать пароли для SSH-аутентификации.
Страницы: 1
Читают тему (гостей: 1)