Доступен (https://lists.linuxcontainers.org/pipermail/lxc-users/2016-A...) релиз инструментария для организации работы изолированных контейнеров LXC 2.0 (http://linuxcontainers.org), который отнесён в выпускам с длительной поддержкой, обновления для которых формируются в течение 5 лет. Одновременно подготовлен релиз виртуальной ФС LXCFS (https://linuxcontainers.org/lxcfs/), предназначенной для симуляции /proc и /sys/fs/cgroup в контейнерах. Готовые пакеты c LXC подготовлены для Ubuntu Linux (https://launchpad.net/ubuntu/+source/lxc).В состав инструментария LXC входит библиотека liblxc, набор утилит (lxc-create, lxc-start, lxc-stop, lxc-ls и т.п.), шаблоны для построения контейнеров и набор биндингов для различных языков программирования. Изоляция осуществляется при помощи штатных механизмов ядра Linux. Для изоляции процессов, сетевого стека ipc, uts и точек монтирования используется механизм пространств имён (namespaces). Для ограничения ресурсов применяются cgroups. Для понижения привилегий и ограничения доступа задействованы такие возможности ядра, как профили Apparmor и SELinux, политики Seccomp, Chroots (pivot_root) и capabilities.
Ключевые изменения (https://linuxcontainers.org/lxc/news/):
- Все основные команды lxc переписаны на языке Си;
- Добавлена новая команда lxc-copy, которая сочетает возможности lxc-clone и lxc-start-ephemeral;
- Значительно улучшена поддержка механизма CRIU (http://criu.org/) для сохранения состояния контейнеров с последующей возможностью возобновить работу с сохранённой позиции;
- Полностью переработаны средства обработки cgroup, добавлена поддержка пространств имён cgroup;
- Внесены улучшения в утилиты командной строки. В lxc-clone добавлена поддержка переименования контейнеров. В lxc-start-ephemeral обеспечена возможность изменения точек bind-монтирования. В lxc-attach задействованы промежуточные устройства pts для защиты от атак против родительского shell;- Реорганизована реализация бэкенда работы с хранилищами, добавлен новый бэкенд для ФС Ceph;
- Добавлены шаблоны для ALT Linux, Slackware и SPARCLinux;
- Реализован новый cgroup-бэкенд cgfsng, который добавлен в список рекомендованных бэкендов;
- Сохранена совместимость C API с прошлыми выпусками 1.x, API присвоен номер версии 1.2.URL: https://linuxcontainers.org/lxc/news/
Новость: http://www.opennet.me/opennews/art.shtml?num=44210
сижу сейчас на проксмоксе 3.4 и контейнерах опенвз.
кто-то уже мигрировал на LXC, как оно?на хабре есть статейка с печальными выводами:
https://habrahabr.ru/post/278877/
> на хабре есть статейка с печальными выводами:Судя по тому, что ни с какими из этих проблем я и близко не столкнулся под Ubuntu и Gentoo, это проблема дистрибутива того автора.
Учитывая, что тот автор использует тупо банальные Debian и CentOS...
>> на хабре есть статейка с печальными выводами:
> Судя по тому, что ни с какими из этих проблем я и
> близко не столкнулся под Ubuntu и Gentoo, это проблема дистрибутива того
> автора.Да именно так и есть - проблема сугубо с 4 проксмоксом...
И сугубо с чисто ванильным Debian Jessie.
да, только проблема не в ванильном дебиане.
ядро там от убунту, а все пакеты для виртуализации они сами компилят из апстрима.
> да, только проблема не в ванильном дебиане.
> ядро там от убунту, а все пакеты для виртуализации они сами компилят
> из апстрима.Лолшто? В Proxmox ядро от Убунту?
Proxmox VE 4.xThe current stable 4.x release uses latest Ubuntu based kernel, which will be regularly updated. The first stable 4.0 release is based on 4.2 Linux kernel.
лол да
Пропал Калабуховский дом ... :(
Есть еще вариант, что у кого-то контейнеры исчисляются тысячами и находятся под нагрузкой, а у другого баловство на локалхосте.
Буквально месяц назад тестировали 4 проксмокс - еще ппц какой сырой. Для продакшена противопоказанно...
Ого, жесть какая. Не знал о таких проблемах в Proxmox 4.X, а как там KVM поживают в новой версии, нормально?
> Ого, жесть какая. Не знал о таких проблемах в Proxmox 4.X, а
> как там KVM поживают в новой версии, нормально?Нормально. Но проблемы не в proxmox. На обычном дебиане я то же самое получал - зависающие намертво контейнеры.
Автор того поста неадекват. Упёршийся в древний ovz и не способный выполнить даже минимальный анализ проблемы.
> Автор того поста неадекват. Упёршийся в древний ovz и не способный выполнить
> даже минимальный анализ проблемы.Вообще-то автор писал про lxc.
Держу мелкий хостинг для разрабов gocloud.ru - вроде норм
Приходится тянуть с Github'а и собирать руками - тогда работает нормально. Ядро я тоже использую кастомное (накатываю патчи BFQ+UKSM+ck на ванильное), поэтому LXC мне лучше подходит, ибо в мэйнлайне и community-driven.
Десяток серверов, БД и php/nginx. По сотне сайтов на каждом.На основании этого, могу точно сказать - хаброавтор не выпрямляет руки по утрам.
на proxmox или на чистом debian/ubuntu ?
> Все основные команды lxc переписаны на языке Си;Ну хоть где-то вменяемые люди, а не хипстеры спешно переписывающие в очередной раз, с питона на go или с go на rust.
То есть выбирать оптимальный язык под текущую задачу это невменяемость и хипстерство?
> оптимальный язык"оптимальный язык" для низкоуровневого софта уровня lxc - это C. Выбор руби или го - да, невменяемость.
На этапе поиска верной архитектуры выбор скриптового языка вполне оправдан, так как позволяет во много раз сократить время разработки. Когда архитектура устаканилась, то можно и переписать на более быстром языке.
Интересно, а какие аргументы против Go. Сможешь ли назвать правильный или ограничишься вариацией "я его не знаю и чтобы скрыть свое невежество навешу на него ярлык хипстерского". Вот против С в пользу Go для таких инструментов всегда есть соображения безопасности.
Адепт java и C# ?
Оба раза мимо, но ты старайся, тебе повезет.
Уважаемые, которые используют скажите LXC уже можно полноценно использовать?
зависит от задач
> Уважаемые, которые используют скажите LXC уже можно полноценно использовать?как уже написали зависит от задач, сам по себе LXC на центосе показывает неплохо для определенных целей. А вот с коробочным proxmox 4 (а также судя по коментам и с чистым дебианом на котором он основывается ) при тонком конфигурировании и нагрузкой всплывает куча траблов.
LXC более чем готов для продакшена. Канешна есть нюансы , но вцелом уже давно очень стабильно.
> LXC более чем готов для продакшена. Канешна есть нюансы , но вцелом
> уже давно очень стабильно.Продакшен бывает разный) Но для простых задач под centos вел себя более менее адекватно...
Кто сидит на проксмоксе есть смысл посидеть пока на 3 версии с openvz.
И хост из контейнера уже не положить и не взломать?
> И хост из контейнера уже не положить и не взломать?Таких решений в принципе нет, даже для полной виртуализации.
Старая рекомендация, не давай рута в контейнере, актуальна и для lxc.
То бишь для задач хостинга, где рут часто дается, не годится совершенно. Не удивительно, что большинство юзает openvz, в котором принципиально нерешаемую проблему давным давно решили.
> То бишь для задач хостинга, где рут часто дается, не годится совершенно.
> Не удивительно, что большинство юзает openvz, в котором принципиально нерешаемую проблему
> давным давно решили.+1
Без рута внутри, lxc как chroot, даже linux-vserver смотрится лучше
> То бишь для задач хостинга, где рут часто дается, не годится совершенно.
> Не удивительно, что большинство юзает openvz, в котором принципиально нерешаемую проблему
> давным давно решили.Для задач хостинга нужно часто давать контейнерам рутовый доступ к системе? Зачем?
>> И хост из контейнера уже не положить и не взломать?
> Таких решений в принципе нет, даже для полной виртуализации.
> Старая рекомендация, не давай рута в контейнере, актуальна и для lxc.Блин, а я хотел спросить на счет рута, но думал это было когда версия была 0.x, думал что в 2 это уже решили. Да еу тонда нафиг этот lxc
Гитлер о контейнерах - https://www.youtube.com/watch?v=PivpCKEiQOQ
Очень верно всё подмечено :-)
>Все основные команды lxc переписаны на языке Си;А были на чём ?
>>Все основные команды lxc переписаны на языке Си;
> А были на чём ?Bash