Контейнерная виртуализация

Скорее всего тут дело в излишне либеральных дефолтных настройках контейнера всё-таки.
В общем-то подобная возможность по незнанию выстрелить себе в ногу это и есть одна из компонент «сырости» LXC о которой постоянно говорят.
Но некоторым фанатикам неймётся побыстрее закопать недостаточно трушный OpenVZ вот они и агитируют оголтело за LXC.

XEN в контейнере? Это вообще как?

Это iZEN

Так ты назовешь преимущества-то?

Когда я последний раз смотрел kvm, там требовалась уйма ручной работы (включая использование готового образа инсталлятора) при создании виртмашины вместо одной строчки lxc-create + была масса жалоб на использование общей виртуальной памяти. Это кроме большего оверхеда у kvm.

Как сейчас — не знаю. Но беглый гуглёж показывает, что менялось мало.

Если можно поставить виртуальную машину одной командой — напиши, введу, посмотрю, в чём ещё разница. А качать вручную образы и ставить инсталлятором на удалённой машине — ломает.

Если можно поставить виртуальную машину одной командой — напиши, введу, посмотрю, в чём ещё разница. А качать вручную образы и ставить инсталлятором на удалённой машине — ломает.

# virt-install -n ubuntu -r 2048 --os-type=linux --os-variant=ubuntulucid --disk /var/lib/libvirt/images/ubuntu.img,device=disk,bus=virtio,size=8,sparse=true,format=qcow2 -w bridge=br0,model=virtio --vnc --noautoconsole --location http://mirror.yandex.ru/ubuntu/dists/lucid/main/installer-amd64/

Либо создаешь темлпейт и делаешь клон, тоже одной командой.

Это кроме большего оверхеда у kvm.

Ты правда думаешь, что +10 метров озу критичны? А как же тесты и исследования оверхеда? С конкретными примерами?

# ...
Начинается установка...
Получение файла MANIFEST...
Получение файла MANIFEST...
Получение файла linux...
Получение файла initrd.gz...
Создание домена...
Domain installation still in progress. You can reconnect to 
the console to complete the installation process.
...
# virsh console ubuntu
Выполнено подключение к домену ubuntu
Escape character is ^]

И тишина. Машина простаивает, дисковых операций ноль.

Ты правда думаешь, что +10 метров озу критичны?

Да нет, народ не на ОЗУ жаловался, а на дисковую и сетевую активность. В смысле, падение производительности.

Тогда большой плюс LXC, а в чем его менее продакшенность?

В LTS ядрах он старый и больной. А кастомные ядра на продакшене как-то стрёмно ставить.

Под OVZ надо либо CentOS, либо Proxmox, чтобы не париться. Но Proxmox недавно скурвился.

Для LXC по-моему надо ждать весны, когда выйдет убунта 14.04 LTS, либо дебиан соответствующий. Надеюсь, там LXC станет годным хотя бы для «внутренних» нужд (не хостинг).

И тишина. Машина простаивает, дисковых операций ноль.

Да, ибо дальше vnc и чистая установка. Такова суть полной виртуализации. Если хочется в один клик - то только через virt-clone с уже готовой виртуалки.

Да нет, народ не на ОЗУ жаловался, а на дисковую и сетевую активность. В смысле, падение производительности.

С этим все ок давно, ибо virtio допилили.

Да, я тоже предполагаю LXC на 14.04 использовать.
А пока поставил на 13.10 из репы версию 1.0.0.alpha1 потестить - ищу баги.

С этим все ок давно, ибо virtio допилили.

а с какой версии читать чендж логи, не подскажешь?

Да, ибо дальше vnc и чистая установка.

Вот это и есть извращения.

Такова суть полной виртуализации.

Поэтому я и выбираю LXC :)

Изоляция окружений LXC задействует общий SWAP, так что будь начеку. ;)

К ней веб-панельки уже сочинили какие-нибудь? Желательно с бекапами и хотя бы оффлайновой миграцией.

Если не сочинили, то возможно проще будет через докер.

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

Сходу: http://lxc-webpanel.github.io/

^)

Она убогая совсем. Не серьезно это.

хоть что-то.
А что ты хочешь от веб-панельки? (кроме бекапов и миграции)

Под OVZ надо либо CentOS, либо Proxmox, чтобы не париться. Но Proxmox недавно скурвился.

Имею опыт OVZ под бубунтой и гентой.
Не парясь.
Proxmox ненужно.

Больше ничего. Ну несколькими серверами рулить, само собой (без этого миграцию не сделать).

Просто без бекапов и миграций будет такой пионерлагерь, что даром не надо.

Ручками собирали или уже ppa есть?

Это можно под убунтой без приключений развернуть, так же просто как proxmox, с аналогичным набором фич?

ручками, ибо нужно было ovz+zfs. а так вроде есть.

без вебморды = без приключений.

вебморда = https://github.com/zed-0xff/ovz-web-panel (руби, рельсы, приключения)

Конструктор - не то. И так хватает, над чем думать.

А вебморда вообще адекватная? Есть смысл автора продонатить, чтобы LXC привернул и косяки зачистил?

А вебморда вообще адекватная?

Более-менее. Местами сыровато.

Есть смысл автора продонатить, чтобы LXC привернул и косяки зачистил?

Под LXC морда 5ю постами выше. Слепить их вместе - проще новую написать, либо поискать универсальную.

С какой хочешь :)

Да я хотел узнать когда виртио допилили и в какой версии )

Ну, в убунте нет user namespaces. А еще, руление ограничениями для контейнеров через apparmor это, простите, полная хрень. Я вообще не понимаю, как такая сырая говноподелка смогла попасть в апстрим, при этом выкинув оттуда openvz. А с переходом всех на systemd там вообще костыль на костыле.

Имхо мое такое, нормальных контейнеров в ядре на данный момент нет.

Что-бы выкинуть что-то из апстрима его туда нужно сначала вкинуть. OpenVZ в ванильноим ведре отродясь не было.

Беда в том что вы, как и многие, рассматриваете LXC как продукт, как нечто законченное и целостное. Но это не так, LXC это набор ядерных фич и одноименная утилита. На основе этих фич в будущем будет создан продукт (и не один).

Почему вы не возмущаетесь тому что в ядро пустили chroot? Ведь он не изолирует вообще ничего кроме ФС, явное решето.
LXC это набор неймспейсов на подобие chroot-а только для других элементов ядра (плюс cgroup и утилита для конфигуряния). Каждый из неймспейсов хорошо выполняет свою функцию, но их совокупности пока-ещё недостаточно что-бы покрыть все потребности контейнерной виртуализации.

Имел двухчасовой интересный разговор с автором вебпанельки. Если сможете сформулировать «сыроватости», постараюсь учесть в следующем milestone.

Пока договоренность в том, чтобы «сбросить оковы» и сделать по весне то, что надо «прастым пасанам». На основе LXC 1.0+

Могу побыть тестером, а пока получаю время от времени 500ку в браузер, при различных запросах (настройка сети, изменения настроек работающего контейнера)

мусор в контейнерах вполне виртуален...

Почему вы не возмущаетесь тому что в ядро пустили chroot?

Потому что chroot является законченным продуктом в отличии от.

Каждый из неймспейсов хорошо выполняет свою функцию

Пример с убунтой 13.10 и выключением хост-машины из контейнера выше.

Надо еще понимать, что есть как минимум 2 версии lxc первая - собственно lxc, вторая - то что в libvirt называют lxc. Набор фич и глюков у них разный, причем судя по моему опыту - версия от libvirt глючнее оригинала. Но это может в debian он кривой, а в rhel - няшный.

Потому что chroot является законченным продуктом в отличии от.

Т.е. chroot законченный продукт, а chroot + набор аналогичных «чрутов» для других элементов ядра это уже кака, потому как не поддерживает make pizdato?

Пример с убунтой 13.10 и выключением хост-машины из контейнера выше.

Значит в ведре той убунты либо небыло инструмента прикрывающего нужные ручки, либо он не был сконфигурирован.

Ещё раз повторю: ты смотришь на lxc как на законченный продукт типа нажми на кнопку получишь результат, а это всего-лишь совокупность ядерных фич которые со временем позволят получить такой продукт.
Короче дуракам половину работы не показывают. Но в случае LXC её зачем-то показали, и часть дураков (которым не терпится закопать «не трушный» OpenVZ) принялись проповедовать LXC на всех углах. А другие дураки им поверили и принялись сравнивать разрабатываемый инструментарий с состоявшимся продуктом.

В принципе иметь профит от LXC можно уже сейчас, если понимать что это такое. У меня на домашнем сервачке часть сервисов загнана в lxc контейнеры, не столько для безопасности (хотя от каких-то сценариев (боты и юные ксакепы которые просто не знают про lxc и не попытаются его обойти) и этого хватит), а просто что-бы не валить всё в одну кучу и иметь возможность легко перенести сервис на другую хостовую ОС.

Надо ещё понимать что LXC един в трёх лицах:
lxc это юзерспейсовая утилита конфигуряющая:
lxc — набор функций ядра, и всё это разработано в рамках проекта под названием:
lxc.

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

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

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

LXC на данный момент это набор костылей и подпорок, причем в разных дистрибутивах, абсолютно с разной функциональностью. Но продвигается он, как супер-решение, прямо замена vserver и openvz. Из-за чего последние выкинуты из большинства дистрибутивов. Но по-факту это просто говноподелка на данный момент, и место ей в каком-нибудь бренче, а не в апстрим ядре.

Значит в ведре той убунты либо небыло инструмента прикрывающего нужные ручки, либо он не был сконфигурирован.

Это связано с системой инициализации upstart. И, кстати, переход на systemd только создаст еще больше боли для LXC. Почему? Потому что root в контейнере слабо (никак?) не изолирован от root в хост-системе. Username::Namespaces вообще настолько сырые, что в 32 битном ядре убунты даже не собраются (поэтому есть только в 64-битном ядре).

просто что-бы не валить всё в одну кучу и иметь возможность легко перенести сервис на другую хостовую ОС.

Так в этом смысл контейнеров и есть.

Просто вот пример чуть подробнее. У меня 32-битная убунта на ноуте, мне надо собрать одну вещицу с GitHub. Я создаю контейнер, с таким же набором библиотек и софта, чтобы доставить компилятор и там все собрать (дабы не мусорить пакетами в основной системе). В итоге я получаю, что 13.10 из шаблона в контейнере не дает консоль и ребутит мой ноут. WTF? К слову сказать, debian работает прекрасно (да и 13.04 тоже). Ок. Тогда я подумываю о OpenVZ, опыт есть и все такое. Но из репозитория его не поставить. Ну и что мне делать? Ядро пересобирать ради компиляции приложения в контейнере? В итоге, пришлось ставить все библиотеки, компилятор в основную систему, собирать и потом все это удалять. Была бы возможность запустить kvm так бы и сделал, но ее нет, openvz и vserver отняли, зато есть не полностью работающий LXC.

На сколько мне известно libvirt для работы с lxc контейнерами использует родную утилиту lxc

Скорее liblxc какую-нибудь.

И да, спорить не буду, тут часть вины Ubuntu.

Но продвигается он, как супер-решение, прямо замена vserver и openvz.

Меньше слушай ЛОРовцев бледных со взглядом горящим. Рассказы про то что lxc уже сейчас может заменить OpenVZ я слышал только от них. Адекватные люди говорят об lxc как о перспективной технологии.

Ядерная часть это набор самостоятельных фич каждая из которых всё-таки достаточно работоспособна что-бы её в ядро приняли (и таки-кто вам сказал что в ванильном ведре только суперстабильны код?).
Если-бы дебилов которые считают chroot полноценной изоляцией было-бы больше ты бы требовал его исключения из ядра?

По поводу выпила openvz из репов бубунты: на сколько мне известно дебиановцы просто задолбались тянуть зоопарк ядер и выкинули всю экзотику. Убунта основана на пакетной базе дебиана, так-что и она осталась без экзотики.
Пользователям OpenVZ остаётся только со стонами и плачем подключать к системе репозиторий OpenVZ (по идее к бубунте он должен подойти).

Нет, не так

есть возможности ядра, называются они по разному, основная называется namespaces.

lxc и в виде отдельной утилиты, и в виде libvirt использует одни и те же возможности.

libvirt не использует утилиту lxc, все конфигурирование ядра в нем делается своими силами.

Возможно у меня просто устаревшие сведения. А может просто неверные.

Нэйсмпэйсы это, строго говоря, набор обособленых фич, а не одна фича.

Дабы не плодить темы спрошу тут:

У меня не работает бриджинг lxc виртуалок с реальной сетевой картой

lxc виртуалка <---> br0 <---> eth0

настройки хоста

root@ubuntu-lxc:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto br0
iface br0 inet dhcp
        bridge_ports eth0
        bridge_fd 0
        bridge_maxwait 0

Настройки гостя

root@ubuntu-lxc:~# head /var/lib/lxc/zimbra/config
# Template used to create this container: /usr/share/lxc/templates/lxc-ubuntu
# Parameters passed to the template:
lxc.network.type = veth
lxc.network.hwaddr = 00:16:3e:75:66:be
lxc.network.flags = up
lxc.network.link = br0
lxc.network.veth.pair = veth0
lxc.network.ipv4 = 192.168.137.28/24
lxc.network.ipv4.gateway = 192.168.137.3
lxc.rootfs = /var/lib/lxc/zimbra/rootfs

net.ipv4.ip_forward=1 - есть

dvrts
и
vel

Завтра подумаю, не сегодня.

на работу бриджа может влиять iptables если есть /proc/sys/net/bridge/bridge-nf-call-iptables с ненулевым значением. Обычно arp при этом работает, а все остальное - нет.

Что говорит на хосте «brctl showmacs br0» после запуска lxc.

У контейнера при запуске нет проблем с сетью ? Если зайти через lxc-console, то с сетью все нормально ?

потести этот форк https://github.com/zed-0xff/ovz-web-panel

Хабр прям разродился статьями про контейнеры. Лор что ли читают.

Ага: http://habrahabr.ru/post/208746/

Вывод: LXC ещё не готов.

Ага: http://habrahabr.ru/post/208746/

Вывод: хабр такой хабр.

Криворукая шваброшваль для изеньки — авторитет, да.

Ну, к слову, брат анон, стоит признать, что изе тут есть чему радоваться. Однако в их этом бдсм есть только jail, так что я бы на его месте все-таки плакал.

c: the undedo

Скоро: http://bhyve.org/faq/