Я собираюсь развеять несколько мифов здесь.
Это просто плохая идея. Мне жаль. - Джейкоб 5 марта в 20:30
Я не понимаю, как это плохая идея. Это действительно просто chroot внутри chroot. С одной стороны, это может снизить производительность каким-то незначительным образом (ничто по сравнению с запуском ВМ внутри ВМ). С другой стороны, он, вероятно, будет более безопасным (например, более изолированным от корневой хост-системы и ее компонентов).
У вас действительно есть реальная причина для этого? Пожалуйста, помните, что вопросы здесь должны касаться реальных проблем, с которыми вы сталкиваетесь. - Зоредаче 5 марта в 21:52
Я согласен на 100% со следующим комментарием автора. Кроме того, я думаю, что можно с уверенностью предположить, что все, кто задает вопрос здесь, вероятно, думают, что у них есть реальная причина сделать это [это] ..
Я думаю, что lxc должен быть в состоянии упростить миграцию виртуальных машин (и резервное копирование + восстановление тоже). Но я не уверен в случаях, когда нет доступа к хост-системе (например, дешевый vps). - Михаил Мар 6 в 11:17
Я действительно столкнулся с этим вопросом еще в июне, когда я впервые погрузился в LXC для проектов PaaS / IaaS, и меня особенно интересовала возможность позволить пользователям эмулировать облачные среды для целей разработки.
LXCeption. Мы слишком глубоко - Том О'Коннор 6 марта в 22:46
Я немного рассмеялся, когда прочитал этот, но это совсем не так :)
В любом случае, после прочтения всего этого, я, в конце концов, настроил среду VirtualBox со стандартной установкой Ubuntu 12.04 LTS Server Edition, полагая, что это на 100% возможно. После установки LXC я создал новый контейнер и установил LXC внутри контейнера с помощью apt-get. Большая часть установки прошла успешно, но в итоге привела к ошибке из-за проблемы с пакетом cgroup-lite, чье задание запуска не удалось запустить после установки пакета.
После небольшого поиска я наткнулся на эту прекрасную статью на stgraber.org (вкусности скрыты в разделе «Вложение контейнера»):
sudo apt-get install lxc
sudo lxc-create -t ubuntu -n my-host-container -t ubuntu
sudo wget https://www.stgraber.org/download/lxc-with-nesting -O /etc/apparmor.d/lxc/lxc-with-nesting
sudo /etc/init.d/apparmor reload
sudo sed -i "s/#lxc.aa_profile = unconfined/lxc.aa_profile = lxc-container-with-nesting/" /var/lib/lxc/my-host-container/config
sudo lxc-start -n my-host-container
(in my-host-container) sudo apt-get install lxc
(in my-host-container) sudo stop lxc
(in my-host-container) sudo sed -i "s/10.0.3/10.0.4/g" /etc/default/lxc
(in my-host-container) sudo start lxc
(in my-host-container) sudo lxc-create -n my-sub-container -t ubuntu
(in my-host-container) sudo lxc-start -n my-sub-container
Установка этой политики AppArmor и перезапуск демона сделали свое дело (хотя не забудьте изменить диапазоны сети!). На самом деле, я подумал, что этот конкретный фрагмент был настолько важен, что отразил его на @ http://pastebin.com/JDFp6cTB на тот случай, если статья когда-нибудь выйдет в офлайн
После этого все sudo /etc/init.d/cgroup-lite startполучилось, и плавание прошло гладко.
Так что, да, можно запустить контейнер LXC внутри другого контейнера LXC :)