Контейнеры Linux (LXC) в Red Hat / CentOS EL6 - lxc-create против libvirt?

Сложно пытаться оставаться в пределах благодати Red Hat и при этом планировать долговечность системы ...

Я был сторонником Linux Containers (LXC) более года. Мои первоначальные установки основывались на информации, полученной из онлайн-уроков, таких как этот и этот . Это центрируется вокруг lxc-create, lxc-start|stopи lxc-destroyкоманды и изменение существующих шаблонов OpenVZ .

Это хорошо работает и успешно работает в производстве. Однако я поднимаю некоторые дополнительные системы и решил проверить текущую документацию Red Hat относительно контейнеров в EL6. Я был удивлен, увидев их официальную позицию по этому вопросу.

В Does RHEL 6 обеспечивают LXC инструменты , необходимые для использования Linux Containers? Red Hat описывает LXC как Technology Preview и предлагает использовать libvirt для управления созданием и управлением контейнерами .

Тем не менее, Oracle поддерживает совершенно иную технику контейнеризации в своем Unbreakable Linux.

Кажется, в методе libvirt отсутствуют некоторые функциональные возможности, но мой первоначальный подход с использованием команд lxc- * был немного ручным процессом ... Я не могу точно сказать, что является правильным или "принятым" средством управления контейнерами в EL6 ,

• Каково современное мнение о LXC и RHEL-подобных системах сегодня?
• Как вы реализуете их в своей организации?
• Есть ли какие-то преимущества у одного подхода по сравнению с другим?
• Могут ли они сосуществовать?

Каково современное мнение о LXC и RHEL-подобных системах сегодня?

Лично мне не хватает текущей настройки. LXC, кажется, больше на переднем крае - конечно, больше поддерживается.

Как вы их реализуете?

С точки зрения предлагать это как вариант виртуализации я не. Я считаю, что текущая технологическая установка отсутствует.

• Нет имени пользователя пространства.
• Некоторые точки монтирования не поддерживают пространство имен (cgroups, selinux)
• Значения в / proc вводят в заблуждение системные глобальные переменные, которые не учитывают разделение ресурсов в пространствах имен.
• Перерывы аудита.

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

Red Hat делает огромный толчок контейнеризации. Вокруг него создается новый продукт - Red Hat Enterprise Linux Atomic Host .

Для менее радикального подхода, посмотрите на их RHEL7 beta Resource Management и Linux Containers Guide ; вы заметите, что он запускает libvirt-lxc и не упоминает инструменты lxc.

Исполняемые файлы lxc- * упакованы в пакет lxc в EPEL . Однако это старый релиз "долгосрочной поддержки". У вас даже нет опции "-f" в lxc-ls. Я бы просто установил Ubuntu для своих хостов LXC.

RHEL-способ управления LXC, похоже, заключается в использовании libvirt-lxc, но он явно устарел .

Отмечено, что Ubuntu поддерживает многие новые разработки lxc / lxd, в то время как Redhat фокусируется на KVM и докере.