Re: LXC vs Docker и форматы контейнеров
В Thu, 11 Oct 2018 01:29:09 +0300
Oleksandr Gavenko <gavenkoa@gmail.com> пишет:
> Всевозможные User-mode Linux, OpenVZ, Xen и т.д. я пропустил. Его
> нужно было либо на голом железе крутить или с особыми ядрами. В общем
> VistualBox можно кликать, экономя время и мозги.
>
Правильно поставленный вопрос - это больше половины ответа. У докера
есть своя область применения, у LXC-своя. А есть вещи (вроде того же
запуска skype) для которых LXC - это избыточно тяжеловесное решение, и
надо испольовать что-то типа firejail или chroot.
К сожалению, из огромного письма, перечисляющего разные свойства
технологий (в которые почему-то вместе с технологиями изоляции и
виртуализации попали технологии массового управления системами -
ansible и CFEngine) я так и не понял чего хочется получить.
Кроме того я не понял в чем сложности с настройкой бриджа-то? Вещь
исключительно простая и прямолинейная.
Итак, что может хотеться получить:
1. Обеспечить работу недоверенных приложений, возможно нескольких
взаимодействующих, возможно предъявляющих несовместимые требования к
операционным системам, в которых развернуты.
Под эту задачу создавался докер. И ее худо-бедно решает. В смысле как
только в список несовместимых требований попадает "это приложение у нас
32-разрядное", становится худо.
При этом надо понимать, что если вы ходите что-то серьезное хостить, то
"сэкономить время и мозги" не получится. Придется достигать глубокого
понимания как работает докер (а он заметно overengineered), как решать
проблемы, которые он не решает (например защиту данных от
несанкционированного изменения при взломе приложения, которое вообще-то
имеет право в эти данные писать).
Решение на базе LXC или LXC+Ansible здесь может оказаться проще потому
что не надо приноравливаться к тому как сделали разработчики докера, а
можно сделать как кажется нужным в конкретной ситуации.
LXC-низкоуровневый конструктор, этим и плох, этим и хорош.
2. Обеспечить разработку и тестирование программы на возможно широком
спектре дистрибутивов Linux при ограниченных аппаратных ресурсах.
Вот здесь, на мой взгляд, LXC гораздо лучше. Хотя на практике часть
тестовых систем все равно приходится держать в KVM, несмотря на
его более высокий оверхед поскольку необходимо бывает тестироваться с
их родными ядрами. Какой-нибудь Oracle Linux unbreakable kernel или
Astra Smolensk с ее мандатным доступом.
3. То же что и 2, но поддерживаемых линуксов меньше десятка, а основной
упор в переносимости надо делать на системы с другими ядрами. Тогда
проще не париться и все держать в KVM/VirtualBox/VMWare. Необходимость
менеджить две системы изоляции/виртуализации обойтется дороже, чем
оверхед от загоняния в виртуальную машину того, что могло бы жить в
контейнере.
4. Поиграться с готовыми образами систем/приложений. Вот тут докер вне
конкуренции. Потому что у него есть DockerHub где этих образов море.
Хотя тут уже надо смотреть в сторону убунтовских snap. Видимо, в ubuntu
эту технологию стали развивать когда уткнулись в ограничения докера.
--
Victor Wagner <vitus@wagner.pp.ru>
Reply to: