LXC 2.0

Ждем в proxmox

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

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

CoreOS, если не ошибаюсь, сам не пробовал.

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

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

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

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

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

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

Ясно, тогда простите.

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

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

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

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

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

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

Да может и без LXC, через libcontainer, libvirt или systemd-nspawn

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

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

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

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

Xen там.

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

Поделись, как мне вывести Доверовый контейнер наружу через бридж с отдельным IP?
Через два бриджа?

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

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

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

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

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

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

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

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

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

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

Т.е. вывести адрес целиком - невозможно?
Вывести два адреса - невозможно?

У меня вот такая проблема была в предыдущей версии https://github.com/lxc/lxc/issues/744

Надеюсь, теперь заживём.

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

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

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

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

Да без проблем, man «network driver plugin» - https://docs.docker.com/engine/extend/plugins_network/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Щито?

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

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

та смотрел - но что-то ничего не нашел. сеть отлично работает кроме вот этой проблемы.

OVZ крут, но LXC активно допиливают.

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

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

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

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

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

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

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

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

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

В чём преимущество 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.

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

этот релиз гвоздями прибит к ненужнод, увы.

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 не решают эту проблему?

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

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