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

http://docker.io

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А по тестам, кто кого? Диск/цпу/сеть

Не столько тесты, сколько аналитика, но - http://www.janoszen.com/2013/01/22/lxc-vs-openvz/

И еще

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

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

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

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

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

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

да, это надстройка над lxc, и она уже почти готова к продакшену

Спасибо, посмотрю. Ее вроде в яндексе используют в кокаине?

Определенно плохое решение

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

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

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

А apparmor или SElinux разве не поможет?

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

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

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

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

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

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

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

На новых ядрах можно использовать 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).

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

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

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

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

Я тоже почти уже выбрал lxc, по дороге ещё планирую глянуть docker.

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

А для каких целей, расскажи?

docker

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

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

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

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

Подскажите, есть ещё варианты?

jail(8)

lxc

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

kvm

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

kvm

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

kvm

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

kvm

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

kvm!

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

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

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

jail(8)

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

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

Так и есть

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

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

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

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

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

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

kvm!

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

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

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

man qcow2, man writeback/writethrough.

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

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

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

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

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

Забыл уточнить что хост - 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).

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

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

XEN в контейнере? Это вообще как?