Re: LXC vs Docker и форматы контейнеров
Приношу извинения за приват. В Gnus не заходил пол года и нажал R, вместо F...
Вы пока не отвечали, если будет интересно - с нетерпением жду в рассылке...
On 2018-10-11, Victor Wagner wrote:
> В Thu, 11 Oct 2018 01:29:09 +0300
> Oleksandr Gavenko <gavenkoa@gmail.com> пишет:
>
>> Всевозможные User-mode Linux, OpenVZ, Xen и т.д. я пропустил. Его
>> нужно было либо на голом железе крутить или с особыми ядрами. В общем
>> VistualBox можно кликать, экономя время и мозги.
>>
>
> Правильно поставленный вопрос - это больше половины ответа. У докера
> есть своя область применения, у LXC-своя. А есть вещи (вроде того же
> запуска skype) для которых LXC - это избыточно тяжеловесное решение, и
> надо испольовать что-то типа firejail или chroot.
>
Это потому что избыточно тянуть системные библиотеки (200 MB зависимостей)
когда просто нужно оградить забором?
> К сожалению, из огромного письма, перечисляющего разные свойства
> технологий (в которые почему-то вместе с технологиями изоляции и
> виртуализации попали технологии массового управления системами -
> ansible и CFEngine) я так и не понял чего хочется получить.
>
Мне не ясно нужно ли тратить время на ansible, если я буду упаковывать все в
контейнеры, а остальное что не пакуется предоставляется провайдер (например
Amazon Relational Database Service).
Провиженинг Vagrant коробок я делаю с помошью bash/sed, т.к. Puppet/Salt
требует отдельного сервера (мне не нужно дополнительных абстракций), а Ansible
и CFEngine умеет без сервера, но требуют инталяций в коробке. Мне не нравится
что 50 MB Python доставится что бы только поменять какую то строчку в
/etc/bla-bla.d
С другой стороны работать с структурироваными форматами (ini/yaml/json/xml) из
sed - неблагодарный труд и лишний Python/Ruby не так неприятен ))
> 1. Обеспечить работу недоверенных приложений...[SKIP]
>
Принято!
> Решение на базе LXC или LXC+Ansible здесь может оказаться проще потому
> что не надо приноравливаться к тому как сделали разработчики докера, а
> можно сделать как кажется нужным в конкретной ситуации.
> LXC-низкоуровневый конструктор, этим и плох, этим и хорош.
>
А как хостить LXC? С kubernates к примеру есть способ описывать деплои в
терминах Docker-контейнеров.
Это предполагается что нужно свое решение делать, набрав пул виртуальных
машин?
С kubernates хостеры поддерживают сервера / балансировщики / хранилища
настроек вне кластера контейнеров и зачастую бесплатно.
Для LXC как я понимаю есть LXD и его крутить придется вручную и еще за хостинг
платить?
> 2. Обеспечить разработку и тестирование программы на возможно широком
> спектре дистрибутивов Linux при ограниченных аппаратных ресурсах.
> Вот здесь, на мой взгляд, LXC гораздо лучше. Хотя на практике часть
> тестовых систем все равно приходится держать в KVM, несмотря на
> его более высокий оверхед поскольку необходимо бывает тестироваться с
> их родными ядрами. Какой-нибудь Oracle Linux unbreakable kernel или
> Astra Smolensk с ее мандатным доступом.
>
Пока не знаю заведется ли Jenkins в паре с LXC.
Всякие CircleCI, Bitbucket Pipelines, Google cloud-build работают только с
образами Docker...
> 3. То же что и 2, но поддерживаемых линуксов меньше десятка, а основной
> упор в переносимости надо делать на системы с другими ядрами. Тогда
> проще не париться и все держать в KVM/VirtualBox/VMWare. Необходимость
> менеджить две системы изоляции/виртуализации обойтется дороже, чем
> оверхед от загоняния в виртуальную машину того, что могло бы жить в
> контейнере.
>
Принято!
> 4. Поиграться с готовыми образами систем/приложений. Вот тут докер вне
> конкуренции. Потому что у него есть DockerHub где этих образов море.
> Хотя тут уже надо смотреть в сторону убунтовских snap. Видимо, в ubuntu
> эту технологию стали развивать когда уткнулись в ограничения докера.
Я позно попал на бал упаковки всего узерспейс окружения и начал с Vagrant.
У них есть свой хаб https://app.vagrantup.com с одной бедой - append only +
нету проверок издателя. Т.е. нельзя "убить" проблемный релиз и все образы
недоверенные и без какиз либо гарантий. Они не хотят менеджить гарантии кто
есть кто, как в докер-хаб.
Если смотреть на проекты, то пока еще можно встретить запаковки в Vagrant что
бы поиграться, но все больше все скатываются в Docker, убивая популярность
Vagrant.
--
http://defun.work/
Reply to: