Приношу извинения за приват. В Gnus не заходил пол года и нажал R, вместо F...
Вы пока не отвечали, если будет интересно - с нетерпением жду в рассылке... On 2018-10-11, Victor Wagner wrote: > В Thu, 11 Oct 2018 01:29:09 +0300 > Oleksandr Gavenko <gaven...@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/
