chroot vs lxc (docker) vs kvm vs etc для установки arch и opensuse на debian-хосте

какую виртуальную среду для гостевых систем лучше выбрать

Зачем виртуально то? Нашинкуй с помощью LVM диск и ставь реально.

Зачем виртуально то?

Чтобы можно было одновременно запускать, не перезагружаясь каждый раз.

А какие серьёзные преимущества от установки нескольких реальных линуксов на одной машине, учитывая, что накладные расходы в контейнерах невелики, а ноут довольно мощный?

(16 Гб RAM с возможностью расширения до 32 гиг и с 4-ядерным i7)

Выбрость этот пятилетний ноут.

Соответственно, какую виртуальную среду для гостевых систем лучше выбрать

А ты что на этих виртуалках собрался делать? Собрался ли запускать приложения? Работать с устройствами и т.д.? И что тебе от арча нужно? Просто юзерспейс? Тут вопросов больше сразу, чем ответов намечается.

никаких

Бери Docker, он удобный. А вообще, от экспериментов зависит. В контейнере у тебя используется ядро основной системы. В случае с kvm, ядро будет гостевой системы.

А ты что на этих виртуалках собрался делать?

Исследовать возможности последних компиляторов (arch) и собирать пакеты (suse).

Бери Docker, он удобный.

Но chroot, насколько я могу судить, легче. Какие преимущества у докера перед чрутом, если пользователь один?

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

Это я знаю, поэтому и спрашиваю. Эксперименты — это компиляция последними компиляторами (arch) и сборка rpm-пакетов (suse).

Если собирать что-то на постоянной основе, то можно сделать docker образ сборщика и когда надо собрать, запускать его. Т.е. надо тебе собрать к примеру пхп из сорцов, и на выходе получить rpm пакет. При нормальном docker образе, это будет docker run, в дире с сорцами php, покинутыми в контейнер. А результатом будет rpm пакет с этим php. Необходимо просто корректно составить докерфайл этого образа. Потом этот докерфайл можно загрузить в гитлаб и настроить job на сборку php в Jenkins. Это если речь о компании. Т.е. кто-то другой потом в Гите глянет твой докерфайл и поймет как ты собираешь свои rpm пакеты с php. Вообщем докер, это ещё и шаг в сторону CI-CD.

Для простых экспериментов — chroot или systemd-nspawn (тот же чрут, но автоматом цепляет proc, dev и всё такое) вполне достаточно.

Тогда чрута за глаза, имхо.

Вообщем докер, это ещё и шаг в сторону CI-CD.

Идею понял. Спасибо за информацию.

chroot или systemd-nspawn (тот же чрут, но автоматом цепляет proc, dev и всё такое)

Спасибо. Отдельное спасибо за упоминание systemd-nspawn. Не слышал о нём, посмотрю.

Тогда чрута за глаза

Понял. Спасибо.

По сравнению с chroot и lxc лучше выбрать второе, так у тебя появится возможность использовать снапшоты lxc

Снапшоты можно и средствами файловой системы сделать.

И какая производительность будет? А если еще и на системном разделе делать то без перезагрузок с livecd не обойтись.

nspawn для таких задач подходит гораздо лучше, чем docker. Там у тебя будет полноценное окружение с системой инициализации (не обязательно systemd), процессом загрузки и выключения, управлением пользователями и т.п.

На docker все это тоже можно сделать (наверно), но все-таки он в первую очередь предназначен для запуска простых контейнеров с одним демоном.

Еще docker устанавливает много своих зависимостей в систему, в то время как nspawn у тебя либо уже есть, либо нужно доставить пару пакетов на пару мегабайт.

в чистом lxc, думаю, нет смысла. И docker и nspawn, по сути, высокоуровневые обертки над ним.

Плюсы kvm - лучшая безопасность (которая в данном случае не особо нужна), минусы - большее потребление ресурсов благодаря запуску 2-го ядра и оверхеду от виртуализации.

Итого, я бы выбрал chroot или nspawn.

windows 10 + ubuntu env

Вообще отличная производительность будет. lxc думаешь, как сам снапшоты делает?

В арче до сих пор старый GCC 8, что-то и арч скатывается...

в чистом lxc ... И docker ..., по сути, высокоуровневые обертки над ним.

Нет. И уже сильно давно как Нет.

Снапшоты можно и средствами файловой системы сделать.

И какая производительность будет? А если еще и на системном разделе делать то без перезагрузок с livecd не обойтись.

Кстати, касательно снапшотов. Читая ЛОР, я часто слышу аргументы в пользу btrfs по сравнению с традиционной ext4, в т. ч. и из-за снапшотов. Но являясь консервативным скептиком, меня не оставляет в покое тот факт, что официально эта ф/с всё ещё не считается стабильной. В Сети очень много информации о btrfs, но в основном это похвалы и дифирамбы, а о недостатках если и пишут, то не больше 3 — 4 строчек. Можешь сказать, какие там могут быть серьёзные подводные камни (кроме проблем с рэйдами), в частности на системном (корневом?) разделе, и почему без перезагрузок с livecd не обойтись? Или речь шла о какой-то другой ф/с?

chroot или nspawn

Да, я тоже склоняюсь к nspawn: вроде как накладных расходов ненамного больше, а преимущества налицо.

lxc [skip] nspawn, по сути, высокоуровневые обертки над ним

Точно? Арч-вики, как я понял, не считает nspawn обёрткой над lxc, а наоборот противопоставляет systemd-nspawn (https://wiki.archlinux.org/index.php/Systemd-nspawn) и lxc-systemd (https://wiki.archlinux.org/index.php/Lxc-systemd).

windows 10 + ubuntu env

Что имеется в виду? Дуалбут или какое-то убунту-окружение внутри десятки? Если второе, то по каким ключевым словам гуглить и есть ли аналогичные окружения для десятки других дистров?

В арче до сих пор старый GCC 8, что-то и арч скатывается...

Других вариантов всё равно нет (если не считать сборки из сорцов в local/bin, но это можно сделать в любом дистре). С другой стороны, новая стабильная версия вышла меньше месяца назад. Если за месяц — 2 она появится в арче, думаю, это не так долго.

какое-то убунту-окружение внутри десятки?

https://ru.wikipedia.org/wiki/Windows_Subsystem_for_Linux

Спасибо за ссылку.

последние компиляторы в debian появляются раньше, чем в арче https://tracker.debian.org/news/1036577/accepted-gcc-defaults-1182-source-int...

А когда захочется экспериментов с драйверами, ничего из перечисленного не подойдёт, и придётся ставить ОС прямо на железо.

последние компиляторы в debian появляются раньше, чем в арче [skip] accepted-gcc-defaults-1182-source-into-experimental/

Ну, если в experimental, то ничего удивительного. :-) Только настолько же стабильна эта ветка, как arch, который, в общем-то, не падает постоянно, разве что отдельные программы иногда глючат, и при обновлениях изредка случаются неприятности?

А когда захочется экспериментов с драйверами, [skip] придётся ставить ОС прямо на железо.

Безусловно. Хотя для экспериментов с драйвером какого-нибудь виртуального устройства может сгодиться и kvm или другая полноценная виртуалка.

Только настолько же стабильна эта ветка

Experimental не является веткой. Это репозиторий с эпизодическими пакетами.

Только настолько же стабильна эта ветка

Experimental не является веткой. Это репозиторий с эпизодическими пакетами.

Суть не в терминах (хотя на сайте debian https://www.debian.org/distrib/packages#search_packages в выпадающем списке дистрибутивов для поиска пакетов среди прочих можно выбрать «экспериментальный» наряду со «стабильным» и прочими ветками), а в том, насколько эта ветка/этот репозиторий стабилен/не стабилен в сравнении с арчем, и сколько раз в день он будет падать. Если в среднем меньше 1 раза в день, то это, имхо, очень неплохо для экспериментального репозитория. Сам я, если честно, с дебиан имею дело довольно давно, но экспериментами с этой веткой ни разу не занимался. Максимум — с testing.

сколько раз в день он будет падать. Если в среднем меньше 1 раза в день, то это, имхо, очень неплохо для экспериментального репозитория

Дистрибутив занимается дистрибьюцией софта, а не его написанием. Поэтому то, что ты пишешь, не имеет смысла.

Дистрибутив занимается дистрибьюцией софта, а не его написанием.

Как будто мейнтейнеры из debian/experimental сами пишут gcc 9 и другие программы, присутствующие в ветке.

Поэтому то, что ты пишешь, не имеет смысла.

Но это не отменяет того факта, что одни дистры или ветки дистров стабильны, а другие — нет. Поэтому смысл-таки есть.

Как будто мейнтейнеры из debian/experimental сами пишут gcc 9 и другие программы, присутствующие в ветке.

Ты пытаешься опровергнуть мои слова словами подтверждения? ಠ_ಠ

Я просто не понял, какие мои слова не имеют смысла:

Суть не в терминах (хотя на сайте debian https://www.debian.org/distrib/packages#search_packages в выпадающем списке дистрибутивов для поиска пакетов среди прочих можно выбрать «экспериментальный» наряду со «стабильным» и прочими ветками)

или

а в том, насколько эта ветка/этот репозиторий стабилен/не стабилен в сравнении с арчем

Поэтому ответил и за те, и за другие.

Стабильность софта определяется софтом, а не дистрибутивом. В дистрибутиве на падения никак повлиять не могут, им неоткуда узнать, будет падать программа или нет. Поэтому обсуждения того, сколько раз в день будет падать, не имеют смысла. По крайней мере, в контексте выбора дистрибутива.

ответил и за те, и за другие

на уголовный жаргон похоже ಠ_ಠ

Стабильность софта определяется софтом, а не дистрибутивом. В дистрибутиве на падения никак повлиять не могут

Теоретически это как бы так. Но на практике мы наблюдаем обратную картину: есть супер стабильная основная ветка debian, есть менее стабильная debian testing и mint, есть глючноватая ubuntu и, наконец, совсем глючная fedora. Есть arch, неплохой для роллинг-дистрибутива (в сравнении с той же федорой), но, конечно, намного менее стабильный, чем debian stable.

Оно и понятно. Ведь новое ПО более сырое, а в дистрах, где всё от всего зависит, эти ошибки умножаются друг на друга. Мейнтейнеры не только собирают ПО, но и создают патчи, устраняя некоторые баги. Однако для написания и тестирования этих патчей тоже нужно время. А иначе и не было бы разницы между дистрами. В конце концов, везде одно ядро (или разные версии одного ядра), один gcc, один gimp и т. д. И чего все спорят об этих дистрах, когда есть просто один единственный GNU/Linux и несколько дистрибьюторов оного?

Собственно, вопрос заключался в том, насколько arch менее глючный, чем debian experimental. Конечно, речь об ощущениях, а не о точных цифрах, если имел дело с experimental.

ответил и за те, и за другие

на уголовный жаргон похоже ಠ_ಠ

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

основной минус btrfs в корневом разделе - то что она может крашнуться к чертовой бабушке, и тебе придется полностью переустанавливать систему. Если хочется использовать btrfs для контейнеров, то либо выдели для этого отдельный раздел, либо создай loop device в файле.

Собственно, вопрос заключался в том, насколько arch менее глючный, чем debian experimental. Конечно, речь об ощущениях, а не о точных цифрах, если имел дело с experimental.

если что-то пойдет не так, то в арче можно одной строчкой в конфиге откатить состояние пакетной базы до нужной даты. См. https://wiki.archlinux.org/index.php/Arch_Linux_Archive

в дебиане такого, кажется, нет. Поэтому, если выбирать между арчем и debian experimental, то конечно арч.

Если хочется использовать btrfs для контейнеров, то либо выдели для этого отдельный раздел, либо создай loop device в файле.

Спасибо за инфу. А крашится она чаще в корне или где угодно (имеется в виду не в теории, — понятно, что любая ф/с может грохнуться, — а на практике)? Т. е. насколько стабильным будет контейнер поверх этой ф/с?

если что-то пойдет не так, то в арче можно одной строчкой в конфиге откатить состояние пакетной базы до нужной даты. См. https://wiki.archlinux.org/index.php/Arch_Linux_Archive

И за эту инфу спасибо. Не знал. Правда, с подобными проблемами пока и не сталкивался.

Расскажи как lxc мне на ext4 сделает снапшот которая не умеет в снапошты.

Самому интересно.

Скорее всего, fsfreeze + cp.

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

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

Тоже верно.