Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
Зачем запускать UniFi Controller в Docker?, UniFi Network
 
Каковы плюсы и минусы запуска Linux-версии UniFi Controller в контейнере Docker? Я слышал, что переход с одной версии контроллера на новую проще с Docker, но у меня есть скрипт обновления контроллера, который позволяет просто указать новый URL для загрузки, а дальше он всё сделает сам: скачает новую версию, выключит сервис контроллера, создаст бэкап данных старой версии, установит новую и запустит сервис снова. Так в чём же преимущества и недостатки запуска UniFi Controller в Docker?
 
Я запускаю контроллер UniFi на виртуальной машине Linux Mint на ESXI в корпоративной среде. Виртуальный жёсткий диск на 16 ГБ, оперативная память 2 ГБ. На самом деле его даже можно установить на Raspberry Pi.
 
Смотрите это: https://community.ui.com/questions/292b1974-6bb9-48a9-bf8f-51d657c07500. Мой личный опыт таков: я хотел выделить больше памяти контроллеру через файл config.properties, используя значение unifi.xmx=4096. Вот руководство по настройке: https://help.ubnt.com/hc/en-us/articles/115005159588-UniFi-How-to-Tune-the-Controller-for-High-Number-of-UniFi-Devices. Но докер-образ просто игнорировал эту настройку. Поэтому я перешёл с запуска Docker на Qnap ;-) на виртуальную машину Ubuntu, работающую на Virtualization Station от Qnap. Там всё работает. Надо сказать, что у меня нет глубоких знаний о Docker — я просто скачал готовый докер-образ.
 
Да, ты абсолютно прав.

@osunifi

… для первого поста — это довольно смело сказать, так что я не воспринимал это легкомысленно и не хотел создавать неправильное впечатление. Уверен, ты прав, что это отличное место, чтобы учиться и участвовать (я на это надеюсь). К сожалению, такое слишком часто встречается в интернете: люди не оказывают друг другу того уважения, какое были бы обязаны проявлять при личном общении. Вежливое напоминание никому не повредит😉

Можешь, пожалуйста, подробнее рассказать, в чём именно устройство работало не так, как должно, а также когда и какую версию образа ты использовал? Мне интересно, так как у меня уже есть QNAP NAS, работающий круглосуточно, и я подумываю попробовать вариант с Docker.
 
Эээ... Привет, Lemondixon, довольно представительный вступительный пост у тебя. И все же — добро пожаловать! :-) Ну, я тоже ошибаюсь, и если ошибаюсь, меня кто-то более опытный поправляет. Я вижу, что здесь в основном очень открытое и отзывчивое сообщество. Как и в реальной жизни — порой даже у опытного участника настроение бывает не из лучших, и он может потерять терпение и написать что-то не слишком уважительно. Да, я тоже пробовал Docker, и было бы круто, если бы он официально поддерживался. Но у меня опыт с доступными образами был такой: контроллер вёл себя не всегда так, как должен.
 
Я пришёл сюда в поисках полезной информации, и благодаря стараниям @ypu и @levicki я её получил.

Для тех из нас, кто не настолько опытен и осведомлён (и я в их числе), очень неприятно заходить в сообщество или форум, где люди не могут просто выразить своё мнение, не подвергнувшись при этом жёсткой атаке от тех, кто с ними не согласен — особенно когда эти агрессоры позиционируют себя как «Старшие участники». Какой посыл это даёт? «Даже не думай высказывать свои мысли или что-то добавить сюда, если ты не знаешь всего о предмете и не готов к оскорблениям в любом случае!» Ммм, не слишком похоже на дух обмена знаниями ради интереса и сотрудничества с людьми, разделяющими твои увлечения, правда? Люди обычно больше учатся там, где бывают здоровые и уважительные разногласия; но большинство уходит из мест, где чувствует себя запуганными, даже если у них есть что-то действительно ценное, что они могли бы поделиться (возможно, чего не знаешь и ты). В итоге все теряют (и ты тоже). Вот досада.
 
Короткий ответ: из-за тебя. Создать docker-образ для среднего специалиста по телекоммуникациям в миллион раз проще, чем по отдельности устанавливать все нужные пакеты Linux и настраивать их, что потребовало бы знаний системного администратора Linux.
 
зевота
 
Рад, что ты умеешь читать, но очевидно, что ты не работаешь с виртуальными машинами или Docker, раз даже основы и их преимущества тебе непонятны. Я просто хотел уберечь других от путаницы, а вместо этого ты решил только усугубить ситуацию, копая себе яму вместо того, чтобы выбраться из неё. Я не устраиваю баталии в интернете, так что не собираюсь тратить время на объяснения для тебя. Удачи, дружище. П.С. Эта часть — просто моя мелочная придирка. Очевидно, что у тебя есть какое-то понимание Docker. Если бы я оставил это, то противоречил бы своему вышеупомянутому комментарию про «клавиатурного воина».
 
Они точно этого не делают. Есть tarball, и даже самый младший системный администратор спокойно может взять его и использовать на любой unix-подобной системе с Java. Поиск по форумам здесь покажет вам такие компании. Некоторые компании очень строго придерживаются своих политик. Тот самый tarball, о котором вы говорите, поставляется без поддержки от Ubiquity, в отличие от Debian-пакета. Другая проблема — сам Java. Множество приложений (например, онлайн-банкинг для бизнеса от голландских банков) требует конкретной версии Java, что может вызвать конфликты, если пытаться запустить всё это на одной машине. Тут на помощь и приходит что-то вроде Docker. Лично я вообще не считаю нынешнюю ситуацию проблемой. Как вы и сказали, запускаешь tarball — и делаешь всё сам. Не должно возникать проблем.

Docker не является операционно-системно независимым. Docker работает от ядра базовой системы. Вы распространяете много дезинформации для тех, кто в этом не разбирается. Пожалуйста, прекратите.

@ypu

Твой пост заставляет меня корчиться от количества дезинформации. Может, тебе лучше просто удалить его? Если кому и нужно удалять посты, так это тебе. Ты вкладываешь слова в мои уста и читаешь в моих словах то, чего там нет — это оскорбляет и, скорее всего, нарушает правила форума.

Нигде я не говорил, что Docker независим от ОС, я чётко сказал, что на данный момент (!) он работает на Linux, OS X и Windows. Поскольку существует больше операционных систем, чем эти три, должно быть понятно, что Docker не является ОС-независимым. Если посмотреть на Linux, то Red Hat, CentOS, SUSE, Debian и другие его поддерживают. Если же посмотреть на системы, которые поддерживает Ubiquity для контроллера, то это только Debian. Посчитайте сами.

Docker работает только от ядра базовой системы, когда запускается на Linux. В OS X и Windows он использует гипервизор ОС, то есть добавляет ещё один уровень (в OS X раньше использовался VirtualBox, теперь — Hypervisor Framework OS X). Вот вам и дезинформация...

Кстати, от людей, работающих с такими продвинутыми устройствами, как у Ubiquity, ожидаешь, что они будут изучать вопросы, если с чем-то не знакомы. Это очень просто, ведь документация по Docker у нас очень подробная.

Разве запуск Docker на виртуальной машине не сводит на нет его основное назначение и не нивелирует преимущества контейнеров перед виртуальными машинами в плане производительности?

Виртуализацию используют для инфраструктуры, а контейнеры — для приложений. Свою инфраструктуру можно запускать на bare metal, а можно и использовать облачных провайдеров (например, Amazon) — что больше подходит по требованиям и бюджету. Когда у тебя смешанная среда (контейнеры и простые ВМ), логично использовать одну и ту же инфраструктуру и для контейнеров, и для всего остального.

Docker (и контейнеризация в целом) — это не про производительность, а про простоту развертывания приложений, гарантию, что они просто заработают, и возможность делать это снова и снова. Вам действительно стоит прочитать «Что такое Docker?» и посмотреть на него с точки зрения приложений. В итоге именно разработчик приложения получает основную выгоду от таких инструментов, как Docker (в данном случае — Ubiquity).
 
Сейчас я разбираюсь с Azure, который тоже невероятно мощный. Там много чего нравится, но документация просто ужасная. Microsoft постоянно добавляет новый функционал, который ломает то, что ты только что настроил; если честно, это меня реально бесит, но мне всё это обошлось по цене, которой не перебьёшь, к сожалению. Microsoft отвечает за мой Exchange-сервер, и это здорово, но есть столько проблем, что даже топ-менеджеры MS не знают, как их решить. После одного обновления Windows 10 мне даже пришлось покупать новые лицензии для рабочих станций и переустанавливать всё (потом вернули деньги). Крупные облачные провайдеры, кто бы они ни были, видимо, тащат слишком много проблем. Это бесполезно — выпускать новые версии быстрее, чем успевают сделать документацию и справочные материалы. Даже обучающие видео просто устарели. R+C
 
Это очень классная система, но, честно говоря, документация от Google по ней просто отвратительная и в некоторых местах даже неправильная. Мой сетевой специалист потратил кучу времени и сил, чтобы во всём разобраться (к тому же у него есть хороший друг из команды разработчиков Google...), но теперь, когда всё настроено, мы можем позволить себе потерять ноду, диск или что угодно, и обычно даже не замечаем этого, пока не заглянем в сам кластер. Было несколько случаев, когда из-за сбоя с питанием нода выпадала, а мы и не догадывались, пока не проверяли, какие ВМ работают на каких нодах... Джим
 
Очень круто. Обязательно подробнее изучу Ganeti. Спасибо, что уделили время и ответили.
 
Вот в чем прелесть Ganeti (это то, что Google разработал и построил для своей инфраструктуры, если вы не знаете) — всё дублируется по всему кластеру. Диск есть на каждом отдельном узле кластера, и он автоматически синхронизируется в реальном времени между дисками и узлами. Мы используем серверы DL380 с двумя зеркальными жесткими дисками для нативной ОС и с 5+1 HS 148MB дисками в RAID5 на каждом узле, в сумме получается более 500 ГБ на узел, и каждый узел синхронизируется и делится данными по всему кластеру. Так что нам не нужен внешний SAN или что-то вроде того. Если бы нам действительно понадобилась огромная система хранения данных, я просто взял бы какой-нибудь внешний системный массив, в зависимости от задачи, подключил к нескольким узлам и позволил системе зеркалировать данные там. Для репликации баз данных лучше подходит отдельная мастер-слейв репликация в реальном времени с помощью самой базы данных. Мы раньше строили большие массивы, подключая через iSCSI или Fibre Channel, в зависимости от нужд. Даже использовали программный RAID там, где важна была скорость чтения, а не записи, например, на крупных зеркальных сайтах — kernel.org построен именно так. Ещё одна классная вещь в Ganeti — оборудование на узлах может отличаться друг от друга. То есть можно настроить кластер из больших и маленьких узлов по CPU, RAM и дискам, а система сама разберётся, где и как запускать и хранить данные. Узлы даже могут находиться в разных местах, хотя тогда ограничением становится пропускная способность соединения... Jim
 
@eejimm

Просто интересно, какие решения для хранения данных ты используешь. Всегда удивляло, почему у многих людей есть избыточные коммутаторы, избыточные маршрутизаторы, кластеры виртуальных машин, а когда дело доходит до SAN, они ставят один контроллер SAN с 15 HDD в RAID и при этом игнорируют, что контроллер SAN — это единственная точка отказа. Они настолько надежные, что на это не обращают внимания, или я чего-то не понимаю?
 
Разве запуск Docker внутри виртуальной машины не сводит на нет его изначальную задачу и не отменяет преимущество производительности контейнеров приложений по сравнению с контейнерами ОС? Да, но мы пытаемся запускать всё в нашем кластере Ganeti — для нас надежность важнее производительности. Когда мы пробовали запустить UCRM таким образом, он не заработал, потому что кластер настроен на паравиртуализацию, а не на полную эмуляцию. Много людей регулярно используют виртуальные машины для своих систем, ведь сейчас действительно быстрое железо стоит совсем недорого. Я могу купить полностью укомплектованный сервер HP Gen6 меньше чем за $500, который без проблем потянет всё, что нужно нашему провайдеру... Джим Понятно.
 
Разве запуск Docker на виртуальной машине не сводит на нет её основное предназначение и не нивелирует преимущества по производительности использования контейнеров приложений по сравнению с ОС-контейнерами? Да, верно, но мы стараемся запускать всё в нашем кластере Ganeti — надёжность для нас важнее производительности. И когда мы попробовали UCRM именно так, оно не сработало, потому что кластер настроен на паравиртуализацию, а не полноценную эмуляцию. Многие люди регулярно используют виртуальные машины для своих систем, ведь сейчас действительно мощное железо стоит копейки. Я могу купить полностью укомплектованный сервер HP Gen6 менее чем за 500 долларов, и он спокойно потянет всё, что нужно нашему провайдеру… Джим
 
Разве запуск Docker на виртуальной машине не сводит на нет его изначальную задачу и не нивелирует преимущества в производительности контейнеров приложений по сравнению с контейнерами ОС?
 
У Docker есть и другие проблемы — он может отказывать в работе на определённых типах виртуальных машин (в зависимости от конкретного метода виртуализации) и прочее. Однако он даёт разработчикам относительно простой контейнер для распространения приложения и в некоторых моментах справляется лучше таких вещей, как Java, когда нужно сделать систему по принципу «напиши один раз — запускай везде», особенно с точки зрения производительности.  
Jim
 
Docker не является независимым от ОС. Docker работает на базе ядра системы. Ты путаешь людей, которые в этом не разбираются, рассказывая столько неверной информации. Пожалуйста, прекрати.

@ypu

Твой пост заставляет меня испытывать стыд из-за такого количества неточностей. Может, тебе просто стоит его удалить.
Страницы: 1 2 След.
Читают тему (гостей: 1)