Linux-контейнеры дома: зачем и как

С habrasorage'ом у меня не самые приятные отношения. Обсуждаемый когда-то на хабре способ загрузки с помощью curl в очередной раз накрылся, я какое-то время поковырял, плюнул и загрузил изображения на другой хостинг.

Через браузер это все грузить — пытка, особенно если нужно сделать тамбнейлы. Тут графики еще мало, а вот когда прошлую статью писал, поминал habrastorage недобрым словом.

Ну, на этот счет написано довольно много. Если в двух словах, то контейнеры — это расширенный chroot с изоляцией, в том числе, сетевого стека.

Вот тут чуть подробнее про контейнерную виртуализацию.

В целом да, но его активно поддерживает canonical и api у него более полное и стабильное, чем у docker, при этом оно само не привязано к сторонним сервисам, в отличии от rocket

Для энтузиастов, говорите? OpenVZ заменили на LXC в недавно вышедшем Proxmox VE 4.0

Черт возьми, все таки пролезло empty, хотя вроде все лишнее поудалял. Разумеется veth, А при создании контейнера, по дефолту пишется empty. Сейчас подправлю.

>отрабатывать после всех остальных сервисов, в т.ч. и openvpn,

Есть такое дело, верное замечание. На самом деле, устройство достаточно создать один раз и писать это все в 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.
Там много чего вкусного есть.

Ну это если с избытком, а обычно дома стоят тихие сервера. Там контейнеры очень да же правят миром.

У сервера, у лаптопа — нет. А контейнеры нужны и на нем.

Хотелось бы статью на эту тему. Именно вот так вот вы делали bridge-utils, а вот так это следует делать ovs

К openvswitch ровно одна претензия: ОЧЕНЬ большой оверинжиниринг. Он содержит слишком много того, чего не должен. В этом смысле он похож на systemd: от утилиты управления openvswitch я ожидаю, что она будет исключительно заниматься передачей моих команд ядру, но никак не поддержания отдельной базы данных с конфигурацией (тем более, я категорически против такой базы в бинарном виде), синхронизации между нодами и тому подобного. Пусть синхронизацией занимается мой механизм кластеризации, на базе того же corosync, а не непонятный сервис, поведение которого при различных отказах не определено; базу конфигурации оставим скриптам инициализации ОС, которая лучше знает, какие у чего зависимости.

С ip + brctl можно сделать что нужно: ip link add link name eth0.15 dev eth0 type vlan id 15 и дальше brctl addif br15 eth0.15 и всё, я сделал влан и добавил в мост. Это легко автоматизировать, прекрасно поддерживается скриптами инициализации сети во всех дистрибутивах. Если мне надо, я могу, не прерывая сервис, свободно модифицировать эту структуру в памяти, не трогая конфигурацию, или наоборот только изменить конфигурацию, которая активируется при следующей перезагрузке.
Самое главное: эти две утилиты — это всё, что нужно, никакой базы данных, всё оперативное состояние хранится в ядре и используется при работе, а конфигурация — в конфиг-файлах ОС и загружается понятным и простым образом.

Телодвижений многовато только на первых порах, в момент первичной настройки своего первого контейнера. Да и то, телодвижений — создать контейнер, прописать в конфиге нужные устройства и маунтпоинты, прописать интерфейсы. Может быть в статье это выглядит несколько монстроузно, а на деле делается минут за 20 с кружкой чая. Когда-нибудь, думается, для этого будет сделана гуевая тулза.

А дальше это все клонируется с правкой пары строчек, делаются и удаляются снапшоты при надобности и так далее. Вообще, это все мне очень напоминает будто заново открытые соляровские virtual zones, но я очень рад, что в линуксе такие решения развиваются, полируются и являются при этом свободными.

А отсутствие проблем с дисковым пространством и памятью — это не означает, что всем этим можно разбрасываться направо и налево. Да и отсутствие ли? Я там выше писал про лаптоп, а контейнеры мне нужны и на нем.

планируем CEPH поднять

Почему не Gluster?

Конечно можно. Их можно править, создавать свои, или вообще создавать образ с помощью того же debbootstrap'a.

Но получить список пакетов с рабочей системы и переложить работу по установке на apt — это может быть проще, чем заниматься правкой и написанием шаблона. Да и не костыль это, а стандартное действие для пакетного менеджера.

Другое дело, когда нужно клепать много однотипных контейнеров на разных хостах — тут действительно проще написать шаблон. В общем, каждой задаче свой инструмент. В этом путь UNIX, да.

>Тут же, в конфиге, можно задать и IP, маску, gateway.

Вот только nameserver в конфиге контейнера так не задать. Можно, конечно, попробовать передать через network.script.up… В общем, тут опять же зависит от задачи и фантазии. Нужно много однотипных контейнеров: используем типовой конфиг с небольшими изменениями и сеть описываем как-то вот так.

А может быть нужно воспользоваться дистрибутив-специфичными вещами: потребуется там несколько интерфейсов, обработка событий на up-down, нестандартная маршрутизация итд…

В общем, юзкейсов и способов построения много (:

>Зачем удалять инклюд дефолтного конфига?

Очевидно же: чтобы написать свои правила, которые могут противоречить дефолтному конфигу.

>Можно еще поиграться с unprivileged контейнерами

Можно, но будут проблемы с построением мостов изнутри контейнера, доступом к хранилищам (например, 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) добиться того, чтобы внутри контейнера была запущена отличная от хостовой версия видео-драйвера?

Увы, невозможно. Контейнер работает на ядре хоста со всеми его модулями. Так что здесь только виртуализация и проброс.

Виртуализация и проброс. qemu-kvmэто неплохо научился в пслд версиях, по тестам потеря производительности около 1% в видео.

В случае с LVM доступ по-прежнему простой и удобный, хотя в цепочку действий добавляется необходимость монтирования. Плюсов у LVM много, а в данном случае весьма критично использовать снапшоты в том числе и под машины-клоны. То есть, имеем первый контейнер размером в 2GB, и второй — его копию, но с куда более скромны объемом в сотню метров.

Ну и вообще, LVM штука полезная. Бэкапиться с его помощью просто и приятно.

Про aufs ничего не скажу, сталкиваться покамест не приходилось.

Docker довольно узкоспециализирован. Для изоляции приложений и даже деплоя он, конечно, хорош. Но когда нужен контейнер с полноценной операционной системой, лучше все-таки смотреть на lxc или openvz.

А как в Docker разрешить пользователю управление только его контейнерами?