Comments 29
IMHO, контейнеры прекрасно создаются командой debootstrap (ну это для Debian'f разумеется). backup/restore вообще не очень понятны, когда это действительно одна папка с rootfs, так что сами вызывайте что Вам удобнее — tar, dump, etc.
Раздражает то, что многие команды привязаны к той мысли, что контейнеры должны лежать в /var/lib/lxc/${cname}/rootfs, а если не в rootfs, а просто в ${cname}, то часть команд не работает, даже если в конфиге указан верный путь! Почему бы не брать настройку из файла настроек?!
Раздражает то, что многие команды привязаны к той мысли, что контейнеры должны лежать в /var/lib/lxc/${cname}/rootfs, а если не в rootfs, а просто в ${cname}, то часть команд не работает, даже если в конфиге указан верный путь! Почему бы не брать настройку из файла настроек?!
Я собственно и создал для Debian 7 его в итоге с помощью debootstrap, просто из коробки тоже было бы неплохо, чтобы работало :) А по поводу backup'а ну так вроде ж какие-то зачатки в toolset'е были, а в итоге действительно выглядит, что проще уж самому tar'ом rootfs паковать. Но может так случиться, что для полноценного бэкапа еще надо бы конфиг паковать или еще какие-нибудь директории, а узнаю я это только методом проб и ошибок. В этом как раз преимущество штатных lxc-backup/restore должно было быть.
lxc это пока скорее более ядерная вещь, чем конкретные утилиты, управляющие всем этим добром, которые ещё стопиццот раз переделаны будут.
И да, для продакшена на данный момент пока ещё есть смысл использовать ядро и утилиты от openvz, ибо там более чёткая изоляция контейнеров, да и нужные фичи присутствуют.
Хотя в vzctl уже начали впиливать поддержку vanilla-kernel, но пока данный режим так же далёк от продакшена, как и lxc.
И да, для продакшена на данный момент пока ещё есть смысл использовать ядро и утилиты от openvz, ибо там более чёткая изоляция контейнеров, да и нужные фичи присутствуют.
Хотя в vzctl уже начали впиливать поддержку vanilla-kernel, но пока данный режим так же далёк от продакшена, как и lxc.
Использовать допотопные ядра без многих очень хороших фич,
да еще и не родные для всех ОС кроме CentOS/EL, как бы не самая лучшая идея.
CentOS конечно хорошая ОС и я долго ее использовал, но слишком уже отстала от жизни.
да еще и не родные для всех ОС кроме CentOS/EL, как бы не самая лучшая идея.
CentOS конечно хорошая ОС и я долго ее использовал, но слишком уже отстала от жизни.
Обещали приделать новые ядра после выхода RHEL7, то есть уже в этом году.
Ждать этого долго + опять будут страдать некрофилией долгое время.
Ну опять таки, KSM они починят в своих ядрах когда-нибудь?
И последнее, где обещанные еще при царе горохе патчи на актуальное ванильное ядро?
Ну опять таки, KSM они починят в своих ядрах когда-нибудь?
И последнее, где обещанные еще при царе горохе патчи на актуальное ванильное ядро?
KSM для контейнеров — вещь КРАЙНЕ сомнительная. Он задуман был исключительно для VM и пытаться прикрутить его к контейнерам — весьма сомнительно, чисто архитектурно.
Патчи на актуальное ядро — это не статичный процесс, а постоянная разработка, подвижек в ней множество. А из ближайшего OpenVZ для RHEL7.
Патчи на актуальное ядро — это не статичный процесс, а постоянная разработка, подвижек в ней множество. А из ближайшего OpenVZ для RHEL7.
> KSM для контейнеров — вещь КРАЙНЕ сомнительная.
Ну почему же, вот есть 5 контейнеров с одной и той же версией дебиана, внутри, соответственно, куча одинаковых библиотек, так почему бы все эти либы не загрузить в память один раз, а не по одному разу на каждый контейнер?
Ну почему же, вот есть 5 контейнеров с одной и той же версией дебиана, внутри, соответственно, куча одинаковых библиотек, так почему бы все эти либы не загрузить в память один раз, а не по одному разу на каждый контейнер?
KSM работает на чуть-чуть ином уровне, он мержит страницы, а не баблиотеки. Причем, эта операция довольно ресурсозатратная.
В случае VM вся их память — непрерывный блок/несколько блоков на хост-сервере.
В случае контейнеров — это тысячи непоследовательных блоков, каждый для своей программы, своей задачи.
Для решения задачи шаринга либ самое красивое, что я видел — это pfcache из коммерческой версии OpenVZ. Они делают хэши SHA-1 библиотек/бинариков и поддерживают их список в ядре и если происходит попытка загрузки либы, которая уже в памяти, загрузка не происходит и просто происходит ссылка на область памяти соседа.
В случае VM вся их память — непрерывный блок/несколько блоков на хост-сервере.
В случае контейнеров — это тысячи непоследовательных блоков, каждый для своей программы, своей задачи.
Для решения задачи шаринга либ самое красивое, что я видел — это pfcache из коммерческой версии OpenVZ. Они делают хэши SHA-1 библиотек/бинариков и поддерживают их список в ядре и если происходит попытка загрузки либы, которая уже в памяти, загрузка не происходит и просто происходит ссылка на область памяти соседа.
Archlinux, буквально пару дней назад.
lxc-0.9.0-5
Мне понадобилось доустановить bridge-utils (забыли добавить в зависимость) и создать bridge-interface.
После этого создается и запускается.
lxc-0.9.0-5
Мне понадобилось доустановить bridge-utils (забыли добавить в зависимость) и создать bridge-interface.
После этого создается и запускается.
Кстати, можно перепаковывать образы через packer.io/.
Ну и можно работать с LXC через VirtualBox — github.com/wyrdvans/lxc-playground
Ну и можно работать с LXC через VirtualBox — github.com/wyrdvans/lxc-playground
Подключите репозиторий LXC kernel и LXC Stable. Здесь, соответственно, ядро с включенным user namespace (его кстати можно руками включить и на обычном ядре в Ubuntu 12.04) и актуальная версия утилит. И будет вам счастье. А вообще, обещают, что в Ubuntu 14.04 и RHEL 7 уже все будет стабильно и «изкоробки» работать.
Кстати, вот еще блог разработчика LXC из Canonical, может будет кому-нибудь полезно.
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)
Есть очень полезная штука github.com/lxctl/lxctl. В убунте она уже есть.
Под Centos 6 запускается «машина» и молчит (т.е. не выходит в консоль). При нажатии Ctrl-C хост уходит в ребут (!)
LXC еще делают. Зачем в него кидать камни и кричать «не готово»?
До OpenVZ пока не дотягивает, но если нет возможности поставить ovz-ядро, то вполне годится.
Памятка по развёртыванию и утилиты для личных нужд:
code.google.com/p/lxc-loader/wiki/QuickStart
Сетка настраивается в режиме ProxyARP, как в OpenVZ.
Возможно, кому-то пригодится.
Памятка по развёртыванию и утилиты для личных нужд:
code.google.com/p/lxc-loader/wiki/QuickStart
Сетка настраивается в режиме ProxyARP, как в OpenVZ.
Возможно, кому-то пригодится.
Docker вполне вполне!
Я тащусь просто уже пару дней.
Недавно был на ДевОпс митапе, там чуваки с серьзныех проектов на докере сидят и нахваливают.
Он сырой и активно развивается, но у всех у них в продакшене и ничего ;)
Там только надо учитивыть: поменше (состояния) в контейнерах
и потоньше на сервисы резать
Я тащусь просто уже пару дней.
Недавно был на ДевОпс митапе, там чуваки с серьзныех проектов на докере сидят и нахваливают.
Он сырой и активно развивается, но у всех у них в продакшене и ничего ;)
Там только надо учитивыть: поменше (состояния) в контейнерах
и потоньше на сервисы резать
У меня Docker смог довести систему до kernel panic. Больше никому такого еще не удавалось.
Докер не делает никаких чудес. Контейнеризацию давно изобрели.
Худшее, с чем мне доводилось иметь дело — это докер. Бесконечность всевозможных косяков и «но» на всех платформах.
И что же за косяки такие...? :) Может просто готовить надо уметь?
Я в продакшене гоняю уже как год и ненарадуюсь…
Наконец-то с помощью докера полностью переехал в гугл-клауд со своими прокетиками… Маинтаинить проще и дешевле…
Я в продакшене гоняю уже как год и ненарадуюсь…
Наконец-то с помощью докера полностью переехал в гугл-клауд со своими прокетиками… Маинтаинить проще и дешевле…
Может просто готовить надо уметь?
На этом и стоит акцентировать внимание. Если LXC вы просто устанавливаете — и он из коробки работает, то в Docker ещё надо уметь. Конечно, там уже наворотили функциональности более чем достаточно, но я предпочитаю решения, которые можно начинать использовать без изучения мегатонн документации, блогов, багов на ровном месте. И вообще, с докером удивительное всегда где-то рядом.
Вот здесь вот пункт про «Cannot connect to the Docker daemon», например, доставляет неимоверно. Собственно говоря, в последний раз когда он у меня возник, мне уже надоело изучать почему докер снова не запускается, хотя всего час назад всё выглядело работоспособным. Переход на LXC на машинах под Ubuntu занял 6 часов с учётом переписывания всех рецептов оркестратора. LXC просто работает из коробки, предоставляя мне решать, хочу ли я, к примеру, systemd под контейнер с RHEL7 или нет.
UP: А когда вы попытаетесь ещё разок убедить меня, просто настройте статический IP для контейнера LXC и то же самое для Docker. Почувствуйте разницу, как говорится.
Стефан Грабер (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
Рассмотрены:
* Первый Ubuntu контейнер.
* Второй контейнер.
* Продвинутое использование контейнера.
* Более углублённое использование контейнера.
* Хранилище контейнеров.
* Безопасность.
* Непривилегированные контейнеры.
* Скрипты и API.
* GUI в контейнере.
* Решение проблем и отладка.
Оригинал www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/
Перевод vasilisc.com/lxc-1-0-blog-post-series
Sign up to leave a comment.
LXC (Linux Containers) — так ли все прекрасно на самом деле?