Контейнеры lxc/lxd (в Slackware и не только)

Здесь можно поговорить о чём угодно и сколько угодно.

Модератор: Модераторы разделов

Ответить
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Контейнеры lxc/lxd

Сообщение Hephaestus »

По итогам этой темы.
Посмотрев разные варианты создания контейнеров, пришёл к выводу, что чаще всего попадается lxc.
У docker под капотом lxc, Promox вроде тоже перешли на lxc/lxd. Кроме того, нашлись переводы статей, русскоязычная версия сайта, how-to... Короче говоря, решил попробовать.

Сначала (сам дурак) начал собирать lxc из исходников - создал ей слакбилд, собрал.
Потом как-то случайно обнаружил, что она, оказывается, есть в репах слаки. Ладно, поставил из репов.
Там оказался шаблон для слаки... Запустил я это дело, создал контейнер... Всё работает, вроде бы...
Если бы я удовольствовался привилегированным контейнером, этим бы всё и кончилось. Но мне захотелось непривилегированных. Тут выяснилось, что создание непривилегированных контейнеров выполняется от пользователя, а следовательно, есть ограничения, в частности, нельзя создавать файлы устройств, в общем, нужно использовать шаблон download, то есть скачивать уже собранные контейнеры. Никакой slackware там в списках, разумеется, не оказалось, а те, которые были - почти все завязаны на systemd, поэтому не запускаются. Запустить удалось debian wheezy.

Нашлась серия статей Unprivileged containers in Slackware
(второй вариант), где предлагалось создать обычный привилегированный контейнер,
потом заменить gid/uid на subgid/subuid по всем файлам, создать конфиги и в итоге запустить это всё от пользователя.
Попробовал. Вроде получилось, но слишком много возни по превращению контейнера.

Решил тогда попробовать lxd. Предъявляется, как более современный вариант, более безопасный, никаких шаблонов, только проверенные образы, ну и т.д.
Заявлено, что lxd - это демон, а lxc - клиент.

Собрал/поставил я это дело...
Поскольку lxd - детище Canonical, то понятно, что Ubuntu там на первом месте. Ну и systemd, разумеется. Куда ж без него...
И разумеется, никакой Slackware там и рядом нет. Зато утверждается, что легко создавать свои образы, в отличие от возни с шаблонами lxc.
Это правда. Создать образ оказалось проще простого.
Достаточно поставить нужные пакеты в отдельный каталог через chroot, создать файл метаданных, упаковать всё это хозяйство в тарбол и скормить тарбол демону. Тот его нормально съест и развернёт дерево каталогов в контейнере. С этим вроде всё нормально.

Но вот сам демон...
Демон он - так себе, честно говоря.
Стартует в foreground, shell не отдаёт обратно. В случае чего, нужно его принудительно запускать в фоне.
Pid-файл не создаёт. Если он нужен, об этом придётся позаботиться самостоятельно.
Сообщения выводит в терминал (даже при указанном файле логов), приходится глушить.
Короче, от демона там только сокет. Сокет создает/уничтожает исправно, да.
А всё остальное - как у обычной программы. У меня rtorrent вёл себя так же, с той лишь разницей, там ещё и сокет создавать приходилось.
Но при этом его гордо величают "демоном".
Решил я, раз он демон, то и стартовать его нужно как демон - при загрузке системы.
Написал для него init-скрипт с учётом перечисленных особенностей.

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

Мне вот интересно, это "демон", который на самом деле не демон - он везде так себя ведёт или только в слаке?
Spoiler
-- Не человеьчим хотеньем, но Божьим соизволеньем, молви ещё раз, ты не демон?
-- Я Вам сто раз объяснял, кто я такой. Не демон я!
-- Ой, не лги! Ой, не лги - царю лжёшь!
При этом создатели слакбилда для lxd предоставляют run-скрипт, в котором за каким-то чёртом запуск этого "демона" прописан как "lxd daemon", хотя такой команды у lxd нет. И стартует он всё равно в foreground.
И я бы может даже чего-нибудь там пропатчил, но оно написано на go, которого я совсем не знаю.


У кого есть желание поделиться опытом/историями (не)успеха использования lxc/lxd - милости просим.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20794
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Контейнеры lxc/lxd

Сообщение Bizdelnick »

Hephaestus писал:
23.12.2018 16:18
У docker под капотом lxc
Вообще-то нет. У них обоих под капотом те же самые namespaces, cgroups и что там ещё, но на этом общее у них заканчивается.

Hephaestus писал:
23.12.2018 16:18
Стартует в foreground, shell не отдаёт обратно. В случае чего, нужно его принудительно запускать в фоне.
Pid-файл не создаёт. Если он нужен, об этом придётся позаботиться самостоятельно.
systemd-way… А что, в слаке нет start-stop-daemon?
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Kopilov
Сообщения: 949
ОС: [K]Ubuntu, Debian

Re: Контейнеры lxc/lxd

Сообщение Kopilov »

А в каком случае вообще нужно использовать lxc, а не Docker?

(Docker на работе используем, как с Kubernetes, так и без)
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Контейнеры lxc/lxd

Сообщение Hephaestus »

Bizdelnick писал:
23.12.2018 22:21
Вообще-то нет. У них обоих под капотом те же самые namespaces, cgroups и что там ещё, но на этом общее у них заканчивается.
Мне это встречалось на просторах Сети несколько раз.
"Docker - обертка над lxc"
"Docker использует lxc"
"Изучите lxc - будете понимать, как работает Docker"
и т.д. Возможно, это уже не актуально, но вот попадалось такое.
Bizdelnick писал:
23.12.2018 22:21
А что, в слаке нет start-stop-daemon?
Нету. Из всех опробованных мной дистров (Ubuntu, AltLinux, Mandriva, Debian, Slackware) start-stop-daemon я видел только в Debian. Даже в Ubuntu вроде не было (хотя утверждать не буду - не помню), а в остальных не было точно. И если я правильно помню, start-stop-daemon это всего лишь функции-обертки (одна или несколько), то есть те же shell-скрипты. Так что, если программа изначально - не демон, получится то же самое, что у меня, разве что использовать удобней.
Да я так-то не против - написал я скрипт - да и ладно. Не в первый раз.
Просто странно, что "демоном" называют программу, в которой от демона - только сокет.
А ведь там в исходниках на каждом шагу daemon, daemon, daemon...
И в ман-странице она демоном называется. И в официальной документации.
Ну я и подумал, может я ошибся и она всё-таки демон. Мало ли, под слакой собралась как-нибудь неправильно, потому и не работает как полноценный демон. Но похоже, что я не ошибся и она - не демон.
Либо я уже совсем не понимаю смысл термина "демон". Для меня демон - это программа, работающая в фоне.
И называется она демоном в силу своей "невидимости". А тут, понимаешь ли, оно не то, что не запускается в фоне - её туда пинками загонять надо - программу в background переводить, да ещё глушить вывод на stdout/stderr. Ладно хоть сокет руками создавать не надо.
Kopilov писал:
24.12.2018 00:10
А в каком случае вообще нужно использовать lxc, а не Docker?
Да я не знаю, почему не Docker. Я вот как-то сразу наткнулся на инфу, что Docker - это обертка, а lxc - более низкий уровень. Плюс попались статьи по lxc на русском. Плюс lxc присутствует в основных репах. Ну так оно и пошло-поехало. А когда решил использовать непривилегированные контейнеры - как-то само собой на lxd переключился.

А в docker тоже непривилегированные контейнеры или нет?
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20794
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Контейнеры lxc/lxd

Сообщение Bizdelnick »

Hephaestus писал:
24.12.2018 01:04
Мне это встречалось на просторах Сети несколько раз.
"Docker - обертка над lxc"
"Docker использует lxc"
"Изучите lxc - будете понимать, как работает Docker"
и т.д. Возможно, это уже не актуально, но вот попадалось такое.
Это никогда не было в полной мере актуально. Хотя и близко к действительности.
Hephaestus писал:
24.12.2018 01:04
Из всех опробованных мной дистров (Ubuntu, AltLinux, Mandriva, Debian, Slackware) start-stop-daemon я видел только в Debian. Даже в Ubuntu вроде не было (хотя утверждать не буду - не помню), а в остальных не было точно.
Хм, действительно, это дебиановская тулза. Мне почему-то казалось, что я её встречал и в других дистрибутивах. Но в убунте таки должна быть.
Hephaestus писал:
24.12.2018 01:04
И если я правильно помню, start-stop-daemon это всего лишь функции-обертки (одна или несколько), то есть те же shell-скрипты.
Неправильно:

Shell

% file /sbin/start-stop-daemon
/sbin/start-stop-daemon: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=22d6bd9ac8afbc6877af1f2e84bf090a6a2245a1, stripped
%
Kopilov писал:
24.12.2018 00:10
А в каком случае вообще нужно использовать lxc, а не Docker?
Очевидно, в тех случаях, когда нужна полноценная система с инитом, причём в единственном экземпляре.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
SLEDopit
Модератор
Сообщения: 4823
Статус: фанат консоли (=
ОС: GNU/Debian, RHEL

Re: Контейнеры lxc/lxd

Сообщение SLEDopit »

Hephaestus писал:
24.12.2018 01:04
Мне это встречалось на просторах Сети несколько раз.
"Docker - обертка над lxc"
"Docker использует lxc"
"Изучите lxc - будете понимать, как работает Docker"
Это было так до 2014 года. Потом пришел libcontainer.
Ну и чтобы понимать как работает docker лучше изучить сам docker, а не lxc. Чтоб уж наверняка (:

PS. В docker faq'e на эту тему есть целый вопрос
Hephaestus писал:
24.12.2018 01:04
А в docker тоже непривилегированные контейнеры или нет?
Внутри контейнера приложение может бежать от какого угодно пользователя. Необязательно от рута. А вот чтобы управлять контейнером, нужно состоять в группе docker, чтобы иметь право записи в докеровский сокет.
UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity. © Dennis Ritchie
The more you believe you don't do mistakes, the more bugs are in your code.
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20794
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Контейнеры lxc/lxd

Сообщение Bizdelnick »

Hephaestus писал:
24.12.2018 01:04
А в docker тоже непривилегированные контейнеры или нет?
По умолчанию непривилегированные, но можно сделать привилегированный.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Контейнеры lxc/lxd

Сообщение Hephaestus »

SLEDopit писал(а):
24.12.2018 01:39
Внутри контейнера приложение может бежать от какого угодно пользователя. Необязательно от рута.
Суть различий привилегированных и непривилегированных контейнеров совсем не в этом.
Там проблема серьёзнее: в случае использования привилегированного контейнера рут внутри контейнера "равен" руту хоста, поскольку они оба имеют id=0. Это нехорошо, небезопасно и т.п, так как "вырвавшись" за пределы контейнера такой пользователь в основной системе имеет права рута.
Для непривилегированных контейнеров используются subuid/subgid, в результате рут внутри контейнера имеет id=0, а снаружи он выглядит как пользователь с id=100000 или что-то в этом роде. Таким образом, за пределами контейнера он теряет все свои полномочия.
Это гораздо безопаснее. Обратной стороной этой безопасности является невозможность создать контейнер, так как нужно запускать от пользователя, а у пользователя нет прав на создание устройств и т.п. Для lxc предлагалось скачивать готовые образы и разворачивать у себя на машине.
Для lxd это остаётся справедливым, но там много чего улучшили.
Есть возможность создать свой образ. И даже опубликовать.
И даже есть какой-то сервер, где происходит процесс сборки разных образов.

Я вот вчера попробовал создать контейнер с минимальным набором пакетов слаки + пакеты категории D |девелоперские инструменты).
Вроде создалось, только размер вышел великоват - полтора гига. Надо бы повыкидывать лишнее.
А вообще неплохо, "клиент-серверный" интерфейс lxc/lxd оказался вполне годным.
Данные выводит в терминал виде ascii-таблиц.

И вообще, процесс создания контейнера, на мой взгляд, получился гармоничным:
в слаке создается чрут, туда ставятся пакеты, дерево каталогов упаковывается в тарбол (всё это через терминал, естественно).
а затем в lxc также через терминал тарбол импортируется и создается контейнер.
В общем lxc/lxd для слаки - самое то.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Ответить