LINUX.ORG.RU

LXC 2.0

 ,


1

5

Разработчики рады объявить о выпуске новой стабильной версии системы для создания Linux-контейнеров LXC 2.0. LXC 2.0 — это результат года работы сообщества LXC, который включает в себя более чем 700 изменений, сделанных более чем 90 участниками. Это второй релиз с долгосрочной поддержкой (5 лет исправлений ошибок и уязвимостей, релизы при накоплении достаточного количества изменений).

Из нового:

  • Инструменты LXC стали более единообразными в использовании.
  • Улучшена поддержка создания контрольных точек и восстановления из них.
  • Полностью переработан код поддержки CGroup, включая поддержку пространства имён в CGroup.
  • Произведена чистка подсистемы хранения данных, добавлена поддержка Ceph RBD.
  • Огромное количество исправлений ошибок.
  • При всем этом, удалось избежать несовместимых изменений API, так что LXC 2.0 полностью API-совместима с LXC 1.0.

>>> Подробности

★★★★★

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

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

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

ну, это ведь серверная ос с docker'ом. или там что-то поменялось, и они и теперь и пользовательское окружение предоставляют, как qubes ?

DawnCaster ★★
()

Странно, что еще никто не написал: ненужно от слова совсем, так как есть Docker. «system containers» на которые якобы «заточен» LXC настраиваются в докере за 5 мин.

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

https://www.qubes-os.org Не уверен, что там именно LXC, так как руки ещё не дошли как следует по-разбираться с ней.

Ну если судить по faq, то там xen гипервизор и vm, а не контейнеры.

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

ненужно от слова совсем, так как есть Docker. «system containers» на которые якобы «заточен» LXC настраиваются в докере за 5 мин

А ничего что докер лишь надстройка над lxc?

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

это ведь серверная ос с docker'ом. или там что-то поменялось, и они и теперь и пользовательское окружение предоставляют, как qubes ?

Как бы серверные приложения тоже пользовательские, только без ui :)
Если php, *sql, nginx в своих контейнерах крутятся, то уже мило.

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

А ничего что докер лишь надстройка над lxc?

Это как бы уже давно не так.

Docker умеет работать без LXC? Или он настолько толстая настройка, что уже даже и не надстройка?

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

очевидно docker работает через jail

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

А ничего что докер лишь надстройка над lxc?

Нет, ничего. Потому что докер не использует LXC, так как с незапамятных времен общается напрямую с ядром.

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

Настройка сети вообще-то стоит несколько в стороне от основных фишек контейнеризации.

Решение в лоб:

1) пробрасываешь необходимые порты на хост (-p 2222:22 ... ну ты понял) 2) вывешиваешь порты с хоста наружу как душе заблагорассудится используя любые проверенные временем сетевые решения, которые знать не знают про контейнеры и прочую новомодную лабуду

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

Настройка сети вообще-то стоит несколько в стороне от основных фишек контейнеризации.

Твой мозг похитили пришельцы.

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

Странно, что еще никто не написал: ненужно от слова совсем, так как есть Docker.

Удивительно, что никто не сказал, что не нужен шуруповёрт, раз есть перфоратор.

Docker и LXC используются для контейнеризации и могут выполнять похоже задачи. Но они не заменяют, а дополняют друг друга. Нормальные люди используют и то, и другое и даже часто на одних и тех же серверах.

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

Ну и какая же из фич контейнеров больше всего к сети относится: cgroups/неймспейсы (читай умный шаринг ресурсов машины), или многослойные ФС?

В чем ты видишь ключевую разницу между настройкой сети для контейнеров и настройкой сети для виртуальных машин?

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

шуруповёрт, раз есть перфоратор

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

В линукс-контейнерах сейчас Docker vs все остальные - это Слон vs стая Мосек.

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

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

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

Начнём с того, что физический бридж указывается напрямую демону и может быть только один.
Т.е. я не могу создать сеть со своим бриджом, если дефолтная с docker0. А в дефолтную сеть нельзя руками назанчать ip контейнерам.
Ну, т.е. если можно - круто, да.
Но я метода не нашел.
Т.е. в рамках его концепции это и не нужно, но тестировать что-то без жОской сковозной интеграции этого самого докера уже не так удобно.

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

более-менее полноценная ОС

Вообще-то под это определение можно вообще что угодно подогнать. Емакс - это тоже «более-менее полноценная ОС», даже оффтопик - «более-менее полноценная ОС». Что здесь критерий «полноценности», Карл?

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

К сожалению (точнее к счастью) настройкой сетей каждождневно не занимаюсь, поэтому помочь не смогу. Но буду очень сильно удивлен если твой кейз ну совсем никак нельзя реализовать с Докером (и при этом он не висит в багтрекере). По опыту сетевой настройки - я обычно сталкивался с тем что у требуемого кейза есть 100500 вариантов решения различной кривости и задачей было выбрать наименее кривой.

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

Система инициализации, система журналирования, куча конфигов в /etc, служебных утилит и библиотек не связанных напрямую с приложением. Может-быть даже cron и sshd.

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

«system containers» на которые якобы «заточен» LXC настраиваются в докере за 5 мин.

Только после любого обращения в IRC или список рассылки по любому вопросу с такими docker-контейнерами вас польют грязью и пошлют подальше. С LXC таких проблем нет.

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

А ничего что докер лишь надстройка над lxc?

Это давно не так. Docker является надстройкой над libcontainer.

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

В чём преимущество LXC над machinectl?

Работа под дистрибутивами, где systemd не является обязательным компонентом

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

Вменяемое представление ресурсов сделали?

Да, через LXCFS (если имеется в виду «контейнер, при взгляде на себя изнутри, должен в top показывать выделенный ему объем ОЗУ»)

AEP ★★★★★
()

А оно уже научилось нормально работать? Можно его в продакшн? А то почитав на хабре про залипающие контейнеры, которые убить можно только кнопкой ресет на сервере, как-то напрягаешься... https://habrahabr.ru/post/278877/

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

Странно, что еще никто не написал: ненужно от слова совсем, так как есть Docker

да и сам докер не особо нужен

gray ★★★★★
()

Что такое «контейнер»? Это каталог куда складываются все файлы программы? Тогда, как быть с классической идеологией FHS? Смутно помню, вроде что-то такое об этом говорил Поттеринг.

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

В линукс-контейнерах сейчас

То же самое, что и всегда. Есть OVZ, вечно недоделаные LXC, и docker для мальчиков в обтягивающих штанишках.

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

теперь заживём.

Сам по себе lxc достаточно тупой инструмент, считай что это «набор башси-скриптов». Если что-то глючит то смотри настройки системы (фаервол, например).

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

Даже руками файл скачивал? Контрольная сумма совпадает?

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

Информационные технологии отличаются гораздо большей гибкостью инструментов.

https://ru.wikipedia.org/wiki/Гипербола_(риторика)

В линукс-контейнерах сейчас Docker vs все остальные - это Слон vs стая Мосек.

Только в руках неопытного пользователя или только при наличии узкой специфики задач.

У Docker оверхед на дисковых операциях по сравнению с LXC большой и Docker не может автоматом работать с файловыми системами на отдельных разделах. Поэтому, если требуется высокопроизводительная отдельная эмуляция виртуального компьютера — то LXC лучший выбор, чем Docker. Docker же рулит там, где требуется масса однотипных решений или когда требуется распространять готовое, работающее «из коробки» решения.

Задачи, которые решают Docker и LXC — очень разные по своей сути. Хотя, конечно, можно все задачи LXC решить через Docker и все задачи Docker'а — через LXC. Но это будет забивание шурупов пассатижами.

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

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

Если в lxc запустить полноценный init, который стартанёт всю остальную систему, то будет примерно полноценная ОС. А если запустить статически скомиленный bash, то будет контейнер с шеллом и не более.

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

В чём преимущество LXC над machinectl?

machinectl управляет «машинами» независимо от технологии, будь то lxc, docker, kvm или какой-нибудь pflask. Если же сравнивать lxc и systemd-nspawn, то

Note that even though these security precautions are taken systemd-nspawn is not suitable for secure container setups.

К тому же оно не умеет (и не будет уметь) непривилегированные контейнеры.

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

machinectl управляет «машинами» независимо от технологии, будь то lxc, docker, kvm или какой-нибудь pflask.

Справедливое замечание, спасибо за поправку.

Note that even though these security precautions are taken systemd-nspawn is not suitable for secure container setups.

Опции selinux-context и selinux-apifs-context не решают эту проблему?

К тому же оно не умеет (и не будет уметь) непривилегированные контейнеры.

Опять же, справедливо.

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