LINUX.ORG.RU
ФорумTalks

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

 , , ,


1

7

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

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

★★★★★

Ответ на: комментарий от vertexua

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

Axon ★★★★★ ()
Последнее исправление: Axon (всего исправлений: 1)

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

drakmail ★★★★ ()
Ответ на: комментарий от Axon

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

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

holuiitipun ()

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

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

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

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

Motif ()

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

George ()

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

xsektorx ★★★ ()

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

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

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

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от Axon

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

kot_otbelivatel ()
Ответ на: комментарий от KRoN73

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

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

Deleted ()
Ответ на: комментарий от KRoN73

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

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

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

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

Axon ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

dvrts ★★★ ()
Ответ на: комментарий от Deleted

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

dvrts ★★★ ()
Ответ на: комментарий от dvrts

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

alozovskoy ★★★★★ ()
Ответ на: комментарий от dvrts

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

alozovskoy ★★★★★ ()
Ответ на: комментарий от alozovskoy

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

Каждый раз, когда ты что-то меняешь изнутри контейнера ты вынужден или терять это изменение, если его не закоммитишь, или множить экземпляры контейнеров, если коммитишь. При этом ты не имеешь возможности обновить исходный образ. То есть, например, ты ставишь образ 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 имеет базу на монтируемом внешнем ресурсе.

KRoN73 ★★★★★ ()
Ответ на: комментарий от dvrts

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

Axon ★★★★★ ()

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

generator ★★★ ()
Ответ на: комментарий от generator

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

Axon ★★★★★ ()
Ответ на: комментарий от Motif

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

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

feofan ★★★★★ ()
Ответ на: комментарий от KRoN73

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

4.2

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

feofan ★★★★★ ()

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

feofan ★★★★★ ()
Последнее исправление: feofan (всего исправлений: 1)
Ответ на: комментарий от feofan

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

Axon ★★★★★ ()
Ответ на: комментарий от Axon

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

man puppet
:)

dvrts ★★★ ()
Ответ на: комментарий от Axon

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

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

feofan ★★★★★ ()
Последнее исправление: feofan (всего исправлений: 3)
Ответ на: комментарий от feofan

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

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

Гемор же.

Axon ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

Deleted ()

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

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

iZEN ★★★★★ ()
Ответ на: комментарий от Axon

У меня так:

> 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

iZEN ★★★★★ ()
Последнее исправление: iZEN (всего исправлений: 3)

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

Axon ★★★★★ ()
Ответ на: комментарий от Axon

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

Axon ★★★★★ ()
Ответ на: комментарий от Deathstalker

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

Axon ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.