Команда проекта Linux Containers, развивающая инструментарий для организации работы изолированных контейнеров LXC, менеджер контейнеров LXD, виртуальную ФС LXCFS, инструментарий сборки образов distrobuilder, библиотеку libresource и runtime lxcri, объявила, что менеджер контейнеров LXD отныне будет отдельно разрабатываться компанией Canonical. Компания Canonical, которая является создателем и основным разработчиком LXD, после 8 лет разработки в составе Linux Containers, решила, что LXD более оптимально развивать как корпоративный проект, а не проект независимого сообщества. Разработка остальных проектов Linux Containers останется без изменений...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59386
Там LXD, там Snap, там LXC. Как всю эту дрянь отличать?
Очень просто. LXC неплохая контейнерная изоляция, в отличии от докера это полноценная система и исплльзуешь её полноценно, т.е. никаких "один процесс на образ", вот прям как на реальной системе за исключением ограничений контейнеров (они и в докере такие же и в runc). Файловая система просто на диске располагается в /var/lib/lxc, красота в общем. Единственное не забудьте трафик разрешить через бридж lxcbr. Из недостатков что менее популярна докера, исключительно по этой причине настраивается немного тяжелее.
LXD это корпоративная обёртка над LXC. Что-то вроде openshift или k8s в докуберовскую эпоху. Если вы не просто тестируете/запускаете отдельный софт на lxc, а хотите развернуть инфраструктуру, то можете посмотреть в эту сторону. Особо не пользовался. Дока есть. Рассчитано на корпоратов с соответствующими проблемами от каноникал. В век кубера перспектив у неё не много, нужно все хорошенько взвесить прежде чем на неё перейти.
Snap это попытка принести контейнеры на десктоп "обычным пользователям"(кто это не уточняется). На самом деле крайне неудачная попытка крайне неудачной идеи пакетирования всего (windows like). Каноникл хотят денег, но не хотят работать и снап должен был решить эту диллему. Но даже среди богомерзких всепакетов снап оказался худшим, поэтому даже извращенные сообщества его не приняли. Но каноникл наплевать: у неё есть база убунты, куда она насильно его пропихивает. Скорее всего не осилит и как и другие поделки каноникл через несколько лет будет признано неудачным, отдадут "сообществу на поддержку" и перейдут на гно^W flatpack.tl;dr
LXC - норм, если нужна околополноценная условно изолированная система без виртуплизации
LXD - для корпоратов
Snap - мертворожденный способ "доставки приложений"^W^W бесконечных проблем для пользователей
... вроде k8s в докуберовскую эпоху... Что?
Необходимость разворачивать контейнеры на кластере из МНОЖЕСТВА машин появилась ещё задолго до кубернетеса. Особенно в провайдерской среде, где каждый пилил что-то своё, и я в том числе.
> LXC неплохая контейнерная изоляция, в отличии от докера это полноценная система и исплльзуешь её полноценно
> LXC - норм, если нужна околополноценная условно изолированная система
Все так. LXC это скорее про создать легкую виртуалку с полноценным окружением. k8s это скорее про разворачивание софта, ближе к stateless.
> Очень просто. LXC неплохая контейнерная изоляция, в отличии от докера это полноценная система и исплльзуешь её полноценно, т.е. никаких "один процесс на образ", вот прям как на реальной системе за исключением ограничений контейнеров (они и в докере такие же и в runc)нет таких ограничений и нет "системы" в контейнере. просто если нужно больше, чем один главный процесс, но используется init система. это может быть systemd или любая другая. для упрощения используется часть что-то типа runsv или supervisord. так что нет каких-то таких специфических ограничений докера. просто утилиты lxc видимо заточены за запуск типа VDS или чего-то такого.
но вообще докер - да, это своя философия: один процесс, изоляция сети, read-only (желательно) образ и т.п. нужно вначале разобраться почему так сделано и какие преимущества прежде чем ругаться.
кстати да, докер-контейнеры через сам докер удобно только если 1-3 сервера. когда их 100 и больше уже kubernetes без разговора.
но все-равно не мешает даже в k8s запускать больше, чем один процесс. просто это не всегда удобно содержать и мониторить.
(это все не теория)
> LXD это корпоративная обёртка над LXC. Что-то вроде openshift или k8s в докуберовскую эпоху.Поспорил бы. LXD этот как libvirt для qemu.
Обёртка над несколькими разными штуками. Типа - комбайн.Ещё есть Vagrant от HashiCorp. Полюбопытнее будет, т.к. в нём на Руби можно докрутить логику конфигурации и провижонинг запускаемой сушности.
Если говорить о практическом применении, то в LXD есть все необходимые механизмы для кастомизации и конфигураций (да хоть через банальный cloud-init), и провижининга. Знаю по собственному опыту, для разных заказчиков делал на LXD сборочные фермы, автоматизацию провижининга k8s кластеров для автоматического тестирования, девелоперских песочниц и для прода, менеджмент виртуальных машин, и так по мелочи для запуска сервисов в контейнерах. Настолько понравилось, что даже дома в LXD гоняю виртуалки и контейнеры со всяким барахлом.
>[оверквотинг удален]
> должен был решить эту диллему. Но даже среди богомерзких всепакетов снап
> оказался худшим, поэтому даже извращенные сообщества его не приняли. Но каноникл
> наплевать: у неё есть база убунты, куда она насильно его пропихивает.
> Скорее всего не осилит и как и другие поделки каноникл через
> несколько лет будет признано неудачным, отдадут "сообществу на поддержку" и перейдут
> на гно^W flatpack.
> tl;dr
> LXC - норм, если нужна околополноценная условно изолированная система без виртуплизации
> LXD - для корпоратов
> Snap - мертворожденный способ "доставки приложений"^W^W бесконечных проблем для пользователейСпасибо за обратную связь и доступное грамотное объяснение. LXC - это программная (не аппаратная) виртуализация дистрибутивов GNU/Linux. LXD - система аранжировки LXC. Snap - это попытка применить технологии из LXD для приложений Ubuntu Desktop. Я правильно понимаю систему?
Нет :)
> Нет :)Шо опять не так? Всё так было хорошо в моих фантазиях.
lxd это управление lxc (быстрые контейнеры к ним каноктикалы никакого отношения не имеют), snap тормозной запуск-изоляция приложений на тормозных fuse fs, общего между lxc и snap (но не lxd) это использование механизма cgroups
Там чудеса, там леший бродит, русалка на ветвях сидит...
LXD (D = daemon) - это демон, сервер
LXC (С = client) - это клиент к этому серверу контейнеров
Не вводите людей в заблуждение LXC образован от "LinuX Containers", это более низкий уровень, чем LXD, поэтом LXD скорее клиент к LXC.
> Не вводите людей в заблуждение LXC образован от "LinuX Containers", это более низкий уровень, чем LXD, поэтом LXD скорее клиент к LXC.Не вводи сам людей в заблуждение, это так было в первых версиях, уже прошло с того времени много лет и переписали всю концепцию кажется с версии 2.0, а на дворе уже 5-ая версия.
> Там LXD, там Snap, там LXC. Как всю эту дрянь отличать?Чё анальники минусов натыкали? Кто-то должен красноглазием днями заниматься?
Пацаны (и дамы разумеется), давайте проголосуем кого уважаем больше: Canonical или Redhat?
Как говорится, есть два стула...
какой из них жиже.
аксиома эскобара
Это лебедь, рак и щука...
LXD годнейший проект, жаль будет если сделают убунтуспецифичным или вовсе закроют.
Ничего не изменится, Canonical и так всегда пилил LXD в одиночку, просто сейчас решил убрать некоторые лишние цепочки для ускорения разработки. Идея была привлечь сообщество к работе над LXD, но никто из крупных компаний этим так и не заинтересовался.
я знаю L-xde, но я не знаю сабж
Какой-то парад суверенитетов.
Эпоха open source закончилась.Теперь компании, особенно которые десятки лет были не прибыльными, начали извлекать прибыль.
Базовые бесплатные вещи (Java) теперь требуют конских лицензий по 100к баксов в год.
На очереди языки программирования, компиляторы, контейнеры, виртуальные машины (привет этой новости), и даже сама ОС и базовые дистрибутивы.
Привет всем с лицензией Apache 2.0 и MIT.
Самым надёжным остаётся JavaScript и Web. Но не долог тот час , когда закроют и V8.
Тебе никто не мешает наваять форков версий с последней открытой лицензией, а потом стать судебным троллем, отстаивающим права общества в свой личный карман.
Ты видимо не понял что такое опенсурс.
Его нельзя закончить, он вечен как сама вселенная.
Ну а веб всегда был под крылом wc3 и корпораций. Тем более js и v8.
Всё с точностью до наоборот. А так всё верно.
На самом деле причина очень простая. Инфляция и конец эпохи дешевых денег. Центробанки повсеместно поднимают ключевыеставки, кредиты дорожают, инвесторы начинают требовать выхода на окупаемость, а лучше так прибыль, прием не ХХХ через 10-15 лет, а Х-ХХ, но через год-два.
Отсюда все эти содрагания Твиттора, Убера и прочих "мы стоим дофига притом что до сих пор убыточны" компаний. Инвесторы сокращают аппетит к риску.
Вот и IBM закрывают "халяву", бесплатные продукты становятся платными, массовые сокращения в компаниях и так далее.Легко рости когда кредиты околохалявные, а при ХХ% в год - совсем иная ситуация.
Очень грамотный комментарий. Прям приятно было почитать. Пожалуй, со всем соглашусь.Но меня это больше интересует в контексте свобод ПО. Именно сейчас стала понятна ценность GPL (от поклонника Apache 2.0) - невозможность смены лицензии.
А так сейчас все эти компании закроют код и весь этот Open Source схлопнется. Особенно касается базовых технологий.
Что с того что есть какой-то Open Source выше Java (в виде библиотек), если сама Java теперь несвободная. Нижние уровни подрывают всю экосистему.
Тоже подтвержду что так и есть. Гигант где я работаю, впервые в двух десятилетиях начал жить на свои деньги. До этого все вкладывал в развитие, за счет этого поднимал новые инвестиции и жил на них.
>Вот и IBM закрывают "халяву", бесплатные продукты становятся платными, массовые сокращения в компаниях и так далееВсе верно, кроме IBM и халяву. Никогда ни у ibm, ни у redhat небыло бесплатных продуктов. Всякие centos не есть их продукт. Кто сталкивался с тырпрайзом подтвердят. А кто не сталкивался, тем хоть centos, хоть debian, хоть freebsd одинаково полезны. Кто-то там закрывает debian или *bsd? Вот и нечего ныть.
Они всё ещё думают составить конкуренцию докеру.Если в Редхате поскрипели мозгами и придумали как сделать совместимый продукт с кучей плюшек, то Каноникал пилит очередной самобытный велосипед.
Будто от их энтерпрайзного шильдика он станет чуть более нужным.
Им бы с подманом хотябы сконкурировать. До докера со всеми его минусами ему как до луны
Давай в 2023 сравнивать виртуализацию со средством размещения одной приложухи.
> Давай в 2023 сравнивать виртуализацию со средством размещения одной приложухи.Для виртуализации есть libvirt. Или имеется в виду такая "виртуализация" как у OpenVZ?
В смысле до кубера?
С докером то может lxc конкурировать и то кажется там все поделено: для доставки приложений докер, для доставки "систем" lxc. В разных нишах они.
Да и корпораты потихоньку от докера в пользу runc и отдельных сборщиков отказываются.
Зачем Canonical пилить очередной Docker?LXC, LXD - это не аналог Docker, Podman, k8s. И если поймёшь это, то подобную хрень писать не будешь.
> LXC, LXD - это не аналог Docker, Podman, k8s.Не аналог, а велосипед. Контейнеры и libvirt умеет запускать, если надо.
Или предполагается, что это такой убийца OpenVZ? Так они лет на пятнадцать с этим опоздали.
Это не про Docker.
Вот LXD не пользовался.
А Multipass от Canoical прям зашло. Для разработки очень удобно.
Docker для запуска одиночных процессов, а LXD для запуска множества.
Не. Они KVM/QEmu запускают через LXD тоже.А тогда это всего-то обёртка над всеми обёртками. И если обёртка не развита как всё остальное, то лучше брать под конкретную задачу готовые, специально сделанные инструменты оркестровки.
Обвязки над обвязками все делать мастера, тут своего достаточно.
сколько ты задашь процессов, столько и запустятся.
Скорее что, не для, а с расчётом на профит от минимума процессов в контейнере.Но на это из коробки "все" забили. Да ещё прокидывая снаружи внутрь сокеты для выхода за пределы песочницы. Ну и прочие были недостатки у новомодной придумки.
> Docker для запуска одиночных процессов, а LXD для запуска множества.Ничто не мешает в контейнере Docker запустить хоть один процесс, хоть сотню.
Хоть от одного пользователя, хоть от сотни разных.
Посмотри как собраны образы Dovecot или FreeIPA, например.
В Podman сто лет как можно запускать контейнер с systemd, дальше запускай всё, что тебе хочется.
Вопрос только в том, нужно ли использовать контейнеры таким образом.
>> Docker для запуска одиночных процессов, а LXD для запуска множества.
> Ничто не мешает в контейнере Docker запустить хоть один процесс, хоть сотню.
> Хоть от одного пользователя, хоть от сотни разных.
> Посмотри как собраны образы Dovecot или FreeIPA, например.
> В Podman сто лет как можно запускать контейнер с systemd, дальше запускай
> всё, что тебе хочется.
> Вопрос только в том, нужно ли использовать контейнеры таким образом.1) Докер живёт, пока живёт процесс.
2) LXD живёт пока запущен контейнер. Процессы могут жить (пользовательские), а могут помереть, но контейнер сохранит своё состояние и продолжит работуВот, основная разница
>[оверквотинг удален]
>> Ничто не мешает в контейнере Docker запустить хоть один процесс, хоть сотню.
>> Хоть от одного пользователя, хоть от сотни разных.
>> Посмотри как собраны образы Dovecot или FreeIPA, например.
>> В Podman сто лет как можно запускать контейнер с systemd, дальше запускай
>> всё, что тебе хочется.
>> Вопрос только в том, нужно ли использовать контейнеры таким образом.
> 1) Докер живёт, пока живёт процесс.
> 2) LXD живёт пока запущен контейнер. Процессы могут жить (пользовательские), а могут
> помереть, но контейнер сохранит своё состояние и продолжит работу
> Вот, основная разницаСпасибо, коллега.
Только если мне нужен контейнер без процессов, в котором я что-то произвольно запускаю и, судя по всему, тестирую, то мне, наверное, просто нужна виртуальная машина.
Да всем хватит простой дедовской виртуальной машины. Придумали эти контейнеры зачем-то.
> Да всем хватит простой дедовской виртуальной машины. Придумали эти контейнеры зачем-то.Контейнеры понятно зачем придумали, для изоляции процессов и уменьшения накладных расходов.
Запустил, прихлопнул, сохранил только то, что тебе действительно надо.
В автоматизированной среде контейнеры всегда выполняют узкие задачи.
Контейнер без запущенных процессов в общем случае не нужен.
Если мне нужен контейнер без процессов, я собираюсь ковыряться в нём руками и сохранять состояние всего, что там происходит, то скорее всего мне нужен не контейнер.
То что технически можно выстрелить себе в ногу не означает, что так нужно делать. Docker задумывался под изоляцию сервисов между собой. Например, docker logs выводит только один поток логов. Конечно, nginx/apache/postfix плодят дочерние процессы, но это считается одним сервисом. Но между собой эти программы нужно класть в разные контейнеры Docker.
Nginx и Apache плодят дочек, а процессы Dovecot или, например, Rspamd просто запускают другие сервисы. При этом на несколько контейнеров их распилить невозможно. Я уж не говорю, что упомянутый Postfix сравнительно недавно научился писать логи в стандартный вывод, до этого без rsyslog было не обойтись. А Cyrus до сих пор вот не умеет.Понятно, что в идеале в одном контейнере должен работать один процесс. Но полно приложений, которым на это совершенно плевать.
При этом, если у тебя всё в докере, запускать где-то сбоку ещё одного контейнерного демона специально для таких вот случаев вообще не вариант.
> Они всё ещё думают составить конкуренцию докеру.Они думают как создать сообществу мягкую и тёплую среду для разраотки исключительно под вендора Каноникл для исклчительно единственного вендор магазина. Ну, может с MS ещё дуржить будут.
LXD - для запуска и тестов разработок под вендора. Отсюда-то оно и в LXC умеет и в Qemu умеет. И в ком.строке ничего не надо указывать. Просто скачай готовое у папы. Напиши свой код. Опдати папе место в магазине. И продавай.
Ах как я вангую, что такие мысли хоть раз там да проскакивали. Только непонятно, чего тогда жалуются, что у них мало разработчиков, чтобы уметь ответить на вопросы о устройстве пакетов из Дебиан репо.
Поэтому они всячески противились завозу LXD в Debian, перед заморозкой сознательно не фиксили проблему, и сходу закрывали issue, сваливая все на Qemu. Еле достучались до спящего deb мейтейнера, состряпали костыль и в stable оно все-таки пролезло.
Повели Канноникал себя крайне по ред-хатовски, как баги искать, так мы все такие GPL и Apache открытые, а в опенсорс релиз выкатить - сразу игнор перманентный.
А как ещё они себя мягкому софту продадут?
Контейнеры это тупиковая технология.
Тупиковая технология это пересборка мира для установки любой новой программы. Контейнер это лучший из существующих костылей.
Контейнеры это всего лишь эксплуатация фишек ядра Linux: cgroups и namespaces. Как например lvm эксплуатирует подсистему device mapper. А представь скока ещё тайн и нераскрытых фишек таин в себе ядро Linux?
> Контейнеры это тупиковая технология.Ведроид хорошо взлетел.
У Sun когда-то была гениальная идея с Jar и Java. До сих пор идея работает и равивается и развивается в разных видах.
Печально. В тень уходит удобный аналог virsh для контейнеров, по удобству сравним с docker и может его заменить в большинстве случаев. Одна из причин ждать Debian 12 для меня была (помимо исправления бага с буфером обмена в gnome-terminal 3.38).
Не то что б в тень. Но LXD ж засунут в Snap и заставят жить без ~/.* директорий, без остального сообщества, ограниченно и зажато.Узконаправленная, ограниченная среда. Вендор лок.
Скука. Бесполезность.
> Но LXD ж засунут в SnapДавно уже.
Ещё недавно можно было собрать в Deb. Но опасения, что и это закончится. Если такими темпами.Когда люди пишут, что возможность автозапуска при загрузке системы сокрашает время загрузки, то такую ересь не пишут, когда действительно всё хорошо (https://forum.snapcraft.io/t/deploying-robotics-applications...). _Такие_ доводы применяют только от безисходности, при чём-то плохом.
Использую proxmox. По-моему, их pct куда удобнее lxd. С pct я разобрался, один раз глянув в man. А lxd - какой-то инопланетный монстр. Впрочем, как и всё у канониклов.
У них как в скрипты всё не заглянешь, так потом думаешь: надо ли туда к ним или с ними чего-либо.Скорее, что нет, чем да. Но в задумчивость нерешетельности точно вгоняет.
> У них как в скрипты всё не заглянешь, так потом думаешь: надо
> ли туда к ним или с ними чего-либо.
> Скорее, что нет, чем да. Но в задумчивость нерешетельности точно вгоняет.Меньше знаешь -- крепче спишь :) Дети, не заглядывайте в скрипты, а то это вгонит вас в задумчивость! :D
> более оптимально развивать как корпоративный проект, а не проект независимого сообществаКажись, что разумные люди послали их с их подходами и идеями.
Значит больше с ними не по пути.
тебе что ли? ты про lxd только на опеннете в новостях и слышал, иксперд
Не поверишь, в код к ним заглядывал.Не понравилось в сумме. Есть положительное, есть отрицательное. Но в целом это не та вещь, которую раньше чем через лет пять стоит оценивать для полезного применения. Для них - нужно. Они для себя и делают. Для других - нет.
Дистр уходит в нишу, сходную со смартфонами: интернет вещей. Небольшие устройства, с функционалом для продажи, где не хотят чужого вмешательства. Под себя не поточить, без сложностей и сильных трат времени. О чём у Столмана и была претензия к принтеру, когда "всё началось" про OSS.
> Для них - нужно. Они для себя и делают. Для других - нет.Отучайся говорить за всех. Мне нужно, и я на LXD неплохо денег заработал. И ещё заработаю, если подвернётся контракт на эту тему.
Не говори за всех. Кому-то - нужно, кому-то - нет, вместе уже с дистрибутивом.
кто то юзал LXCFS? для чего?
"live-миграцию работающих контейнеров с одной машины на другую"
кто-то может подсказать как это сделать?