LINUX.ORG.RU
ФорумAdmin

Чем Docker принципиально лучше OpenVZ?

 ,


1

4

Много работал с OpenVZ, всё очень устраивало, включая производительность. Не устраивала главным образом необходимость патчинга ядра Linux, поскольку это сильно ограничивало возможности работы с капризным железом или даже просто какими-то современными ядрёными технологиями. То есть ну не слишком здорово то, что с OpenVZ можно работать только на ограниченном множестве версий Linux'ячих ядер.

Но в целом, повторюсь, OpenVZ оставил самое положительное впечатление, позволяя и бэкапы делать просто и безболезненно, и миграции между физическими машинами на случай отказа оборудования, и многое-многое другое. Плюс конечно тот факт, что не менее замечательный Proxmox поддерживает OpenVZ из коробки - не может не радовать.

Теперь Docker.

Вроде бы те же контейнеры, по сути являющиеся развитием jail/chroot, как и OpenVZ, как и LXC.

Почему сразу к этим контейнерам привязали «сбоку» основное их назначение - поставка ПО со всеми зависимостями а-ля «квази-статическая сборка». То есть вроде как Docker позволяет успешно бороться с проблемой, которую сами же Linux'оиды и создали: катастрофическим хаосом, бардаком и зоопарком из библиотек, валяющихся во всяких там /usr/lib'ах

А ещё у Docker есть забавная штука commit - пока я посто не врубаюсь, в чём соль и как оно работает, а вывод команды mount внутри контейнера начисто взрывает мозг.

Ну ОК. А с точки зрения, гм, виртуализации в контексте «создания изолированных программных сред» (клинически ненавижу слово «облако») что конкретно нового, интересного даёт нам Docker по сравнению со старым-добрым OpenVZ?

Пока я вижу одно определённое преимущество: образы Docker меньше образов OpenVZ.

А ещё???

★★★★★

Последнее исправление: DRVTiny (всего исправлений: 1)

А ещё у Docker есть забавная штука commit - пока я посто не врубаюсь, в чём соль и как оно работает

вносит изменения в образ файловой системы контейнера в соответствии с текущим инстансом
это когда в контейнере изменил конфиг и хочешь чтобы это осталось навсегда, а не только пока контейнер жив

anonymous
()
Ответ на: комментарий от melkor217

А контейнеры умеют «замораживаться»? И правильно ли я понимаю, что приложение внутри контейнера должно использовать некие монтируемые внутрь контейнера внешние файловые ресурсы?

Ну то есть приложение внутри контейнера должно как-то осознавать, что за часть якобы доступной ему для записи файловой системы - на самом деле аналог файловой системы для livecd, где менять-то можно всё, что угодно, но жить оно будет «одноразово».

DRVTiny ★★★★★
() автор топика

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

Deleted
()
Ответ на: комментарий от DRVTiny

Вернее, так:

Работающий контейнер Docker с точки зрения ядра - наверняка это просто процесс.

Скорее всего, его можно остановить либо сигналом, либо понижением приоритета до «фонового», после чего там внутри ни регистр указателя кода не переместится ни на байт.

Но вот... память процесса как бы сохранить ещё?

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от Deleted

Вот честно - бизнесу по**р на подобные соображения.

Б: Бесплатный OpenVZ?

И: Да!

Б: Ограничения есть принципиальные?

И: Ну, вот, тут ядро только определённой версии надо...

Б: А для работы томкатика с быдлоявакодом это важно?

И: Нет, не особо.

Б: Значит, ок, нам подходит!

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от DRVTiny

Так я делаю touch /etc/NOTHING, контейнер останавливаю, запускаю - файл на месте...

это если stop/start, то да
а если rm/run, то все пропадет без коммита

anonymous
()
Ответ на: комментарий от Deleted

Думаю, Docker взлетел именно на идее «поставки приложений».

Parallels просто не догадался продвигать OpenVZ в таком контексте.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Ммм... А зачем мне его rm/run???

Настроечные переменные чтобы передать другие? У меня просто под рукой пример с контейнером для OpenLDAP'а, там точно параметры передаются.

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от DRVTiny

Бизнесу как раз не по**р, так как он учитывает все важные факторы. И задротить с ядрами нужной версии никто особо не любит. Ты конечно можешь использовать хоть Win95 в своей мегаконторе «Рога и копыта», но поезд уехал и глобально ничто не изменится. Даже тугодумы с некрософта это поняли и отвалили докеравцам кучу денег для интеграции с шиндовсом.

Deleted
()

я конечно не эксперт в вопросе виртуализации

но докер это переизобретенные контейнеры

там есть свои менеджер пакетов

в контейнере ничего нет

openvz это вроде недовиртуалка

umren ★★★★★
()
Ответ на: комментарий от Deleted

И задротить с ядрами нужной версии никто особо не любит.

Ну в общем да, есть такое. Странно, что OpenVZ чудо-патч свой не пропихнули в ядро. Вон даже гигантскую мусорную свалку от Android туда «слили».

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

А зачем мне его rm/run???

а ты ребут сервера не делаешь, и электричество у тебя не отключается?
если нужно такой же контейнер развернуть на другом сервере, то тоже измененный образ пригодится

anonymous
()

То есть вроде как Docker позволяет успешно бороться с проблемой, которую сами же Linux'оиды и создали: катастрофическим хаосом, бардаком и зоопарком из библиотек, валяющихся во всяких там /usr/lib'ах

С этой проблемой успешно борется менеджер пакетов любого современного дистрибутива. А докер эту проблему усугубляет и прячет под ковёр 8).

Deleted
()

там где есть завязки за поделия потера ничего хорошего быть не может

anonymous
()
Ответ на: комментарий от anonymous

а если rm/run, то все пропадет без коммита

rm — удалить контейнер, run — создать контейнер. После удаления старого и создания нового контейнера, старые данные пропадают. Странно, не правда ли?

anonymous
()
Ответ на: комментарий от anonymous

Давай ты исчезнешь отсюда, и не будет дезинформировать людей.

anonymous
()
Ответ на: комментарий от DRVTiny

Ммм... А зачем мне его rm/run???

Контейнеры по своей идее не персистентные. Персистентность можно добавить с помощью labels (монтируешь хостовые файлы или директории внутрь контейнера). Если например ты захочешь обновить софт в контейнере, ты создашь новый image, удалишь старый контейнер, запустишь новый.

commit создает новый image с текущего состояния твоего контейнера.

staseg ★★★★★
()
Ответ на: комментарий от anonymous

нет, не странно, но бывает нужно потом новый контейнер создать с исправленным конфигом в предыдущем контейнере
хотя бы на случай тюнинга контейнера на одном хосте, а потом полученную конфигурацию развертывать на других хостах

anonymous
()
Ответ на: комментарий от anonymous

rm — удалить контейнер, run — создать контейнер. После удаления старого и создания нового контейнера, старые данные пропадают. Странно, не правда ли?

Интересно, что я подумал же об этом, но постеснялся спросить - вдруг чего-то не понимаю (тема как раз об этом: я только начинаю копать docker)

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

Работающий контейнер Docker с точки зрения ядра - наверняка это просто процесс.

Все контейнерные технологии используют схожие/одинаковые (со стремлением к последнему) механизмы для изоляции. С точки зрения ядра запущенный Docker-контейнер это в том числе и pid namespace. С произвольным количеством процессов внутри.

melkor217 ★★★★★
()
Ответ на: комментарий от anonymous

но бывает нужно потом новый контейнер создать с исправленным конфигом в предыдущем контейнере

Так просто перепаковать «контейнер» - и дело с концом?

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от melkor217

А Вы не в курсе, можно все pid'ы стопануть, например, отправив сигнал pid'у верхнего уровня? (у которого в /proc/pid/cmdline - docker с параметрами). И можно ли сгрести в файл содержимое оперативной памяти контейнера?

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

вон хороший пример выше был — апдейт пакетов в контейнере; давай меняй руками :)

anonymous
()
Ответ на: комментарий от Deleted

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

да блин, где он взлетел то, кроме кучи маркетоидных статей. а, ну еще в тестинге всяких вебных прилажух. там временем опенвз есть на всех хостингах уже очень давно, его даже не надо так пиарить, как этот самый докер.

stave ★★★★★
()
Ответ на: комментарий от stave

Есть мнение, что вы со своим опоннентом сравниваете инструменты для разных задач.

melkor217 ★★★★★
()
Ответ на: комментарий от stave

да блин, где он взлетел то, кроме кучи маркетоидных статей

Приехали. Где не плюнь, даже дистрибутивы выпускают уже в докеровском формате, не говоря уже про приложения.

опенвз есть на всех хостингах уже очень давно

На территории бывшего совка онли разве что. И нафиг не нужно, потому что разница c kvm/xen копейки, а возможности уже совсем другие.

Deleted
()
Ответ на: комментарий от Deleted

>> да блин, где он взлетел то, кроме кучи маркетоидных статей

> Где не плюнь, даже дистрибутивы выпускают уже в докеровском формате, не говоря уже про приложения.

Ого, для докера делают образы. Это, бесспорно, аргумент за «взлетел» :)

melkor217 ★★★★★
()

Docker отстой.

Работал с ним не раз - проблемы ловились на каждом чихе.

Грубо говоря: docker что то вроде «портабел программ», то есть его задача(и задумка) обмен какой либо «программой» ради презентации. А в качестве какого либо сервиса(не он конечно может выступать в качестве полноценного сервера) с точки зрения администрирования и поддержания не пригоден.

А вот показать что и как может функционировать как «демо» очень и очень кстати.

beta9092
()
Ответ на: Docker отстой. от beta9092

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

staseg ★★★★★
()
Последнее исправление: staseg (всего исправлений: 1)

Чем Docker принципиально лучше OpenVZ?

Ничем. Просто сильно разрекламированная технология. Большинство образов не проверены. В плане эксплуатации ничем не отличается от обычной полноценной ВМ.

King_Carlo ★★★★★
()
Ответ на: комментарий от DRVTiny

Странно, что OpenVZ чудо-патч свой не пропихнули в ядро.

Они достаточно много пропихнули в ядро. Современный vzctl работает с современными обычными ядрами. Правда, с некоторым набором ограничений.

AS ★★★★★
()
Ответ на: комментарий от Deleted

И нафиг не нужно, потому что разница c kvm/xen копейки

Между OpenVZ и kvm/xen копейки ?? Ну-ну.

AS ★★★★★
()

Небольшая справка

Docker это надстройка (со свистелками и мерделкама) над LXC, а LXC пилят авторы OpenVZ/Virtuozzo из Parallels которые затрахались патчить и поддерживать свои ядра. Поэтому потихоньку продавливают все фишки в мейнстрим. С точки зрения зрелости и фичастости с OpenVZ нет равных, но дато Docker у всех на слуху (ОЧЕНЬ МОЩЩЩЬЬЬНЫЙЙЙ ПИАР!!!), и не очень та он готов. Кстати Doker не все фичи LXC использует, насколько я помню.

А если в двух словах докер это распаренное гавно. И до докера всё это было. Вобщем это как было с Руби лет 5 назад.

itn ★★★
()
Ответ на: комментарий от staseg

типа того ;) всё футуристично и практично как всегда только на презентации(словах). а реализация в живую доставляет=)

beta9092
()
Ответ на: Небольшая справка от itn

Да, кстати самое главное отличие докера от остальных, что он пропагандирует философию запуска Одного процесса на контейнер, в отличии от остальных контейнеровозов.

itn ★★★
()
Ответ на: комментарий от melkor217

Да, CRIU тоже нашёл. К docker'у отношения не имеет, но докер тоже поддерживает CRIU. И это хорошо :)

DRVTiny ★★★★★
() автор топика
6 июля 2016 г.

Это просто не для админов, а для девопов. Рвет все что было на рынке из-за своего апи, т.б. возможностью управлять этой инфрастукторой програмно как угодно. Разрабы деплой пишут и развивают в виде кода, а деплой стал частью сборки проектов.

exsulem
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.