SibProgrammer12 янв 2014 в 14:44

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

5 мин

38K

Виртуализация *

+20

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

Alukardd 12 янв 2014 в 15:52

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

Раздражает то, что многие команды привязаны к той мысли, что контейнеры должны лежать в /var/lib/lxc/${cname}/rootfs, а если не в rootfs, а просто в ${cname}, то часть команд не работает, даже если в конфиге указан верный путь! Почему бы не брать настройку из файла настроек?!

SibProgrammer 12 янв 2014 в 15:59

Я собственно и создал для Debian 7 его в итоге с помощью debootstrap, просто из коробки тоже было бы неплохо, чтобы работало :) А по поводу backup'а ну так вроде ж какие-то зачатки в toolset'е были, а в итоге действительно выглядит, что проще уж самому tar'ом rootfs паковать. Но может так случиться, что для полноценного бэкапа еще надо бы конфиг паковать или еще какие-нибудь директории, а узнаю я это только методом проб и ошибок. В этом как раз преимущество штатных lxc-backup/restore должно было быть.

Alukardd 12 янв 2014 в 16:03

Должно быть — наверное да. Но пока как видите оно не пашет, как и косяк указанный мной выше, он и основополагающим командам(start, stop, shutdown) не даёт нормально работать.

Eklykti 12 янв 2014 в 16:04

lxc это пока скорее более ядерная вещь, чем конкретные утилиты, управляющие всем этим добром, которые ещё стопиццот раз переделаны будут.

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

Хотя в vzctl уже начали впиливать поддержку vanilla-kernel, но пока данный режим так же далёк от продакшена, как и lxc.

DLag 13 янв 2014 в 00:32

Использовать допотопные ядра без многих очень хороших фич,
да еще и не родные для всех ОС кроме CentOS/EL, как бы не самая лучшая идея.
CentOS конечно хорошая ОС и я долго ее использовал, но слишком уже отстала от жизни.

blueboar2 13 янв 2014 в 02:00

Обещали приделать новые ядра после выхода RHEL7, то есть уже в этом году.

DLag 13 янв 2014 в 06:46

Ждать этого долго + опять будут страдать некрофилией долгое время.
Ну опять таки, KSM они починят в своих ядрах когда-нибудь?
И последнее, где обещанные еще при царе горохе патчи на актуальное ванильное ядро?

pavelodintsov 13 янв 2014 в 09:19

KSM для контейнеров — вещь КРАЙНЕ сомнительная. Он задуман был исключительно для VM и пытаться прикрутить его к контейнерам — весьма сомнительно, чисто архитектурно.

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

Eklykti 13 янв 2014 в 09:42

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

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

pavelodintsov 13 янв 2014 в 10:02

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

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

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

Forked 12 янв 2014 в 16:09

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

akzhan 12 янв 2014 в 16:21

Кстати, можно перепаковывать образы через packer.io/.

Ну и можно работать с LXC через VirtualBox — github.com/wyrdvans/lxc-playground

SibProgrammer 12 янв 2014 в 16:28

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

А за ссылочку на packer.io — спасибо, надо будет поразглядывать.

Alukardd 12 янв 2014 в 16:40

Под «свои» внутренние нужды конечно использовать можно. По крайне мере получаешь видимость контейнерной виртуализации и свои пакеты/настройки/ip-адреса и т.п. для каждой «виртуалки».
В общем «под внутренние задачи» на отдельном сервере вполне годная штука.

1it 12 янв 2014 в 16:52

Подключите репозиторий LXC kernel и LXC Stable. Здесь, соответственно, ядро с включенным user namespace (его кстати можно руками включить и на обычном ядре в Ubuntu 12.04) и актуальная версия утилит. И будет вам счастье. А вообще, обещают, что в Ubuntu 14.04 и RHEL 7 уже все будет стабильно и «изкоробки» работать.

1it 12 янв 2014 в 16:56

Кстати, вот еще блог разработчика LXC из Canonical, может будет кому-нибудь полезно.

pomeo 12 янв 2014 в 17:19

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)

pomeo 12 янв 2014 в 17:22

Есть очень полезная штука github.com/lxctl/lxctl. В убунте она уже есть.

savostin 12 янв 2014 в 17:19

Под Centos 6 запускается «машина» и молчит (т.е. не выходит в консоль). При нажатии Ctrl-C хост уходит в ребут (!)

MedVedar 13 янв 2014 в 01:31

LXC еще делают. Зачем в него кидать камни и кричать «не готово»?

SibProgrammer 13 янв 2014 в 02:37

Никто цели «камни покидать» не ставил. Для себя было исследование «а можно ли уже пользоваться». Просто в тех статьях, что попадались обычно про подводные камни почти ни слова.

IlyaEvseev 13 янв 2014 в 09:31

До OpenVZ пока не дотягивает, но если нет возможности поставить ovz-ядро, то вполне годится.

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

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

Возможно, кому-то пригодится.

shuron 30 янв 2014 в 15:29

Docker вполне вполне!
Я тащусь просто уже пару дней.
Недавно был на ДевОпс митапе, там чуваки с серьзныех проектов на докере сидят и нахваливают.
Он сырой и активно развивается, но у всех у них в продакшене и ничего ;)
Там только надо учитивыть: поменше (состояния) в контейнерах
и потоньше на сервисы резать

MedVedar 30 янв 2014 в 19:39

У меня Docker смог довести систему до kernel panic. Больше никому такого еще не удавалось.

Ipeacocks 24 ноя 2015 в 22:18

Докер не делает никаких чудес. Контейнеризацию давно изобрели.

KIVagant 7 дек 2015 в 20:55

Худшее, с чем мне доводилось иметь дело — это докер. Бесконечность всевозможных косяков и «но» на всех платформах.

shuron 8 дек 2015 в 08:34

И что же за косяки такие...? :) Может просто готовить надо уметь?

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

KIVagant 9 дек 2015 в 07:53

Может просто готовить надо уметь?

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

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

UP: А когда вы попытаетесь ещё разок убедить меня, просто настройте статический IP для контейнера LXC и то же самое для Docker. Почувствуйте разницу, как говорится.

vasilisc 20 фев 2014 в 04:43

Стефан Грабер (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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий