Представлен (http://linuxcontainers.org/news/) первый стабильный выпуск инструментария LXC 1.0 (http://linuxcontainers.org), официально объявленный пригодным для промышленного применения. В рамках проекта развивает набор инструментов для организации работы изолированных контейнеров, позволяющих изолировать процессы и ресурсы при помощи штатных механизмов ядра Linux, таких как пространства имён (namespaces) и группы управления (cgroups). Поддержка выпуска исправлений для ветки LXC 1.0 будет осуществляться в течение пяти лет.В отличие от технологий виртуализации на основе гипервизоров, контейнеры выполняются под управление единого ядра Linux, без необходимости запуска отдельного ядра и набора драйверов в каждом окружении. По своим возможностям контейнеры занимают нишу между изоляцией при помощи chroot и полноценными средствами виртуализации. В состав инструментария LXC входит библиотека liblxc, набор утилит (lxc-create, lxc-start, lxc-stop, lxc-ls и т.п.), шаблоны для построения контейнеров и набор биндингов для различных языков программирования.
Кроме пространств имён (namespaces), которые используются для изоляции ipc, uts, точек монтирования, идентификаторов процессов и сетевого стека, и cgroups, применяемых для ограничения ресурсов, в LXC также задействованы такие возможности ядра, как профили Apparmor и SELinux, политики Seccomp, Chroots (pivot_root) и capabilities.Ключевые улучшения в LXC 1.0 (подробный обзор с примерами можно найти здесь (https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/)):
- Поддержка полностью непривилегированных контейнеров;
- Стабилизация API (liblxc1) для создания и управления контейнерами;
- Поставка официальных биндингов для использования API в программах на языках python3, lua, ruby и Go;
- Гибкая система размещения контейнеров в различных типах хранилищ. Поддерживается размещение контейнеров в обычном дереве директорий, в ФС btrfs и zfs, в lvm, loop-устройствах, aufs и overlayfs;
- Поддержка клонирования работающих контейнеров и возможность заморозки их состояния через создание снапшотов;
- Сокращенный, но более целостный, набор утилит;
- Обновлённая и полноценная документация;
- Поддержка нескольких методов создания контейнеров на основе недавно сгенерированных образов;
- Поставка шаблонов для создания контейнеров на основе популярных дистрибутивов Linux.
URL: https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-F...
Новость: http://www.opennet.me/opennews/art.shtml?num=39154
Вообще, по-хорошему, речь идет только о наборе юзерспейсных программ, являющихся лишь одним из возможных реализаций интерфейса к ядерным фичам LXC.
Другие реализации - Docker, libvirt-lxc, systemd-nspawn - развиваются гораздо динамичнее.
В любом случае, все равно нужно ждать, пока в ядре окончательно допилят UID namespaces, без этого изоляция получается весьма эфемерной.
А чего конкретно сложно сделать без UID namespaces?
> А чего конкретно сложно сделать без UID namespaces?Без UID namespaces, root из контейнера == root на хосте. Допустим, ФС хоста и сетевой стек и он и не увидит, но есть ряд механизмов никсового IPC, которые игнорируют контейнеры.
Например, если запустить ubuntu в lxc на убунтовом хосте, команда reboot из контейнера перезагружает хост.
А можно подробнее на почитать? Получается, что все эти разговоры про контейнеры, докер, етц - пустой пиар?
> Получается, что все эти разговоры про контейнеры, докер, етц - пустой пиар?Нет, просто LXC-контейнеры (в современном их виде) - не для безопасности, а для более удобного управления ресурсами и приложениями.
Так ведь это так и есть. Для безопасности, допустим, те же сервисов, выставленных наружу, те же cgroups без всяких контейнеров подходят лучше.
> Так ведь это так и есть. Для безопасности, допустим, те же сервисов,
> выставленных наружу, те же cgroups без всяких контейнеров подходят лучше.cgroups - это только компонент контейнера. Таких механизмов, как изоляция точек монтирования, сетевого стека, и т.д. - они не предоставляют.
Но даже в сочетании с namespaces, они все равно (пока) уступают старому доброму OpenVZ.
Зачем моему сервису, крутящемуся на моей машине, изоляция точек монтирования и сетевого стека? Ему нужно всего-то более-менее ограничить ресурсы и более-менее защитить его от проламывания.OpenVZ - это когда я вдруг решу на эту машину пустить зачем-то десяток незнакомых людей с их сервисами. Правда, я и тогда возьму Xen.
> Зачем моему сервису, крутящемуся на моей машине, изоляция точек монтирования и сетевого стека?
> более-менее защитить его от проламывания.this
И?
Дисковой квоты и обрезания прав недостаточно?
> Xen.А нафига? KVM мало?
Медленно. Особенно в районе сети.
> Медленно. Особенно в районе сети.враньё
> Медленно. Особенно в районе сети.Не заметил. Virtio там есть, etc.
Чё только не придумают, лишь бы маны не читать!> и более-менее защитить его от проламывания.
Если ты пишешь на Опеннете, значит твой сервак нахер никому не нужен. :-P
>Без UID namespaces, root из контейнера == root на хосте.Сам проверял, загрузить/выгрузить ядрёный модуль тем (внутренним) рутом не даёт. И reboot хоста не происходит. Ядро ванильное самосборное 3.4 и не Ubuntu.
> Сам проверял, загрузить/выгрузить ядрёный модуль тем (внутренним) рутом не даёт.Это уже давно прикрыли. Но это всего лишь одна из десятков дырочек... все не упомнишь.
> Ядро ванильное самосборное 3.4 и не Ubuntu.
Демка с ребутом основана на особенностях upstart (там для взаимодействия telinit и init используется не сокет, а D-Bus). Тем не менее, суть иллюстрирует довольно неплохо.
> Сам проверял, загрузить/выгрузить ядрёный модуль тем (внутренним) рутом не даёт. И reboot хоста не происходит. Ядро ванильное самосборное 3.4 и не Ubuntu.Ну, если не Ubuntu, могу предложить попробовать поменять системное время в контейнере. Результат должен порадовать :)
> Ну, если не Ubuntu, могу предложить попробовать поменять системное время в контейнере.
> Результат должен порадовать :)На Ubuntu, конечно тоже будет работать, но там есть еще и много других впечатляющих граблей. Но вот прикол со временем - универсальный.
> Например, если запустить ubuntu в lxc на убунтовом хосте, команда reboot из
> контейнера перезагружает хост.Пробовал? :) Или Мойша напел?
Я пробовал. Ubuntu 13.10 32bit.
> Например, если запустить ubuntu в lxc на убунтовом хосте, команда reboot из контейнера перезагружает хост.Что за ересь? Перегружает. Только не хост, а гест.
LXC в 12.04LTS вполне себе работают с самого начала, и ,как минимум, для билдстанций и отладочных нужд - очень экономное решение.
"команда reboot из контейнера перезагружает хост." наверно это только на убунте, на арче такого не происходит.
> Другие реализации - Docker, libvirt-lxc, systemd-nspawn - развиваются гораздо динамичнее.# Создадим контейнер с именем "p1", используя шаблон "ubuntu"
# Войдём в контейнер через консоль (для выхода нужно набрать ctrl-a + q)
# Заморозим состояние контейнера
# Разморозим состояние контейнера
# Пробросим устройства в контейнер
# Создадим снапшот (при размещении контейнера в LVM или Btrfs)
# Откатим состояние на созданный снапшот
# Создадим новый контейнер на основе снапшотаКак?
> Как?Легко. Например, Docker это умел еще полгода назад.
а ты ткни пальчиком, деточка, а то не видно старичку то.
http://docs.docker.io/en/latest/use/Дальше сами осилите, или мне придется еще и учить вас пользоваться браузером?
понятно, ответа нет.
так вот, сабж, в отличие от ваших ссылок, работает.
а там пока только „договор о намерениях“. не говоря уже об экзотичности языка, на котором он написан и сам не стабилизирован.зыж
всех минусующих просто отнесу к тем, кто этот доккер в глаза не видел.
> понятно, ответа нет.Скорее, человек просто лень писать персонально для вас подробное руководство, и он понадеялся, что вы не маленький и умеете пользоваться браузером и бегло читать по-английски.
> так вот, сабж, в отличие от ваших ссылок, работает.
Docker тоже работает, причем давно и успешно.
> Скорее, человек просто лень писать персонально для вас подробное руководствоСкорее вы тролль.
И ни разу не пробовали ни то, ни другое.
Вывод — а напуркуа вы это всё написали?
А как у него с оверхедом, например, по-сравнению с FreeBSD Jail?
Какой оверхед там вообще может быть? Контейнер - это просто совокупность процессов, использующих общие namespaces.
Сам вак ключенных namespace-ов, cgroup-ов и т.п. в ядре даёт overhead-ы.
А уж ядро какие даёт оверхеды! То ли дело bare metal.
> А уж ядро какие даёт оверхеды! То ли дело bare metal.Вы наверное удивитесь, но в разной конфигурации ядро работает с разной скоростью.
> Вы наверное удивитесь, но в разной конфигурации ядро работает с разной скоростью.Поэтому айда програмить в досе, на голом асме. Вот там точно никакого оверхеда.
> Сам вак ключенных namespace-ов, cgroup-ов и т.п. в ядре даёт overhead-ы.Нет.
Не даёт.
Фактически это только куда смотрит как на рут граф.
>> Сам вак ключенных namespace-ов, cgroup-ов и т.п. в ядре даёт overhead-ы.
> Нет.
> Не даёт.
> Фактически это только куда смотрит как на рут граф.Хм, а в документация к ядру и lwn.net думают иначе [1], насколько я помню.
[1] http://lwn.net/Articles/516533/
То есть если вы их включили в ядре, вы уже полчили overhead-ы, вне зависимости от того, используете их или нет.
> Сам вак ключенных namespace-ов, cgroup-ов и т.п. в ядре даёт overhead-ы.Нет. Только отдельные контроллеры cgroups, типа memory. Но их включать не обязательно.
>> Сам вак ключенных namespace-ов, cgroup-ов и т.п. в ядре даёт overhead-ы.
> Нет. Только отдельные контроллеры cgroups, типа memory. Но их включать не обязательно.Давая контейнеру доступ ко всей памяти получается слишком плохая изоляция. Получается что контейнер становится способен вызвать DoS всех сервисов всех соседних контейнеров и хост-системы.
0.93% в среднем
Фантастичная статья - огромное спасибо - долго искал короткое описание, как например есть у зони Соляриса - всего доброго!!!
:)
совсем другой подход в реализации.
Стефан Грабер (Stéphane Graber), в преддверии выхода 20 февраля 2014 года релиза LXC 1.0, опубликовал цикл статей о Linux Containers.
Рассмотрены:
* Первый Ubuntu контейнер.
* Второй контейнер.
* Продвинутое использование контейнера.
* Более углублённое использование контейнера.
* Хранилище контейнеров.
* Безопасность.
* Непривилегированные контейнеры.
* Скрипты и API.
* GUI в контейнере.
* Решение проблем и отладка.
Оригинал https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series
Перевод http://vasilisc.com/lxc-1-0-blog-post-series
>По своим возможностям контейнеры занимают нишу между изоляцией при помощи chrootнамного безопаснее chroot'а?
> намного безопаснее chroot'а?Ощутимо - изолируется не только ФС но и иные неймспейсы, что явно лучше.
Когда игрался на убунте 12.4 обнаружил невозможность ограничить даже размер памяти в контейнере не говоря уж о потреблении проца. Ядро какие-то фичи не поддерживало вроде.
Но самое главное, убунта в контейнере не может обновиться штатными средствами, т к ее скипты при обновлении upstart завершаются с ошибкой и система превращается в нерабочую.
Оказалось проще поставить виртуалку ))
> Когда игрался на убунте 12.4 обнаружил невозможность ограничить даже размер памяти в
> контейнере не говоря уж о потреблении проца. Ядро какие-то фичи неЭто называется resource management. Отсутствует как класс в лине.
И давно оно стало отсутствовать? И у кого присутствует лучше?
Оно просто никогда не было написано.А присутствует дофига где. В Солярис 10, например. Там весьма продвинутый менеджмент ресурсов в контейнерах.
> А присутствует дофига где. В Солярис 10, например. Там весьма продвинутый менеджмент ресурсов в контейнерах.У меня не получилось. Следовательно, в солярке тоже отсутствует как класс :)
> Отсутствует как класс в лине.То-то линем все хостеры ползуются. Что для впсок на опенвзе, что для виртуалок на xen/kvm и прочих облаков.
Нужно пробовать на 14.04, там будет новый LXC 1.0, в 12.04.4 да, всё грустно с ним.
Поставь Linux и бдет тебе счастье.
К.О.
Подозреваю, дебиан тоже не линукс.
На роль домашнего серверо-декстопа (с поддержкой больше 5 лет) не так уж много претендентов.
> Подозреваю, дебиан тоже не линукс.
> На роль домашнего серверо-декстопа (с поддержкой больше 5 лет) не так уж
> много претендентов.В отличие от горбатой убунту, Debian как раз таки один из нормальных представителей Linux семейства.
> В отличие от горбатой убунту, Debian как раз таки один из нормальных
> представителей Linux семейства.Вот только найти 10 отличий между ними не подсматривая в версии софта... :)
> Подозреваю, дебиан тоже не линукс.
> На роль домашнего серверо-декстопа (с поддержкой больше 5 лет) не так уж
> много претендентов.К сожалению, именно у Ubuntu (в частности, из-за особенностей сборки ядра и проблем в архитектуре upstart) очень серьезные противопоказания к работе LXC-хостом.
Используйте Debian, либо CentOS с OpenVZ.
> Когда игрался на убунте 12.4 обнаружил невозможность ограничить даже размер памяти в
> контейнере не говоря уж о потреблении проца. Ядро какие-то фичи не
> поддерживало вроде.Сравнительно старое ядро + особенности убунтовой сборки.
// Сейчас посмотрел конфиг ядра в стабильном дебиане (тоже 3.2) - управление памятью есть.> Но самое главное, убунта в контейнере не может обновиться штатными средствами, т
> к ее скипты при обновлении upstart завершаются с ошибкой и система
> превращается в нерабочую.Особенности национального upstart-а. Он не приспособлен для работы к контейнерах, в отличие от systemd, например. В результате команды управления init-ом из контейнера пытаются ломиться к процессу init хоста, с переменным успехом.
Если у команд управления инитом из контейнера получается убить хост-систему -- такие контейнеры не нужны, не правда ли?
> контейнеры не нyжны, не правда ли?Ну да, сейчас нам бздюки дадут краткий курс использования контейнеров. Правда почему-то все хостинги поголовно на openvz сидят :). Или на виртуалзаторах типа xen и kvm. ИЧСХ там тоже линь. И на вашем десктопе макось. А так то да, бзды хорошие системы. Если ими пользоваться чисто на поиграться и забыть.
>> контейнеры не нyжны, не правда ли?
> Ну да, сейчас нам бздюки дадут краткий курс использования контейнеров.Заканчивай истерику и внимательно перечитай вопрос, на который отвечаешь.
Каким образом получается, что сигнал из контейнера вообще доходит до PID 1?
Правда почему-то
> все хостинги поголовно на openvz сидят :). Или на виртуалзаторах типа
> xen и kvm.Аг, вот мы как раз Linux и используем как хорошую запускалку виртуальных машин :-) другого применения не находится. Так что тут соглашусь.
> Каким образом получается, что сигнал из контейнера вообще доходит до PID 1?Интимные особенности работы апстарта, сигнал приезжает "неожиданным" маршрутом который не удавили (dbus).
> Аг, вот мы как раз Linux и используем как хорошую запускалку виртуальных машин :-)
Странно что не hyper-v, было бы прикольнее смотреть как бы вы этот кактус грызли.
> другого применения не находится.
Ну а что что с проприераса взять? Он фапает на бзду но грузится в макось или максималку, знаем мы это дело. Ну или вот линь на виртуализаторе. Потому что toy OS и на виртуализатор не тянет.
>> Каким образом получается, что сигнал из контейнера вообще доходит до PID 1?
> Интимные особенности работы апстарта, сигнал приезжает "неожиданным" маршрутом который
> не удавили (dbus)Причем тут вообще апстарт??? Каким образом userland-приложение стало причиной того, что ядро ниасилило заглушить посланный тз контейнера сигнал? Тебе самому не смешно?
>> Аг, вот мы как раз Linux и используем как хорошую запускалку виртуальных машин :-)
> Странно что не hyper-v, было бы прикольнее смотреть как бы вы этот
> кактус грызли.Я смотрю, богатый опыт у анонима в пожирании кактусов.
>> другого применения не находится.
> Ну а что что с проприераса взять? Он фапает на бзду но
> грузится в макось или максималку, знаем мы это дело. Ну или
> вот линь на виртуализаторе. Потому что toy OS и на виртуализатор
> не тянет.Я уже неоднократно писал тут, какие мы продукты делаем на базе бзды, продолжайте прятать голову в песок :-)
Ну не видели люди SmartOS с нормальными Zones.
> Ну не видели люди SmartOS с нормальными Zones.Кому было сильно надо - сто лет юзают OpenVZ в продакшне. Ну и виртуалки вот. А zones - они где? Много на них продакшнов у хостеров? Ну вот и...
Вот бы ещё эти контейнеры могли использовать KSM. 20 запущенных контейнеров сожрали 14 гигов.
Кстати пробовал ядро с UKSM, хрень полная... не работает.
Ну, не просто так его до сих пор в ядро не включили :)
KSM+KVM/QEMU хотя бы реальный эффект дают..
> Вот бы ещё эти контейнеры могли использовать KSM.Не секурно. Да и память нынче дешева.