LINUX.ORG.RU
ФорумAdmin

Контейнерная виртуализация

 , , ,


3

3

В дополнение к топику про виртуализацию вообще хочу спросить про контейнеры.
Скажите что выбрать под не особо нагруженные виртуалки lamp/RoR/Django/Tomcat? Изолироваться от соседа не так критично с точки зрения безопасности.

Пока выбор стоит между OpenVZ vs LXC.
Подскажите, есть ещё варианты?

★★★

По моему опыту использования, OpenVZ более приспособлен для использования в production, нежели LXC. При этом, LXC я использую для тестовых сред, в том числе на ноутбуке или рабочей станции - все его компоненты включены в upstream ядро, в отличие от OpenVZ (для которого нужно загружать патченное ядро от OpenVZ).

Как следствие из последней причины, я бы использовал RHEL-based дистрибутивы (Центось та же), ввиду того, что VZ-ядра нативно пилятся на основе RHEL-ядер.

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

Это же надстройка над lxc, не?

Верно + она еще не готова серьезно, о чем docker'овцы и говорят прямо.

Опять же - для тестовых сред - пойдет, для production я бы постремался.

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

все его компоненты включены в upstream ядро, в отличие от OpenVZ

Тогда большой плюс LXC, а в чем его менее продакшенность?

для тестовых сред - пойдет, для production я бы постремался

Это полупродакшн.

Тогда lxc пока более лучший выбор. А по тестам, кто кого? Диск/цпу/сеть

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

Тогда большой плюс LXC

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

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

а в чем его менее продакшенность?

Говорят, он не такой допиленный.

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

Вот за эту ссыль огромное спасибо!

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

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

IMHO в lxc с сетью все хорошо. Можно отдать целиком девайс, можно vlan с девайса, можно через veth либо p2p либо в мост.

CPU не жрет, а с диском - в зависимости от того, что ему отдашь.

Но ядра нужно иметь свежие, а не 2.6.30 и сам lxc из git, а не релиз 0.90.

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

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

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

Тогда большой плюс LXC, а в чем его менее продакшенность?

Изоляция у контейнеров слабая. Не всё ещё заизолировали. Если в контейнер предполагается пускать потенциальных вредителей (например организовать хостинг VPSок или запускать какой-то совсем уж левый софт) то LXC пока не годится. Но его пилят.

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

Яндекс не пускает в свои кокаиновые облака посторонних (хотя вроде собирается). Да и кокаиновая нода это всё-таки не VPS, там клиент сильнее ограничен.
К тому-же можно предположить что у яндекса есть специалисты которые точно знают в чём LXC ещё не готов, могут подстелить соломки и подкостылить где нужно.

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

Понятия не имею. Не удивлюсь если контейнерный root сможет поменять себе метки SElinux наложенные на него из хостовой системы и тогда толку от этого SElinux будет ноль.

В любом случае такие самопальные связки это явно не прадакшын рэди.

OpenVZ используется давно и хорошо протестирован. Ставишь по хаутушечке с официального сайта и получаешь гарантированно неплохой уровень безопасности. Хотя это и не спортивно.

MrClon ★★★★★
()

Вообще, емнип, я где-то читал, что большая часть LXC основана как раз-таки на коде OpenVZ. Но, так как в LXC пока включено далеко не всё, ибо не весь код считается готовым для Upstream Kernel, OpenVZ всё равно пока ещё нужен. И в новых ядрах OpenVZ там, где это возможно, использует код LXC, уже включённый в ядро, а для ещё не реализованных фич — свой патченный.

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

Ого как интересно!
А опыт работы с openvz мне поможет в понимании lxc и наоборот?

Типа знание кишков lxc/openvz
Или использование одинаковых скриптов,команд управления

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

Юзерспейсные управляющие тулзы у них таки разные.

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

На новых ядрах можно использовать vzctl для создания контейнеров lxc, но функционал далеко не полон и частично коряв, например:

Software that depend on information supplied by the proc filesystem may not work correctly, since there is not a full solution for full /proc virtualization. For instance, /proc/stat is not yet virtualized, and top will show distorted values.

Вот ещё небольшая статья про OpenVZ и LXC.

In the future (another eight years? who knows...) OpenVZ kernel functionality will probably be fully upstream, so it will just be a set of tools.

OpenVZ is essentially LXC++, because it adds some more stuff that are not (yet) available in the upstream kernel (such as stronger isolation, better resource accounting, plus some auxiliary ones like ploop).

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

lxc - это больше чем chroot. контейнеры друг друга не видят.

vel ★★★★★
()

Я выбрал LXC и пока ни разу не пожалел. Даже на вполне нагруженном проекте за 100 тыс. тяжёлых хитов в сутки на контейнер.

Контейнеры легко создаются, не требуют особого ядра, могут пользоваться общим свопом, могут для корневой системы использовать хоть отдельный каталог, хоть отдельный том в lvm и т.п. При всём этом оверхед совершенно незаметен.

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

интересно, положил в ридер группу в жж. Спасибо

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

docker

Тот же LXC, только меньше ручной работы.

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

Если только ОЧЕНЬ глубокий опыт, с ковырянием подсистем ведра.

А так да, parallels на всех углах кричит что они пытаются засунуть в апстрим всё что могут ибо их хаит тянуть свой форк.
Но присунуть в апстрим им дают далеко не всё и вообще сношают мозг и обзывают «various mad Russians».
В общем их фичи пока неготовы для ванильного ядра (слишком кривые), а ванильное ядро пока неготово для их управляющих тулзов (слишком нефичастое). Такая вот драма.

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

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

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

Контейнеры легко создаются

kvm

не требуют особого ядра

kvm

могут пользоваться общим свопом

kvm

могут для корневой системы использовать хоть отдельный каталог, хоть отдельный том в lvm

kvm

При всём этом оверхед совершенно незаметен.

kvm!

Так ты назовешь преимущества-то? =D

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

Вот крайне годная статья от одного из разработчиков.

Точнее жалкие отмазки неудачников.

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

jail(8)

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

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

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

Так и есть

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

KVM уже использую для домашних виртуалок. Хочется что-то полегче

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

Kvm и контейнеры - вещи немного разные, ты же понимаешь это

Прекрасно понимаю. Мне просто попридераться хочется, такой вот вредный у меня характер.

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

При всём этом оверхед совершенно незаметен.

kvm!

А у тебя есть тесты? Мне казалось что kvm очень сильно проседал по диску по сравнению с нативной записью.

Я тестировал kvm-виртуалку в файле и lvm-разделе
Оба раза было медленнее чем нативно, правда было это давно...

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

Мне казалось что kvm очень сильно проседал по диску по сравнению с нативной записью.

man qcow2, man writeback/writethrough.

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

Почитал. Итого - мы записываем в кеш, а потом медлееенно записываем на диск.
Выглядит как костыль.
На хост машине такое тоже можно реализовать?

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

На любой фс, которая умеет copy-on-write.

Выглядит как костыль.

Это очень распространенная практика, так работает огромное кол-во софта. И сам линукс в том числе.

tazhate ★★★★★
()

Контейнер LXC с убунтой 13.10 полностью влияет на upstart хост-машины. Эта хрень, при выключении виртуалки вырубила мне хост-машину (тоже 13.10). Нафиг такое счастье.

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

Забыл уточнить что хост - linux ^_^

Давай так: на хосте заводишь LXC, там внотре Linux, туда пихаешь XEN, далее запускаешь его и внутри устанавливаешь FreeBSD, а уже в ней делаешь Jail с linux_base-f10 (порт emulators/linux_base-f10), linux-sun-jdk17 7.45 (порт java/linux-sun-jdk17) и tomcat7 7.0.47 (порт www/tomcat7).

Я думаю, что взлетит. Заодно и изучишь свойства контейнерной виртуализации (изоляции) по полной программе.

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

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

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