Хомячковая контейнерная виртуализация

Все равно docker. Или lxc

Ну, допустим, docker. Как мне без геморроя создать для него контейнер с копией имеющейся ОС? Есть где-нибудь хаутушки для гуманитариев?

Можно взять и обойтись без копии имеющейся ОС

Подпишусь.

Ради неё всё и задумывалось, кагбе.

Btrfs какой-нибудь? Вроде он умеет делать снепшоты и к ним откатываться.

Как мне без геморроя создать для него контейнер с копией имеющейся ОС?

Можно подрубить текущий корень как volume и тупо скопировать всё.

https://www.stgraber.org/2012/03/04/booting-an-ubuntu-12-04-virtual-machine-i...

https://blog.deimos.fr/2014/06/10/migrating-from-kvm-to-lxc-feedbacks/

Если просто ставить дистры, то lxc работает без всяких докеров.

http://help.ubuntu.ru/wiki/руководство_по_ubuntu_server/виртуализация/lxc

А вот с копией системы не все так просто. Задумался. Можно сделать chroot, заархивировав / по типу gentoo stage3. Это получится stage4, как я понимаю. И развернув его в нужном каталоге. Вот только долго получается. Так чтобы одной командой, не видел.

Хм, на ZFS можно делать снапшоты, а потом запускать их как отдельные экземпляры, но это не про линукс пока. О btrfs не скажу, не знаком, возможно тоже можно.

первое, что приходит в голову - это ZFS и снапшоты. но насколько оно хорошо реализовано сейчас в онтопике не скажу, в opensolaris'е с этим 8 лет назад (именно тогда пробовал) никаких проблем не было.

для виртуалок есть virt-p2v, к слову

Виртуалки - плохой вариант: слишком большой оверхед, не очень быстрое развёртывание, тормозной гуй.

Если тебе гуй, то всё равно виртуалки.

Без гуя — у LXC оверхед очень маленький, стартуют контейнеры за несколько секунд. У Docker оверхед такой же, стартуют контейнеры обычно за секунду.

По затратам памяти — у LXC контейнер жрёт как цельная система. Т.е. для каких-нибудь Ubuntu/Debian без GUI — 250..300Мб. Потом растёт мало, сколько софта добавишь.

У Docker каждая копия контейнера жрёт мало, но вот каждый образ — много. Получается, что если тебе надо иметь несколько уникальных автономных контейнеров, то выгоднее LXC. Если много типовых, не меняемых изнутри — то выгоднее Docker.

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

Как мне без геморроя создать для него контейнер с копией имеющейся ОС?

Это задача не для Docker. Решить-то можно, но выгоднее делать это в LXC. Я для себя вывел простую эмпирику. Если при работе с Docker-контейнером нужен ssh, чтобы залезть внутрь и требуется сохранять результат (по умолчанию Docker-контейнеры не персистентны, остановил его, запустил — всё сбросилось в исходное состояние), то я Docker использую не правильно и нужно или решение пересмотреть, или перейти на LXC.

У Docker каждая копия контейнера жрёт мало

Никто не запрещает в lxc использовать клоны-снапшоты с aufs или overlayfs, будут такие же компактные, как в докере.

Ещё у lxc интерфейс имхо человечнее. Что за чучело придумало, чтобы каждая команда docker run создаёт отдельный контейнер, а потом этими мёртвыми контейнерами всё завалено? Это вот как в VCS бы при каждой правке файла создавалась отдельная ветка с именем wpoi34-9q83-370r9qufpizdecblat. И кругом сплошные грабли. Создать 32-битный контейнер на 64-битном хосте? Для lxc ноль проблем, docker говорит «Я НИУМИЮ ЛАЛ)))». Потому что он пытается внутри контейнера запустить свой бинарник для своей сраной магии. Shell-скрипты - это же так не по-хипстерски, блеать, то ли дело бинарник на Go, ёбана. Если запущен OpenVPN - docker вообще отказывается запускаться, потому что не может себе найти свободный IP. Глобальный, надёжный, «Huhak Huyak & VProduction» edition. Настолько уёбищен, что даже не удивляет, почему он так популярен.

то я Docker использую не правильно и нужно или решение пересмотреть, или перейти на LXC.

а мне казалось, что lxc (хоть стендэлон версия, хоть докеровская) суть есть для запуска одного аппликейшена. т.е. если требуется внутрях еще и ссх, то нужно уже решение пересматривать в пользу полноценной виртуалки. другими словами - это не средство виртуализации, а средство изоляции.

Если тебе гуй, то всё равно виртуалки.

Почему? LXC не позволяет поднять иксы на отдельном vt?

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

Мне тоже пока так показалось. Тем больее, что в rootfs lxc можно без проблем скопировать что угодно.

docker/lxc

man ansible

Получается, что если тебе надо иметь несколько уникальных автономных контейнеров, то выгоднее LXC. Если много типовых, не меняемых изнутри — то выгоднее Docker.

Не совсем понял откуда такие выводы. Docker - по сути высокоуровневая обёртка над LXC.

Неверный вывод. Openvz - по сути архитектурный аналог lxc ведь используется не только для «изоляции» как ты выразился.

С aufs проблем не больше.

systemd-nspawn?

Не совсем понял откуда такие выводы. Docker - по сути высокоуровневая обёртка над LXC.

Логика работы. Docker — это достаточно узкоцелевая обёртка.

Если много типовых, не меняемых изнутри — то выгоднее Docker.

Поясни, пожалуйста, что имеется под «не меняемых изнутри»? Все файлы внутри контейнеров должны быть одинаковые? Или просто будет одна система, а контейнеры «хранят» изменения относительно этого шаблона?

Ansible поможет развернуть систему на основе готового образа, но образ системы ТСу делать самому, а в случае разового (если можно так сказать) создания контейнеров можно это сделать и руками.

Поясни, пожалуйста, что имеется под «не меняемых изнутри»?

Каждый раз, когда ты что-то меняешь изнутри контейнера ты вынужден или терять это изменение, если его не закоммитишь, или множить экземпляры контейнеров, если коммитишь. При этом ты не имеешь возможности обновить исходный образ. То есть, например, ты ставишь образ Ububtu 14.04 LTS. Ты не можешь обновить базовый образ — после apt-get upgrade и коммита изменений ты получишь копию. На диске будут храниться и оригинальный, не обновлённый образ и накопившиеся изменения. Если у тебя контейнеров на Ubuntu несколько и в каждом свои мелкие изменения (в одном конфиг nginx'а подкрутил, в другом php иначе настроен, я каждого ещё и hostname вручную указан в /etc), то каждый контейнер надо обновлять вручную и хранить все эти изменения. В итоге получается ад и каша. И тут лучше просто поставить LXC и не мучиться, использовать каждый контейнер как самостоятельный виртуальный комп. И обновлять его можно как хочешь самостоятельно, и с компа на комп переносить... В общем, полноценный виртуальный хост.

А вот работу с Docker лучше строить на принципе невмешательства в содержимое образа контейнера. Например, качаешь образ nginx — и всё. Конфигурируешь его снаружи, монтируя внешний конфиг на место внутреннего, монтируя свой /var/www в его /usr/share/nginx и т.п. В результате, когда потом обновится образ nginx, то он спокойно обновится для всех случаев работы с ним разом. А вот если ты полез что-то менять внутри ручками, то обновить его снаружи ты уже не сможешь, тебе придётся накатывать все эти изменения в новый контейнер по новой.

А обнаружить такое нарушение легко — если тебе хочется что-то поменять внутри одиночного применения контейнера (в частности, если тебе нужен ssh, например) — то что-то в использовании не так. Понятно, это не распространяется на случай, когда ты делаешь свой собственный образ, который потом многократно используешь. И то в этом случае лучше всё делать через Dockerfile.

Ещё пример идеологической разницы. LXC — это полноценная виртуальная система. Например, сайт из nginx + php + mysql... Законченный хост, который можно таскать между физическими машинами и т.п.

Docker же заточен под использование отдельных приложений. Один образ/контейнер с nginx. Он, когда нужно, обращается с другому образу/контейнеру с php-fpm. Тот, если нужно, лезет на контейнер с MySQL. И все эти образы иммутабельны, не сохраняют состояние. Тот же MySQL имеет базу на монтируемом внешнем ресурсе.

Если это, по-вашему, быстро и легко, то ваше «сложно и долго» я даже представить боюсь...

А vagrant не пробовал? Хоть и виртуалки, но процесс деплоя довольно быстрый. И свой образ можно создать с чем угодно без проблем.

Это как с китобойным гарпуном на кильку охотиться, IMHO. И виртуалки не катят вообще.

Хм, на ZFS можно делать снапшоты, а потом запускать их как отдельные экземпляры, но это не про линукс пока.

4.2. Вполне про линукс.

Если тебе гуй, то всё равно виртуалки.

4.2

Даже стим успешно запускается с помощью lxc

ТС, рекомендую остановиться на связке zfs + lxc. Всё очень удобно. Если возникнут вопросы, могу проконсультировать. Мы, правда, используем эту связку не только на локалхосте.

Корневую fs ради этого менять не хочется, так что обойдусь, пожалуй, без zfs. Я бы предпочёл завернуть корень в файл с образом, подмонтировать его в лупбек и запустить в lxc. Пока разбираюсь с такой схемой.

то ваше «сложно и долго» я даже представить боюсь...

man puppet
:)

можно просто использовать

mount -o ro,bind ...

Как я в ro экспериментировать-то буду?

А при экспериментах менять нужно весь корень?

Подсказка: man aufs. Но порой быстрее таки скопировать.

А при экспериментах менять нужно весь корень?

Подсказка: man aufs.

Гемор же.

Try upgrading to a human brain.

Это задача не для Docker. Решить-то можно, но выгоднее делать это в LXC. Я для себя вывел простую эмпирику. Если при работе с Docker-контейнером нужен ssh, чтобы залезть внутрь и требуется сохранять результат (по умолчанию Docker-контейнеры не персистентны, остановил его, запустил — всё сбросилось в исходное состояние), то я Docker использую не правильно и нужно или решение пересмотреть, или перейти на LXC.

SSH - плохая практика, так как требует запущенного демона, что уже сильно противоречит идее один контейнер - одно приложение. Поэтому принято использовать nsenter с хостмашины.
Правда не все согласны с таким подходом

Wat?

Что сейчас лучше всего подходит для такого юзкейса?

chroot(8), jail(8), bhyve(8) — на любой вкус на FreeBSD.

У меня так:

> cat /etc/fstab.buildserver 
/usr/src         /var/jail/buildserver/usr/src               nullfs  ro        0       0
/usr/obj         /var/jail/buildserver/usr/obj               nullfs  ro        0       0
/usr/ports       /var/jail/buildserver/usr/ports             unionfs rw,below  0       0
/store/distfiles /var/jail/buildserver/usr/ports/distfiles   nullfs  rw        0       0
/store/pckgs64   /var/jail/buildserver/usr/ports/packages    nullfs  rw        0       0
/usr/local	 /var/jail/buildserver/usr/local             unionfs rw,below  0       0
/var/db/pkg      /var/jail/buildserver/var/db/pkg            unionfs rw,below  0       0

Просто любопытно - насколько «копия» существующей системы тебе нужна? Сотни гигабай HD-порнухи^Wценных данных из хомяка входят в копию? Образы виртуалок из /var/lib/libvirt/images?

Только корневая fs без шелухи. Из хомяка - разве что, некоторые конфиги, которые можно и ручками перенести.

ИМХО, тебе проще будет поставить свежую систему, накатить поверх нее нужные пакеты, и скопировать /etc.

Чем это, мне проще забить на эксперименты...

OpenVZ

Как мне в пару команд склонировать хостовую систему в контейнер? Что там с работой гуя в госте?