Linux контейнери (LXC) на Red Hat / CentOS EL6 - lxc-create vs libvirt?


13

Це складно намагатися залишатися в межах доброї грації 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 як попередній перегляд технологій та пропонує використовувати libvirt для створення та керування контейнерами .

І все ж Oracle виступає за зовсім іншу техніку контейнерної обробки в своєму Unbreakable Linux.

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

  • Яка загальноприйнята мудрість щодо систем, подібних до LXC та RHEL?
  • Як ти їх реалізуєш у своїй організації?
  • Чи є якісь переваги одного підходу порівняно з іншим?
  • Чи можуть ці співіснувати?

1
libvirt має драйвер контейнера LXC і керує ним лише, це не є рішенням щодо віртуалізації / контейнерування як такого.
Крістіан Цюпіту

Відповіді:


7

Яка загальноприйнята мудрість щодо систем, подібних до LXC та RHEL?

Особисто мені здається, що поточні налаштування дещо відсутні. LXC здається більше на перший план - безумовно, більш доглянутою.

Як ви їх реалізуєте?

В плані запропонувати це як варіант віртуалізації я не є. Я вважаю, що нинішні технологічні установки відсутні.

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

Я вважаю це дійсно приємним інструментом для захисту рівня додатків. Ми використовуємо простори імен та групи безпосередньо, щоб містити мережеві та IPC-ресурси для певних веб-додатків, керованих користувачем. Ми надаємо власний інтерфейс для управління ним. У RHEL7 я розглядаю можливість переміщення цієї функції libvirt-lxcяк новішу версію libvirtпідтримки концепції ACL користувачів.

Що стосується віртуалізації з точки зору повністю ініціалізованої системи, я чекаю, щоб заплатити те, що пропонується в RHEL7, але, чесно кажучи, я думаю, що ми можемо побачити достатньо хорошого рішення, коли ми підемо на наступний незначний реліз RHEL7, а потім, можливо лише в стані попереднього перегляду технології.

Слідкуйте за systemd-nspawnтим, що мені підказує протягом найближчих 18 місяців, або, можливо, це може зайняти його місце - найкращий інструмент для повноцінної віртуалізації, що міститься в Linux, будь то так, що системні автори дають зрозуміти, що це не захищено зараз! Я б не здивувався, якщо в кінцевому підсумку libvirtкраплі libvirt-lxcі просто пропонують обгортку systemd-nspawnз визначеними системними скибочками.

Крім того, будьте обережні, що було багато розмов за останні 6 місяців щодо повторної реалізації груп як інтерфейсу програміста ядра, а не інтерфейсу файлової системи (можливо, використовуючи мережеве посилання або щось таке, не перевіряли), тому systemd повинен бути дуже гарячим на хвості, щоб це швидко було зрозуміти.

Чи є якісь переваги одного підходу проти іншого?

Я думаю, що варіант LXC (не libvirt-lxc) краще підтримується. Прочитавши libvirt-lxcвихідний код, він відчуває себе поспіхом. Традиційний LXC, безумовно, має новіші функції, які були краще перевірені. І те й інше вимагає певної сумісності системи init, яка працює в них, але я підозрюю, що ви знайдете LXC трохи більше "під ключ", ніж libvirt-lxcваріант, особливо щодо отримання дистрибутива для роботи в них.

Чи можуть ці співіснувати?

Звичайно, пам’ятайте, що для всіх намірів і цілей обидва роблять те саме. Організація просторів імен, груп та точок монтування. З усіма примітивами займається саме ядро. Обидві lxcреалізації просто пропонують механізм взаємодії з наявними параметрами ядра.


9

Red Hat робить величезний поштовх для контейнера. Вони будують цілий новий продукт, Red Hat Enterprise Linux Atomic Host , навколо нього.

Для менш радикального підходу подивіться їх посібник з управління бета-версією RHEL7 та посібником з контейнерами Linux ; ви помітите, що він штовхає libvirt-lxc і не згадує інструменти lxc.


1
Дякую за це Атомний хост RHEL, схоже, покладається на Docker.io . Чи вказує це, що Докер та пов'язані з ним інструменти - це вірний шлях вперед?
ewwhite

Red Hat, безумовно, вкладає значні кошти в докер, але вони також є первинними розробниками libvirt-lxc. Я розглядаю можливості, які вони надають, і бачу, що краще відповідає вашим потребам.
sciurus

1
Так @ewwhite Цей наступний документ Redhat згадує саме про це: access.redhat.com/articles/1365153
Сусінтіран

1

Виконані файли lxc- * упаковані в пакет lxc в EPEL . Однак це старий реліз "довгострокової підтримки". У lxc-ls навіть немає параметра "-f". Я б просто встановити Ubuntu для своїх хостів LXC.

Спосіб управління LXC RHEL, здається, здійснюється через libvirt-lxc, але він, мабуть, застарів .

Зауважив, що Ubuntu підтримує багато нових розробок lxc / lxd, тоді як Redhat зосереджується на KVM та docker.


Питання пов'язане з RHEL 6, депрекація означає RHEL 7 «Наступні пакети libvirt-lxc застаріли, починаючи з Red Hat Enterprise Linux 7.1:», так що це можна використовувати
taharqa
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.