Комментарии 84
На первый взгляд отличная статья. Спасибо, попробую.
Спасибо за статью! Один вопрос: зачем вы размещаете изображения для статьи на Хабре на непонятном хостинге (это дурной тон), есть же родной habrastorage.org?
С habrasorage'ом у меня не самые приятные отношения. Обсуждаемый когда-то на хабре способ загрузки с помощью curl в очередной раз накрылся, я какое-то время поковырял, плюнул и загрузил изображения на другой хостинг.
Через браузер это все грузить — пытка, особенно если нужно сделать тамбнейлы. Тут графики еще мало, а вот когда прошлую статью писал, поминал habrastorage недобрым словом.
Через браузер это все грузить — пытка, особенно если нужно сделать тамбнейлы. Тут графики еще мало, а вот когда прошлую статью писал, поминал habrastorage недобрым словом.
Все равно автоматом на habrastoradge перенесет.
На habrastorage.org все фото переносятся разом в одно движение мышки, что в этом неудобного?
Попробую объяснить. У нас есть куча картинок. В идеале, их все нужно загрузить скопом, не важно там, мышкой или командой и получить список готовых к вставке html-тегов. Желательно, сразу с превьюшками.
Хабрасторадж-то отдаст список загруженных файлов, но теги с превьюшками не построит. Придется их делать и загружать отдельно, плюс соотносить пару превьюшка-оригинал и вставлять все это в текст.
Ладно бы оно нормально работало с curl, скрипт-то сваять не проблема. Но там что-то опять накрутили, и получаем «moved permanetly», что не делай.
Удобства, как говорится, во дворе. Потому я отдаю предпочтения сервисам, которые не столь параноидальны и позволяют взаимодействовать с собой не только посредством тыканья мышкой в браузере.
Хабрасторадж-то отдаст список загруженных файлов, но теги с превьюшками не построит. Придется их делать и загружать отдельно, плюс соотносить пару превьюшка-оригинал и вставлять все это в текст.
Ладно бы оно нормально работало с curl, скрипт-то сваять не проблема. Но там что-то опять накрутили, и получаем «moved permanetly», что не делай.
Удобства, как говорится, во дворе. Потому я отдаю предпочтения сервисам, которые не столь параноидальны и позволяют взаимодействовать с собой не только посредством тыканья мышкой в браузере.
Прочитал статью, но так и не понял, что же такое контейнерная виртуализация…
Ну, на этот счет написано довольно много. Если в двух словах, то контейнеры — это расширенный chroot с изоляцией, в том числе, сетевого стека.
Вот тут чуть подробнее про контейнерную виртуализацию.
Так lxc.network.type = empty или veth?
rc.local здесь выглядит совершенно нерабочим хаком. Насколько понимаю, он будет отрабатывать после всех остальных сервисов, в т.ч. и openvpn, когда они уже отругаются и перейдут в состояние failed.
Уже года три смотрю иногда на LXC, оно всё выглядит как очень для энтузиастов.
rc.local здесь выглядит совершенно нерабочим хаком. Насколько понимаю, он будет отрабатывать после всех остальных сервисов, в т.ч. и openvpn, когда они уже отругаются и перейдут в состояние failed.
Уже года три смотрю иногда на LXC, оно всё выглядит как очень для энтузиастов.
В целом да, но его активно поддерживает canonical и api у него более полное и стабильное, чем у docker, при этом оно само не привязано к сторонним сервисам, в отличии от rocket
Для энтузиастов, говорите? OpenVZ заменили на LXC в недавно вышедшем Proxmox VE 4.0
Да? Пошел смотреть. Как то я новость пропустил.
На это и надежда, что с более широким использованием оно станет таким же понятным и удобным инструментом, как например VirtualBox (мне кажется, во многом поэтому его и используют на декстопе). У самого в планах игры с PVE4.
У которого (PVE4), кстати, свой проблемы. Первая же обновлённая с PVE3 машина не умела создание LXC-контейнеров. Предлагая создать, внезапно, только OpenVZ-контейнеры.
ну Proxmox и так понятнее некуда. Другое дело, что если ты хочешь, что-то такое например поставить его на сотовый RAID, то можноь получить массу проблем.
Ну Upgrade всегда связан с рисками, обычно звонок в support — и они начинают решать эту проблему.
Сам пока на боевых серверах, буду ждать с обновлением, а вот на поиграться поставлю.
Тем более там и CEPH новый.
Ну Upgrade всегда связан с рисками, обычно звонок в support — и они начинают решать эту проблему.
Сам пока на боевых серверах, буду ждать с обновлением, а вот на поиграться поставлю.
Тем более там и CEPH новый.
Другое дело, что если ты хочешь, что-то такое например поставить его на сотовый RAID, то можноь получить массу проблем.
Да ладно? Элементарно ставится по инструкции с сайта — делаем debian на софтовом раиде, затем конвертируем в pve. Никаких проблем. В смысле надёжности и эксплуатации такая система совершенно не отличается от просто линукса с софтовым раидом, т. е. для многих даже зачастую предпочтительнее, чем аппаратный раид.
Вообще обновление прошло нормально. А вот CEPH вызвал вопросы. Если в прошлом релизе в лаборатории мы тестировали и без проблем разместили ceph osd на lvm-томе, то в этом релизе это вызвало затруднения.
Черт возьми, все таки пролезло empty, хотя вроде все лишнее поудалял. Разумеется veth, А при создании контейнера, по дефолту пишется empty. Сейчас подправлю.
>отрабатывать после всех остальных сервисов, в т.ч. и openvpn,
Есть такое дело, верное замечание. На самом деле, устройство достаточно создать один раз и писать это все в rc.local смысла нет. Поглядел сейчас на домашнем десктопе, там все это добро я когда-то закоментировал и, похоже, банально позабыл.
В частности у меня оно выглядит вот так:
/etc/rc.local
Сейчас подредактирую.
Есть такое дело, верное замечание. На самом деле, устройство достаточно создать один раз и писать это все в rc.local смысла нет. Поглядел сейчас на домашнем десктопе, там все это добро я когда-то закоментировал и, похоже, банально позабыл.
В частности у меня оно выглядит вот так:
/etc/rc.local
#mkdir /dev/net &
#mknod /dev/net/tun c 10 200 &
su user -c 'i2prouter start' &
openvpn /home/user/vpn/my.ovpn
Сейчас подредактирую.
Да уже больше года как используем в продакшене LXC на Ubuntu 14.04.
Там много чего вкусного есть.
Там много чего вкусного есть.
Можете сравнить с OpenVZ?
ну, ведь наружу, в «дикие интернеты» lxc скорее всего не смотрит?
у меня в DMZ сервисы живут только в OpenVZ,
так соображения безопасности заставляют мириться с древним ядром.
у меня в DMZ сервисы живут только в OpenVZ,
так соображения безопасности заставляют мириться с древним ядром.
а с LXC можно новое ядро использовать.
Конечно ядро системы это бич OpenVZ и это они сами признают.
Конечно ядро системы это бич OpenVZ и это они сами признают.
Почему не смотрит? Смотрит. Используется защита Неуловимого Джо, но даже если и так, то чтобы вылезти из контейнера, нужно:
1. Влезть в контейнер
2. Поднять привилегии
3. Понять что используется LXC
4. Вылезти из LXC
Я согласен, что в случае полной виртуализации выйти за пределы ВМ сложнее, но до этого вам предстоит еще, как минимум, два этапа.
Были проломы сайтов (дыры в WP и самописных движках), но не более.
1. Влезть в контейнер
2. Поднять привилегии
3. Понять что используется LXC
4. Вылезти из LXC
Я согласен, что в случае полной виртуализации выйти за пределы ВМ сложнее, но до этого вам предстоит еще, как минимум, два этапа.
Были проломы сайтов (дыры в WP и самописных движках), но не более.
Я на своем домашнем сервере все-таки вынес публичные сервисы и owncloud на kvm. Не доверяю я своим навыкам закрыть все возможные дыры.
Никто не доверяет. Поэтому «мухи отдельно, котлеты — отдельно».
Как показывает практика, даже просто использование LXC в качестве chroot позволяет избежать массы проблем, не говоря уже о полной виртуализации. Правда, оба подхода требуют применения системы массового управления конфигурацией/состояниями (Chef, Puppet, Ansible, Salt).
Как показывает практика, даже просто использование LXC в качестве chroot позволяет избежать массы проблем, не говоря уже о полной виртуализации. Правда, оба подхода требуют применения системы массового управления конфигурацией/состояниями (Chef, Puppet, Ansible, Salt).
С полноценной виртуализацией тоже не всё гладко. «Недавний» баг в Xen 3.4+ XSE 148/CVE-2015-7835 (дыра была с ~2009 года, если что) показывает, что даже нормальная виртуализация далека от хорошей изоляции.
Это конечно, паравиртуализация, но кто в том же kvm сейчас живёт без virtio или в esxi/vmware без их модулей?
Для желающих, рекомендую почитать github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt
Это конечно, паравиртуализация, но кто в том же kvm сейчас живёт без virtio или в esxi/vmware без их модулей?
Для желающих, рекомендую почитать github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt
Для домашнего использования я бы порекомендовал еще посмотреть на bocker, Rocket и Vagga.
Если нужен просто расширенный chroot без ограничения ресурсов через cgroops, то можно пользоваться системным unshare или чем-нибудь еще. Есть вот моя поделка — pyspaces =)
Больше справочной инфы по ним всем тут
Если нужен просто расширенный chroot без ограничения ресурсов через cgroops, то можно пользоваться системным unshare или чем-нибудь еще. Есть вот моя поделка — pyspaces =)
Больше справочной инфы по ним всем тут
Docker Standart de facto? Rly?
Вы можете назвать другой продукт, формат образов которого из коробки поддерживают большие cloud провайдеры вроде amazon и google, для которого пишутся большинство оркестраторов и который принят за основу спецификации с участием очень большого количества игроков на рынке?
который принят за основу спецификациивы не указали название спецификации
Простите, понадеялся, что вы ссылку сами найдете в том же списке.
Open Container Initiative
спека на гитхабе
в спеке rkt указано, что они перейдут на этот фомат после того, как он пройдет фазу активного развития и стабилизируется
Я сам не в большом восторге от докера, но с его нынешнем статусом приходится мириться
Open Container Initiative
спека на гитхабе
в спеке rkt указано, что они перейдут на этот фомат после того, как он пройдет фазу активного развития и стабилизируется
Я сам не в большом восторге от докера, но с его нынешнем статусом приходится мириться
Мне как-то напрочь изолированный kvm ближе. Ресурсов и памяти у сервера с избытком…
Дома контейнеры уже лет 8 как.
bridge-utils лучше заменить на Open vSwitch
bridge-utils лучше заменить на Open vSwitch
Хотелось бы статью на эту тему. Именно вот так вот вы делали bridge-utils, а вот так это следует делать ovs
Я из разряда перфекционистов-прокрастинаторов.
Потом если начинаешь переходить с одной технологии на другую, после чтение документации вопросы отпадают.
Сравнивать bridge-utils и ovs это в корне не верно.
Потом если начинаешь переходить с одной технологии на другую, после чтение документации вопросы отпадают.
Сравнивать bridge-utils и ovs это в корне не верно.
Я вот писал об этом http://blog.ipeacocks.info/2015/12/lxc-ontainers-part-ii-network.html
На украинском, но он чудесно корректно переводится на русский.
На украинском, но он чудесно корректно переводится на русский.
К openvswitch ровно одна претензия: ОЧЕНЬ большой оверинжиниринг. Он содержит слишком много того, чего не должен. В этом смысле он похож на systemd: от утилиты управления openvswitch я ожидаю, что она будет исключительно заниматься передачей моих команд ядру, но никак не поддержания отдельной базы данных с конфигурацией (тем более, я категорически против такой базы в бинарном виде), синхронизации между нодами и тому подобного. Пусть синхронизацией занимается мой механизм кластеризации, на базе того же corosync, а не непонятный сервис, поведение которого при различных отказах не определено; базу конфигурации оставим скриптам инициализации ОС, которая лучше знает, какие у чего зависимости.
С ip + brctl можно сделать что нужно: ip link add link name eth0.15 dev eth0 type vlan id 15 и дальше brctl addif br15 eth0.15 и всё, я сделал влан и добавил в мост. Это легко автоматизировать, прекрасно поддерживается скриптами инициализации сети во всех дистрибутивах. Если мне надо, я могу, не прерывая сервис, свободно модифицировать эту структуру в памяти, не трогая конфигурацию, или наоборот только изменить конфигурацию, которая активируется при следующей перезагрузке.
Самое главное: эти две утилиты — это всё, что нужно, никакой базы данных, всё оперативное состояние хранится в ядре и используется при работе, а конфигурация — в конфиг-файлах ОС и загружается понятным и простым образом.
С ip + brctl можно сделать что нужно: ip link add link name eth0.15 dev eth0 type vlan id 15 и дальше brctl addif br15 eth0.15 и всё, я сделал влан и добавил в мост. Это легко автоматизировать, прекрасно поддерживается скриптами инициализации сети во всех дистрибутивах. Если мне надо, я могу, не прерывая сервис, свободно модифицировать эту структуру в памяти, не трогая конфигурацию, или наоборот только изменить конфигурацию, которая активируется при следующей перезагрузке.
Самое главное: эти две утилиты — это всё, что нужно, никакой базы данных, всё оперативное состояние хранится в ядре и используется при работе, а конфигурация — в конфиг-файлах ОС и загружается понятным и простым образом.
Ну как то много телодвижений для домашнего использования, да и с дисковым пространством и памятью сейчас проблем нет.
Телодвижений многовато только на первых порах, в момент первичной настройки своего первого контейнера. Да и то, телодвижений — создать контейнер, прописать в конфиге нужные устройства и маунтпоинты, прописать интерфейсы. Может быть в статье это выглядит несколько монстроузно, а на деле делается минут за 20 с кружкой чая. Когда-нибудь, думается, для этого будет сделана гуевая тулза.
А дальше это все клонируется с правкой пары строчек, делаются и удаляются снапшоты при надобности и так далее. Вообще, это все мне очень напоминает будто заново открытые соляровские virtual zones, но я очень рад, что в линуксе такие решения развиваются, полируются и являются при этом свободными.
А отсутствие проблем с дисковым пространством и памятью — это не означает, что всем этим можно разбрасываться направо и налево. Да и отсутствие ли? Я там выше писал про лаптоп, а контейнеры мне нужны и на нем.
А дальше это все клонируется с правкой пары строчек, делаются и удаляются снапшоты при надобности и так далее. Вообще, это все мне очень напоминает будто заново открытые соляровские virtual zones, но я очень рад, что в линуксе такие решения развиваются, полируются и являются при этом свободными.
А отсутствие проблем с дисковым пространством и памятью — это не означает, что всем этим можно разбрасываться направо и налево. Да и отсутствие ли? Я там выше писал про лаптоп, а контейнеры мне нужны и на нем.
Домашний сервер давно уже не держу, но вот на рабочем пк сделал связку vagrant + lxc, контейнеры это быстро, а когда все настроить ещё и удобно. Для девелоп и тестовой сред используем PVE кластер, начали тестировать PVE4, в целом довольны, планируем CEPH поднять под это дело. в общем-то мы с коллегами верим в LXC. Статья полезная, спасибо!
Дальше либо на хосте, либо на другой рабочей виртуалке можно получить список установленных пакетов и установить их все в нашем новом контейнере:Вместо этого костыля, можно и нужно использовать шаблоны.
Шаблоны, поставляемые с lxc, можно найти в /usr/share/lxc/templates.
Там имеются, помимо прочего, шаблоны для создания контейнеров Ubuntu, Debian, Fedora, Oracle, Centos и Gentoo.
При выполнении lxc-create все параметры, указанные после --, передаются шаблону.
В следующей команде --name, --template и --bdev передаются lxc-create, в то время как --release передаётся шаблону:
lxc-create --template ubuntu --name c1 --bdev loop -- --release trusty
Конечно можно. Их можно править, создавать свои, или вообще создавать образ с помощью того же debbootstrap'a.
Но получить список пакетов с рабочей системы и переложить работу по установке на apt — это может быть проще, чем заниматься правкой и написанием шаблона. Да и не костыль это, а стандартное действие для пакетного менеджера.
Другое дело, когда нужно клепать много однотипных контейнеров на разных хостах — тут действительно проще написать шаблон. В общем, каждой задаче свой инструмент. В этом путь UNIX, да.
Но получить список пакетов с рабочей системы и переложить работу по установке на apt — это может быть проще, чем заниматься правкой и написанием шаблона. Да и не костыль это, а стандартное действие для пакетного менеджера.
Другое дело, когда нужно клепать много однотипных контейнеров на разных хостах — тут действительно проще написать шаблон. В общем, каждой задаче свой инструмент. В этом путь UNIX, да.
vim /etc/lxc/default.confИ задаем параметры по умолчанию для новых контейнеров. Например прописываем сеть и автостарт
lxc.network.type = veth
lxc.network.link = br0
lxc.network.flags = up
lxc.network.hwaddr = 00:16:3e:xx:xx:xx
lxc.start.auto = 1
lxc.start.delay = 10
Тут же, в конфиге, можно задать и IP, маску, gateway. А можно поставить и подстроить dnsmasq, который сам всё сделает.
Зачем удалять инклюд дефолтного конфига?
lxc.include = /usr/share/lxc/config/debian.common.confМожно еще поиграться с unprivileged контейнерами — там у рута uid 100000, я пока не занимался этим.
А еще есть LXD…
>Тут же, в конфиге, можно задать и IP, маску, gateway.
Вот только nameserver в конфиге контейнера так не задать. Можно, конечно, попробовать передать через network.script.up… В общем, тут опять же зависит от задачи и фантазии. Нужно много однотипных контейнеров: используем типовой конфиг с небольшими изменениями и сеть описываем как-то вот так.
А может быть нужно воспользоваться дистрибутив-специфичными вещами: потребуется там несколько интерфейсов, обработка событий на up-down, нестандартная маршрутизация итд…
В общем, юзкейсов и способов построения много (:
>Зачем удалять инклюд дефолтного конфига?
Очевидно же: чтобы написать свои правила, которые могут противоречить дефолтному конфигу.
Вот только nameserver в конфиге контейнера так не задать. Можно, конечно, попробовать передать через network.script.up… В общем, тут опять же зависит от задачи и фантазии. Нужно много однотипных контейнеров: используем типовой конфиг с небольшими изменениями и сеть описываем как-то вот так.
А может быть нужно воспользоваться дистрибутив-специфичными вещами: потребуется там несколько интерфейсов, обработка событий на up-down, нестандартная маршрутизация итд…
В общем, юзкейсов и способов построения много (:
>Зачем удалять инклюд дефолтного конфига?
Очевидно же: чтобы написать свои правила, которые могут противоречить дефолтному конфигу.
>Можно еще поиграться с unprivileged контейнерами
Можно, но будут проблемы с построением мостов изнутри контейнера, доступом к хранилищам (например, LVM группам и томам). А так, надо добавить на хосте юзера с uid, например, 31337 и соответствующим gid'ом, а в конфиге контейнера прописать нечто вида:
И получаем отображение: рут-процессы в контейнере имеют uid/gid свежесозданного юзера. Единичка, если что, это диапазон, указывающий на все остальные uid/gid и как они будут отображаться на хосте.
Вообще, это все еще может быть полезно для синхронизации прав доступа пользователя на хосте и в контейнерах, если uid'ы отличаются.
Можно, но будут проблемы с построением мостов изнутри контейнера, доступом к хранилищам (например, LVM группам и томам). А так, надо добавить на хосте юзера с uid, например, 31337 и соответствующим gid'ом, а в конфиге контейнера прописать нечто вида:
lxc.id_map = u 0 31337 1
lxc.id_map = g 0 31337 1
И получаем отображение: рут-процессы в контейнере имеют uid/gid свежесозданного юзера. Единичка, если что, это диапазон, указывающий на все остальные uid/gid и как они будут отображаться на хосте.
Вообще, это все еще может быть полезно для синхронизации прав доступа пользователя на хосте и в контейнерах, если uid'ы отличаются.
Контейнеры идеальны для автоматического тестирования. Каждый тест можно в своей песочнице запускать
А кто-нибудь знает ответ на следующий вопрос? Реально ли с помощью linux-контейнеров (LCX, Docker) добиться того, чтобы внутри контейнера была запущена отличная от хостовой версия видео-драйвера?
Это требуется для CUDA(OpenCL) вычислений. Мне нужна специфичная версия проприоретарного видео драйвера (и, видимо, как следствие, ядра), отличная от той, которая установлена в хостовой системе.
Смогу ли я решить этот вопрос контейнерами, или требуется полноценная виртуализация + проброс PCI устройств?
Это требуется для CUDA(OpenCL) вычислений. Мне нужна специфичная версия проприоретарного видео драйвера (и, видимо, как следствие, ядра), отличная от той, которая установлена в хостовой системе.
Смогу ли я решить этот вопрос контейнерами, или требуется полноценная виртуализация + проброс PCI устройств?
> Реально ли с помощью linux-контейнеров (LCX, Docker) добиться того, чтобы внутри контейнера была запущена отличная от хостовой версия видео-драйвера?
Увы, невозможно. Контейнер работает на ядре хоста со всеми его модулями. Так что здесь только виртуализация и проброс.
Увы, невозможно. Контейнер работает на ядре хоста со всеми его модулями. Так что здесь только виртуализация и проброс.
Виртуализация и проброс. qemu-kvmэто неплохо научился в пслд версиях, по тестам потеря производительности около 1% в видео.
Вот что бы я изменил в Вашей инструкции — так это использование LVM. Теряется масса преимуществ без дополнительных бонусов. Преимущества — простой доступ к файловой системе контейнера и создание контейнеров с опцией -B aufs и потенциально в каком-то будущем overlayfs (в Debian). Вот с этими бонусами использование для указанных применений LXC становится приятно и просто.
В случае с LVM доступ по-прежнему простой и удобный, хотя в цепочку действий добавляется необходимость монтирования. Плюсов у LVM много, а в данном случае весьма критично использовать снапшоты в том числе и под машины-клоны. То есть, имеем первый контейнер размером в 2GB, и второй — его копию, но с куда более скромны объемом в сотню метров.
Ну и вообще, LVM штука полезная. Бэкапиться с его помощью просто и приятно.
Про aufs ничего не скажу, сталкиваться покамест не приходилось.
Ну и вообще, LVM штука полезная. Бэкапиться с его помощью просто и приятно.
Про aufs ничего не скажу, сталкиваться покамест не приходилось.
Btrfs и ZFS так же хороши. Поддержка идет из коробки. Единственное есть противный баг github.com/lxc/lxc/issues/603
Да, zfs — штука более чем приятная, а контексте обсуждаемого, с соларис-контейнерами. так вообще просто шик.
Но есть нюансы. На том же основном лаптопе прекрасно работает связка LVM+LUKS, причем получается она, что называется, «из коробки», а вот с brtfs или zfs тут может потребоваться несколько больше телодвижений. Да и со стабильностью, увы, пока не слишком хорошо: так на brtfs поверх dm-crypt вот такая веселуха может всплыть: permalink.gmane.org/gmane.comp.file-systems.btrfs/15564
А в дебиан-стейбле у нас 3.16, ага.
Но есть нюансы. На том же основном лаптопе прекрасно работает связка LVM+LUKS, причем получается она, что называется, «из коробки», а вот с brtfs или zfs тут может потребоваться несколько больше телодвижений. Да и со стабильностью, увы, пока не слишком хорошо: так на brtfs поверх dm-crypt вот такая веселуха может всплыть: permalink.gmane.org/gmane.comp.file-systems.btrfs/15564
А в дебиан-стейбле у нас 3.16, ага.
На лаптопе — полностью согласен. Достаточно стабильно и консервативно. Если же говорить как минимум о стейджинг серверах, то это очень дешевый вариант создания контейнеров за несколько секунд. Недавно внедрил в проект LXC (опционально) в качестве замены VirtualBox-у. Речь идет о Vagrant-е. Разработчики использующие Linux ликуют:)
LVM для указанных применений не имеет ни одного плюса. Во-первых, любой снапшот — это ресурсы при его удалении. Во-вторых, бэкапирование и без LVM делается проще, можно даже сказать что гораздо проще — опять же, для указанного применения. В третьих размер файловой системы становится фиксированным что, несмотря на возможность расширения, неудобно. Ну а машины-клоны с помощью Aufs занимают вообще пустяки, не заслуживающие упоминания — гораздо меньше чем LVM.
А как там теперь, LVM не тупит в случае наличия снапшотов?
Прочитал статью, но не понял, чем Docker-то не угодил?
Docker довольно узкоспециализирован. Для изоляции приложений и даже деплоя он, конечно, хорош. Но когда нужен контейнер с полноценной операционной системой, лучше все-таки смотреть на lxc или openvz.
А как в Docker разрешить пользователю управление только его контейнерами?
Докер для этого не предназначен. Человек имеющий права на управление контейнерами докера фактически имеет права рута на соответствующем хосте.
Можно, конечно, делать обёртку, чтобы пользователь не имел возможности работать напрямую и сделать свой IaaS/PaaS.
Можно, конечно, делать обёртку, чтобы пользователь не имел возможности работать напрямую и сделать свой IaaS/PaaS.
Получается, в этом Docker уступает LXC — там есть unprivileged-контейнеры, хранящиеся в $HOME.
Сранение, мягко говоря, некорректно. Docker построен поверх LXC (да, есть другие провайдеры, но в 99% использования — это LXC). Т.о., как и при использовании любой обёртки, теоретических возможностей у высокоуровневого API меньше, чем у низкоуровневого, но с другой стороны вам предоставляют удобный интерфейс для создания, запуска и менеджмента LXC-шек, скрестив это дело с файловыми системами, предоставляющими каскадно-объединённое монтирование (ну а также как альтернатива — c оверлеями device mapper-а).
Если кто захочет написать, что libcontainer (который юзается последними версиями докера) != LXC — теоретически верно, но внутри одно и то же. Те же механизмы ядра linux для контейнеризации (cgroups). Теоретически LXC — это название набора простых тулз для работы с этими вызовами, но обычно, говоря LXC, подразумевают всю технологию контейнеризации, предоставляемую ядром linux.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Linux-контейнеры дома: зачем и как