Запуск системного контейнера в LXC
В настоящее время я пытаюсь запустить контейнер Arch Linux с использованием LXC на хосте Ubuntu 12.04. Arch Linux недавно перешел на systemd, который, в зависимости от множества мест, имеет некоторые проблемы при работе в качестве гостя LXC. Тем не менее, многие из этих источников существенно устарели, и я видел различные другие источники, предполагающие, что можно запустить гостя на основе systemd, используя такие вещи, как lxc.autodev
или же devtmpfs
,
Поэтому я пытаюсь выяснить следующее:
- Можно ли запустить гостя на основе systemd внутри контейнера LXC (по состоянию на февраль 2013 года)?
- У кого-нибудь есть пример шаблона / конфигурационного файла для использования с ```mkarchroot``, чтобы запустить его?
В настоящее время используется LXC версии 0.7.5, но обновление не должно быть проблемой, если это необходимо.
3 ответа
Отвечая самому себе. Шаблон lxc-archlinux доступен по адресу https://github.com/dotcloud/lxc/blob/master/templates/lxc-archlinux.in но не включает переход на systemd (по состоянию на 15 февраля 2013 г.) .
есть полезная часть rootfs для archlinux (например, http://www.gtlib.gatech.edu/pub/archlinux/iso/2013.02.01/arch/i686/root-image.fs.sfs для i686 также есть 64-битная версия версия)
Я еще не запустил гостевой lxc, но получил функциональный chroot i686 изнутри ubuntu 12.04 x64. 1/ скачайте и распакуйте корневой образ, смонтируйте его где-нибудь.
2 / как root (sudo) cp -ar - корневая файловая система, в которой вы находитесь, и chroot в нее
3 / edit /etc/pacman.conf и обновите строку арки (по умолчанию это auto, которая извлекает ar ch из uname, но ubuntu и arch не используют одно и то же обозначение)
4 / mount / proc / dev / random и /dev/urandom (это необходимо для pacman и pacman-key)
Я не смог заставить pacman работать без правильной настройки подписи пакета
5/ pacman-key --init (здесь нужен хороший источник энтропии)
6 / pacman-key --populate archlinux
7 / опционально: pacman-key --refresh-keys (требуется работающее подключение к интернету)
8 / edit /etc/pacman.d/mirrorlist, чтобы активировать относящиеся к вам зеркала.
9 / pacman -Syy
готов обновить или установить новые пакеты.
Чего (прямо) не хватает, так это запуска контейнера. Я не разбираюсь в systemd, но если я правильно понимаю, это в основном вопрос запуска dbus и systemd.
Я просто наткнулся на твой вопрос. Я использую системные контейнеры под Arch. Я написал несколько заметок в Arch Wiki, объясняющих, как заставить его работать. Вам нужно lxc.autodev
и вам также нужно замаскировать некоторые службы, которые не должны работать внутри контейнера.
Я делаю простой mkarchroot, а затем делаю некоторые изменения (chroot в новый archroot):
ln -s /dev/null /etc/systemd/system/systemd-udevd.service
ln -s /dev/null /etc/systemd/system/systemd-udevd-control.socket
ln -s /dev/null /etc/systemd/system/systemd-udevd-kernel.socket
ln -s /dev/null /etc/systemd/system/proc-sys-fs-binfmt_misc.automount
В вашей конфигурации контейнера вам нужно
lxc.autodev = 1
И, если вам нужно создать какие-либо узлы устройства (вы, вероятно, будете), вам также нужно
lxc.hook.autodev = /path/to/script
плюс файл скрипта
#!/bin/bash
# LXC Autodev hook.
cd ${LXC_ROOTFS_MOUNT}/dev
mknod .....
/path/to/script
местоположение в файловой системе HOST - например /etc/lxc/mycontainer-autodev-hook
,
Согласно вики Gentoo есть шаблон для arch, который частично функционален (подробности см. http://wiki.gentoo.org/wiki/LXC). шаблон может быть старше, чем переход на systemd. исправление / обходной путь включает использование менеджера пакетов Arch pacman. Это нормально с gentoo, мне удалось однажды заставить его работать на Ubuntu, но компиляция - рутина.
шаблон может отсутствовать в пакете lxc, поставляемом с 12.04
если вы перекомпилируете pacman (и его библиотеку поддержки), то вы, вероятно, будете так же хорошо использовать archbootstrap ( https://wiki.archlinux.org/index.php/Archbootstrap), который вдохновлен debootstrap, создающим свой собственный шаблон на основе на дебианском.
Мы успешно развертываем контейнеры LXC на основе systemd на CentOS 7. Трудности, с которыми мы столкнулись, в основном связаны со стандартными обновлениями Linux в целом, такими как /run как tmpfs и /var/run => /run (и некоторые пакеты, требующие, чтобы они быть таким же с внутренними инструментами, использующими оба), и systemd настраивает их автоматически, а не под контролем какого-либо модуля, который мы можем найти и переопределить.
Мы переходим с других методов управления процессами (мониторинг, созданные вручную демоны, периодические проверки через cron), поскольку мы должны касаться этих сервисов по какой-либо причине.