LXC (Linux Containers) — так ли все прекрасно на самом деле?

На просторах Интернета можно встретить не одну статью, где нахваливают LXC и утверждают, что за этой технологией будущее. Я уже в третий раз сажусь поизучать текущий статус и каждый раз выясняется множество нюансов. Первая попытка была где-то года полтора или два назад, вторая — после релиза Debian 7, третья — на этих выходных. Причина в том, что Debian/Ubuntu мне нравятся на порядок больше, чем CentOS/RHEL. Но к сожалению, в плане контейнерной виртуализации (в частности OpenVZ) в Debain/Ubuntu стало совсем печально в последних релизах. В том числе и благодаря более активному продвижению LXC. Собственно, LXC так LXC — лишь бы решало нужные задачи. Я не являюсь хостером и такой виртуализацией пользуюсь в основном ради целей разработки, тестирования и для работы некоторых собственных проектов.

Забегая вперед могу сказать, что третья попытка опять оказалось неудачной. LXC все еще выглядит крайне сырым, даже для внутренних нужд, не говоря о коммерческой эксплуатации. Причины — ниже.

Подопытные кролики

В ближайшее время обещан релиз LXC 1.0. Кроме того, в апреле выходит очередная LTS Ubuntu — 14.04 (с длительной поддержкой). Вооружившись Debian 7, Ubuntu 12.04 и Ubuntu 13.10 я пошел смотреть прогресс и текущее состояние. Местами будут сравнения с OpenVZ. Это связано с тем, что хотелось ради эксперимента попробовать заменить один из серверов с OpenVZ-контейнерами на LXC-контейнеры.

Debian 7

Версия LXC — 0.8.0-rc1.

Наиболее яркий момент, который запомнился с прошлого раза — шаблон контейнера Debian 7 не работал из коробки в LXC на Debian 7. В коммерческой разработке такого рода проблемы обычно считаются show stopper'ами. Не смотря на 3-ий апдейт воз и ныне там. Если заглянуть в /usr/share/lxc/templates/ и попробовать другие шаблоны, то выясняется что fedora не хватает yum'а, opensuse не хватает zypper, ubuntu-cloud хочет ubuntu-cloudimg-query, а если попробовать altlinux, то радостно сообщают, что у нас не ALTLinux host. Собственно для того же шаблона Debian 7 предлагается искать починенный и качать его, либо пробовать чинить самому. Для OpenVZ на сайте есть репозиторий с официальными и неофициальными шаблонами — и это очень удобно. Для Vagrant есть www.vagrantbox.es но он пугает ссылками на Dropbox и Google Drive. Можно надеяться на честность, а можно легко получить протрояненную ОСь. Для LXC на данный момент либо то, что в дистрибутиве, либо рыскать по просторам интернета (то есть даже меньше, чем для Vagrant).

Ubuntu 12.04

Версия LXC — 0.7.5

Версия по-старее по понятным причинам. Зато контейнер с Ubuntu создается без проблем.

Пробуем попользоваться backup/restore'ом. Бэкап создается с помощью копирования содержимого rootfs в /var/lib/lxc/ct-name/rootfs.backup1 Вроде бы принято все-таки архив создавать, а не просто тупо копировать в соседнюю директорию. Если я надумаю копировать бэкапы на другой хост, то буду вынужден сам делать архивы. На сайте Ubuntu касательно LXC и backup/restore можно вычитать рекомендацию не пользоваться этим функционалом. Неожиданно.

Еще один момент, который интересовал — миграция контейнеров, хотя бы offline. Ведь одно из удобных преимуществ виртуальных машин является их легкая миграция между физическими серверами. К сожалению, в LXC в этом плане не видно никакой помощи — делайте все сами.

Ubuntu 13.10

Версия LXC — 1.0.0.alpha1

Первое, что бросается в глаза — вывод lxc-checkconfig говорит, что у нас есть проблемы. В частности некий «User namespace: missing». Для человека, далекого от внутренностей технологий — это, во-первых, выглядит подозрительно, во-вторых, практически не говорит «а что же будет не работать из-за этого». Тем более, что в 12.04 все было хорошо по всем пунктам.

Смотрим дальше — контейнер с Ubuntu создается (радуемся уже таким вещам :)) Вместо lxc-list нам говорят нужно теперь использовать lxc-ls. Понятно, что API до 1.0 не обещали держать стабильным, но все равно со стороны выглядит сомнительным нововведением.

Что же с backup/restore? Утилиты lxc-backup/lxc-restore почему-то отсутствуют. То ли это специфика моей инсталляции (но какая?), то ли их действительно решили выбросить — вопрос так и остался открытым. Смотрим еще раз список команд с префиксом lxc- и в поле зрения попадает lxc-checkpoint. Пробуем воспользоваться и получаем «checkpoint function not implemented». Печально.

Возвращаемся к основной теме — использование контейнера. Запуск его осуществляется командой lxc-start. После выполнения этой команды мы оказываемся в консоли контейнера — довольно странный выбор поведения по-умолчанию. Чтобы этого не происходило, нужно не забывать передавать ключ -d. Второй момент — это адекватное покидание консоли. Документация говорит о способе Ctrl+a q, но он не работает (и судя по всему не только у меня).

Следующий момент — после входа видим, что количество памяти и дискового пространства совпадает со значениями в хостовой системе. Смотрим это с помощью традиционных df и free. Интуитивно хочется у команды lxc-create (по аналогии с vzctl) увидеть параметры, которые помогут задать объем памяти и дискового пространства для контейнера, но таких параметров не видно. Так как этот момент весьма важен для меня, пробую разобраться. С момента последнего изучения в LXC в этом плане практически ничего не поменялось. В ядре нет возможности ставить квоты на поддерево и из советов обычно предлагают попробовать использовать LVM-тома в качестве FS для контейнера. Способ явно нельзя назвать удобным и простым. Ограничение памяти в некотором виде можно выставить прописыванием некоей директивы lxc.cgroup.memory.limit_in_bytes в конфиге контейнера. Способ опять нельзя назвать user friendly, но беда даже не в этом. Во-первых, ограничена будет не вся память, во-вторых, в контейнере на free -m нам по-прежнему показывают лимиты хостовой системы. Да, новый лимит на самом деле появился и, если некий процесс его превысит, то OOM-киллер его прибьет. Но уже на первый взгляд кажется, что mongo в таком контейнере запускать не стоит. Да и в любом случае такой подход не выглядит юзабельным. Представьте вы получили в свое распоряжение виртуальную машину и тип виртуализации вам никто не говорил. Смотреть объем доступной памяти вы будете традиционными средствами и потом сильно удивляться, почему умирают те или иные процессы, хотя памяти должно хватать.

Выводы

Хоть это и весьма поверхностное исследование, но его вполне хватает, чтобы принять решение для себя в очередной раз — LXC по-прежнему нужно еще подрасти. Не покидает ощущение, что вам пытаются подсунуть некий чуть более продвинутый chroot, вместо настоящей контейнерной виртуализации. Несмотря на то, что поддержка LXC есть в ядре и достаточно доставить утилиты, чтобы начать пользоваться, этого все равно оказывается мало. Конечно, применять для некоторых задач можно и сейчас, что, например, пытается делать тот же Docker. Но на массовое использование рассчитывать явно не стоит, пока не будут доделаны моменты, которые я упомянул здесь как минусы. Здесь как раз тот случай, когда «готово на 95%» — это все-таки не готово.

P.S. Для интереса по данной теме еще можно полистать презентацию — www.slideshare.net/kolyshkin/seven-problems-of-linux-containers

Автор: SibProgrammer

Источник