Сложно оставаться в милости Red Hat и при этом планировать долговечность системы ...
Я был сторонником Контейнеры Linux (LXC) больше года. Мои первоначальные установки были основаны на информации, полученной из онлайн-руководств, таких как вот этот и вот этот. Это было сосредоточено вокруг lxc-create, lxc-start|stop и lxc-destroy команды и изменение существующих Шаблоны OpenVZ.
Это хорошо работает и успешно работает в производстве. Однако я поднимаю некоторые дополнительные системы и решил проверить текущую документацию Red Hat, касающуюся контейнеров в EL6. Я был удивлен, увидев их официальную позицию по этому поводу.
В Предоставляет ли RHEL 6 инструменты LXC, необходимые для использования контейнеров Linux?, Red Hat описывает LXC как Предварительный просмотр технологий и предлагает использовать libvirt для управления созданием контейнеров и управления ими.
И все же Oracle выступает за совершенно иную технику контейнеризации в своем Unbreakable Linux.
Похоже, что в методе libvirt отсутствуют некоторые функции, но мой первоначальный подход с командами lxc- * был чем-то вроде ручного процесса ... Я не могу точно сказать, что является правильным или "приемлемыми" средствами управления контейнерами на EL6 .
Red Hat делает огромный толчок контейнеризации. Они создают совершенно новый продукт, Red Hat Enterprise Linux Atomic Host, вокруг него.
Для менее радикального подхода взгляните на их бета-версию RHEL7 Руководство по управлению ресурсами и контейнерам Linux; вы заметите, что он нажимает libvirt-lxc и не упоминает инструменты lxc.
Что сегодня думают о LXC и RHEL-подобных системах?
Лично я считаю, что текущая установка несколько не хватает. LXC кажется более передовым - определенно более поддерживаемым.
Как вы их реализуете?
Я не предлагаю это в качестве варианта виртуализации. Я считаю, что нынешняя технологическая установка отсутствует.
Однако я считаю, что это действительно хороший инструмент для сдерживания на уровне приложений. Мы используем пространства имен и контрольные группы напрямую, чтобы содержать сетевые ресурсы и ресурсы IPC для определенных пользовательских веб-приложений. Мы предоставляем собственный интерфейс для управления им. В RHEL7 я рассматриваю возможность переноса этой функции в libvirt-lxc как новые версии libvirt поддерживают концепцию пользовательских ACL.
Что касается виртуализации с точки зрения полностью инициализированной системы, я жду, чтобы узнать, что предлагается в RHEL7, но, честно говоря, я чувствую, что мы сможем увидеть достаточно хорошее решение только тогда, когда перейдем к более позднему второстепенному выпуску RHEL7, а затем, возможно, только в состоянии предварительного просмотра технологии.
Не спускай глаз с systemd-nspawn что-то подсказывает мне, что в ближайшие 18 месяцев или около того, это может занять его место, это лучший инструмент для реализации виртуализации, полностью содержащей Linux, даже если авторы systemd ясно дают понять, что сейчас это небезопасно! Я не удивлюсь, если libvirt капли libvirt-lxc в конце концов и просто предлагает обертку вокруг systemd-nspawn с определенными срезами systemd.
Кроме того, будьте осторожны, за последние 6 месяцев было много разговоров о повторной реализации cgroups в качестве интерфейса программиста ядра, а не интерфейса файловой системы (возможно, с использованием netlink или чего-то еще, не проверял), поэтому systemd должен быть очень горячим на хвосте того, чтобы сделать это очень быстро.
Есть ли преимущества у одного подхода перед другим?
Я думаю, что вариант LXC (а не libvirt-lxc) лучше поддерживать. Прочитав libvirt-lxc исходный код, он кажется поспешным. Традиционный LXC, безусловно, имеет новые функции, которые были лучше протестированы. Оба требуют определенной степени совместимости со стороны запущенной в них системы инициализации, но я подозреваю, что вы найдете LXC немного более готовым к работе, чем libvirt-lxc вариант, особенно в отношении того, чтобы заставить дистрибутивы работать в них.
Могут ли они сосуществовать?
Конечно, помните, что оба они делают одно и то же. Организация пространств имен, контрольных групп и точек монтирования. Все примитивы обрабатываются самим ядром. Обе lxc реализации просто предлагают механизм взаимодействия с доступными опциями ядра.
Исполняемые файлы lxc- * упакованы в lxc пакет в EPEL. Однако это старый релиз с «долгосрочной поддержкой». У вас даже нет опции "-f" в lxc-ls. Я бы просто установил Ubuntu для своих хостов LXC.
RHEL способ управления LXC, кажется, через libvirt-lxc, но это очевидно устарел.
Отмечено, что Ubuntu поддерживает многие новые разработки lxc / lxd, в то время как Redhat делает упор на KVM и докере.