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

    Комментарии 29

      +3
      IMHO, контейнеры прекрасно создаются командой debootstrap (ну это для Debian'f разумеется). backup/restore вообще не очень понятны, когда это действительно одна папка с rootfs, так что сами вызывайте что Вам удобнее — tar, dump, etc.

      Раздражает то, что многие команды привязаны к той мысли, что контейнеры должны лежать в /var/lib/lxc/${cname}/rootfs, а если не в rootfs, а просто в ${cname}, то часть команд не работает, даже если в конфиге указан верный путь! Почему бы не брать настройку из файла настроек?!
        0
        Я собственно и создал для Debian 7 его в итоге с помощью debootstrap, просто из коробки тоже было бы неплохо, чтобы работало :) А по поводу backup'а ну так вроде ж какие-то зачатки в toolset'е были, а в итоге действительно выглядит, что проще уж самому tar'ом rootfs паковать. Но может так случиться, что для полноценного бэкапа еще надо бы конфиг паковать или еще какие-нибудь директории, а узнаю я это только методом проб и ошибок. В этом как раз преимущество штатных lxc-backup/restore должно было быть.
          0
          Должно быть — наверное да. Но пока как видите оно не пашет, как и косяк указанный мной выше, он и основополагающим командам(start, stop, shutdown) не даёт нормально работать.
        +3
        lxc это пока скорее более ядерная вещь, чем конкретные утилиты, управляющие всем этим добром, которые ещё стопиццот раз переделаны будут.

        И да, для продакшена на данный момент пока ещё есть смысл использовать ядро и утилиты от openvz, ибо там более чёткая изоляция контейнеров, да и нужные фичи присутствуют.

        Хотя в vzctl уже начали впиливать поддержку vanilla-kernel, но пока данный режим так же далёк от продакшена, как и lxc.
          –1
          Использовать допотопные ядра без многих очень хороших фич,
          да еще и не родные для всех ОС кроме CentOS/EL, как бы не самая лучшая идея.
          CentOS конечно хорошая ОС и я долго ее использовал, но слишком уже отстала от жизни.
            0
            Обещали приделать новые ядра после выхода RHEL7, то есть уже в этом году.
              0
              Ждать этого долго + опять будут страдать некрофилией долгое время.
              Ну опять таки, KSM они починят в своих ядрах когда-нибудь?
              И последнее, где обещанные еще при царе горохе патчи на актуальное ванильное ядро?
                0
                KSM для контейнеров — вещь КРАЙНЕ сомнительная. Он задуман был исключительно для VM и пытаться прикрутить его к контейнерам — весьма сомнительно, чисто архитектурно.

                Патчи на актуальное ядро — это не статичный процесс, а постоянная разработка, подвижек в ней множество. А из ближайшего OpenVZ для RHEL7.

                  +1
                  > KSM для контейнеров — вещь КРАЙНЕ сомнительная.

                  Ну почему же, вот есть 5 контейнеров с одной и той же версией дебиана, внутри, соответственно, куча одинаковых библиотек, так почему бы все эти либы не загрузить в память один раз, а не по одному разу на каждый контейнер?
                    0
                    KSM работает на чуть-чуть ином уровне, он мержит страницы, а не баблиотеки. Причем, эта операция довольно ресурсозатратная.

                    В случае VM вся их память — непрерывный блок/несколько блоков на хост-сервере.
                    В случае контейнеров — это тысячи непоследовательных блоков, каждый для своей программы, своей задачи.

                    Для решения задачи шаринга либ самое красивое, что я видел — это pfcache из коммерческой версии OpenVZ. Они делают хэши SHA-1 библиотек/бинариков и поддерживают их список в ядре и если происходит попытка загрузки либы, которая уже в памяти, загрузка не происходит и просто происходит ссылка на область памяти соседа.

          +3
          Archlinux, буквально пару дней назад.
          lxc-0.9.0-5
          Мне понадобилось доустановить bridge-utils (забыли добавить в зависимость) и создать bridge-interface.
          После этого создается и запускается.
            +2
            Кстати, можно перепаковывать образы через packer.io/.

            Ну и можно работать с LXC через VirtualBox — github.com/wyrdvans/lxc-playground
              0
              Тут скорее интересовала не столько возможность поиграться, сколько понять реально ли будет применить на одном из физ. серверов.

              А за ссылочку на packer.io — спасибо, надо будет поразглядывать.
                0
                Под «свои» внутренние нужды конечно использовать можно. По крайне мере получаешь видимость контейнерной виртуализации и свои пакеты/настройки/ip-адреса и т.п. для каждой «виртуалки».
                В общем «под внутренние задачи» на отдельном сервере вполне годная штука.
              +3
              Подключите репозиторий LXC kernel и LXC Stable. Здесь, соответственно, ядро с включенным user namespace (его кстати можно руками включить и на обычном ядре в Ubuntu 12.04) и актуальная версия утилит. И будет вам счастье. А вообще, обещают, что в Ubuntu 14.04 и RHEL 7 уже все будет стабильно и «изкоробки» работать.
                0
                Кстати, вот еще блог разработчика LXC из Canonical, может будет кому-нибудь полезно.
                  +2
                  lxc-backup и lxc-restore
                  The following tools/templates have been dropped:
                        - lxc-debconf (upstream ships lxc-debian and lxc-lenny)
                        - lxc (use the lxc-* commands directly)
                        - lxc-backup (was just a wrapper on rsync using hardcoded paths)
                        - lxc-restore (was just a wrapper on rsync using hardcoded paths)
                  
                    +3
                    Есть очень полезная штука github.com/lxctl/lxctl. В убунте она уже есть.
                    –1
                    Под Centos 6 запускается «машина» и молчит (т.е. не выходит в консоль). При нажатии Ctrl-C хост уходит в ребут (!)
                      0
                      LXC еще делают. Зачем в него кидать камни и кричать «не готово»?
                        +5
                        Никто цели «камни покидать» не ставил. Для себя было исследование «а можно ли уже пользоваться». Просто в тех статьях, что попадались обычно про подводные камни почти ни слова.
                        0
                        До OpenVZ пока не дотягивает, но если нет возможности поставить ovz-ядро, то вполне годится.

                        Памятка по развёртыванию и утилиты для личных нужд:
                        code.google.com/p/lxc-loader/wiki/QuickStart

                        Сетка настраивается в режиме ProxyARP, как в OpenVZ.

                        Возможно, кому-то пригодится.
                          0
                          Docker вполне вполне!
                          Я тащусь просто уже пару дней.
                          Недавно был на ДевОпс митапе, там чуваки с серьзныех проектов на докере сидят и нахваливают.
                          Он сырой и активно развивается, но у всех у них в продакшене и ничего ;)
                          Там только надо учитивыть: поменше (состояния) в контейнерах
                          и потоньше на сервисы резать
                            0
                            У меня Docker смог довести систему до kernel panic. Больше никому такого еще не удавалось.
                              0
                              Докер не делает никаких чудес. Контейнеризацию давно изобрели.
                                0
                                Худшее, с чем мне доводилось иметь дело — это докер. Бесконечность всевозможных косяков и «но» на всех платформах.
                                  0
                                  И что же за косяки такие...? :) Может просто готовить надо уметь?

                                  Я в продакшене гоняю уже как год и ненарадуюсь…
                                  Наконец-то с помощью докера полностью переехал в гугл-клауд со своими прокетиками… Маинтаинить проще и дешевле…
                                    0
                                    Может просто готовить надо уметь?

                                    На этом и стоит акцентировать внимание. Если LXC вы просто устанавливаете — и он из коробки работает, то в Docker ещё надо уметь. Конечно, там уже наворотили функциональности более чем достаточно, но я предпочитаю решения, которые можно начинать использовать без изучения мегатонн документации, блогов, багов на ровном месте. И вообще, с докером удивительное всегда где-то рядом.

                                    Вот здесь вот пункт про «Cannot connect to the Docker daemon», например, доставляет неимоверно. Собственно говоря, в последний раз когда он у меня возник, мне уже надоело изучать почему докер снова не запускается, хотя всего час назад всё выглядело работоспособным. Переход на LXC на машинах под Ubuntu занял 6 часов с учётом переписывания всех рецептов оркестратора. LXC просто работает из коробки, предоставляя мне решать, хочу ли я, к примеру, systemd под контейнер с RHEL7 или нет.

                                    UP: А когда вы попытаетесь ещё разок убедить меня, просто настройте статический IP для контейнера LXC и то же самое для Docker. Почувствуйте разницу, как говорится.
                                +2
                                Стефан Грабер (Stéphane Graber), в предверии выхода 20 февраля 2014 года релиза LXC 1.0, опубликовал цикл статей о Linux Containers.
                                Рассмотрены:
                                * Первый Ubuntu контейнер.
                                * Второй контейнер.
                                * Продвинутое использование контейнера.
                                * Более углублённое использование контейнера.
                                * Хранилище контейнеров.
                                * Безопасность.
                                * Непривилегированные контейнеры.
                                * Скрипты и API.
                                * GUI в контейнере.
                                * Решение проблем и отладка.
                                Оригинал www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/
                                Перевод vasilisc.com/lxc-1-0-blog-post-series

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое