Re: LXC vs Docker и форматы контейнеров
On Thu, 11 Oct 2018 11:02:17 +0500 Stanislav Vlasov wrote: > 11.10.2018, Victor Wagner написал(а): > > > 4. Поиграться с готовыми образами систем/приложений. Вот тут докер > > вне конкуренции. Потому что у него есть DockerHub где этих образов > > море. Хотя тут уже надо смотреть в сторону убунтовских snap. > > Видимо, в ubuntu эту технологию стали развивать когда уткнулись в > > ограничения докера. > > Более того, у нас на работе мастер-образы для виртуалок в kvm > создаются на базе соответствующих образов докера путём доустановки > нужных пакетов в распакованном chroot. > Это оказывается быстрее и удобнее, чем debootstrap и тем более, чем > руками. Ну и окончательная конфигурация (хостнейм, сеть, пароли, > ключи) создаётся после раскатывания образа при помощи runc. Мне чаще приходится сталкиваться с обратной задачей - поставив в виртуалку какой-нибудь дистрибутив родным инсталляторм, сделать из этого докер-образ. Потому что примерно половина дистрибутивов, с которыми приходится иметь дело- это всякие хитрые российские сертифицированные варианты. для которых на докерхабе ничего нет. Честно сказать не понимаю, зачем мастер-образы делать таким способом. По-моему проще эталонный qcow2 файл скопировать, и потом уже доустанавливать пакеты и настраивать сеть каким-нибудь ansible. Тем более что это будет работать не только с линуксаии, но и с freebsd, solaris и даже windows. C другой стороны, мне много виртуалок не нужно. У меня сейчас примерно 4 десятка поддержвиваемых дистрибутивов/систем, и на каждую нужно от силы пяток экземпляров 1. В билдферме для тестирования кода, принимаемого от разработчиков 2. Для сборки пакетов 3. Для тестирования собранных пакетов 4,5. Для выполнения всяких длительных тестов --
Re: LXC vs Docker и форматы контейнеров
11.10.2018, Victor Wagner написал(а): > 4. Поиграться с готовыми образами систем/приложений. Вот тут докер вне > конкуренции. Потому что у него есть DockerHub где этих образов море. > Хотя тут уже надо смотреть в сторону убунтовских snap. Видимо, в ubuntu > эту технологию стали развивать когда уткнулись в ограничения докера. Более того, у нас на работе мастер-образы для виртуалок в kvm создаются на базе соответствующих образов докера путём доустановки нужных пакетов в распакованном chroot. Это оказывается быстрее и удобнее, чем debootstrap и тем более, чем руками. Ну и окончательная конфигурация (хостнейм, сеть, пароли, ключи) создаётся после раскатывания образа при помощи runc. -- Stanislav
Re: LXC vs Docker и форматы контейнеров
В Thu, 11 Oct 2018 01:29:09 +0300 Oleksandr Gavenko пишет: > Всевозможные 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
LXC vs Docker и форматы контейнеров
Всевозможные User-mode Linux, OpenVZ, Xen и т.д. я пропустил. Его нужно было либо на голом железе крутить или с особыми ядрами. В общем VistualBox можно кликать, экономя время и мозги. Идея chroot стала ясна после Linux From Scratch, аж захотелось скайп там запускать. Потом пришел LXC, но его нужно было конфигурировать через текстовые файлы. Я не осилил настройку бриждей. Vagrant + VirtualBox мне абсолютно понятен, но тяжеловесен и узкоприменим. Напишешь скрипт развертывания - а к проду он не применим, только локально поиграться (( Всевозможные Chief, Ansible, Puppet, Salt, CFEngine я пропустил, поигравшись с Ansible и CFEngine только потому что оба в дистрибутиве Alpine, а последний еще не тянет Ruby/Python. Зачем настраивать коробку очередным YAML DSL, если можно ее загрузить контейнерами. Как для обывателей - вставил в розетку и работает )) Мания на контейнеры пошла с 2013: https://www.youtube.com/watch?v=wW9CAH9nSLs Из контейнерного хайпа мне нравится только что можно собирать юзерспейс "дистрибутив" с версиями всего внутри как сам захочишь. Вопросы (концептуальные, интересно почему, а не юзай продукт С потому что мне нравится): * Во что оборачивать контейнеры? Вроде есть: - https://github.com/moby/moby/tree/master/image/spec + https://github.com/docker/distribution/tree/master/docs/spec - https://github.com/opencontainers/image-spec и докеровский Manifest Version 2, Schema 2 - самый популярный. По идее это tar файл, только что то для его сборки долго требовался root-сервис от Docker и его все ненавидели, кто следует тру-философии. Вроде как все облачные хостеры его поддерживают. Правильно что никто не стремится поддердивать другие форматы? Или есть альтернатива и при том рабочая? * Стоит ли заморачиваться с LXC для развертывания локальных демо-стендов? Как писал выше я умею варить Vagrant+VirtualBox. Пару лет назад настройка бриждей была непосильна разуму. Docker + Compose - вроде функциональная альтернатива. Я еще не понимаю как там думать в терминах портов, с VirtualBox я работал в терминах IP адресов, что приближено к реальности... * Есть ли локальные запускалки контейнеров, альтернативные Docker? * Правильно ли впихивать 10 гигабайт в контейнер или это должен быть Alpine (100 mb с lighttpd) или CoreOS (500mb)? Не будет Debian без Python и без 1GB места в голом виде? * Микросервис - это потому что выставляется немного HTTP REST эндпоинтов, связаных функционалом? А то когда видишь "микросервисный" Java-jar файл в 100 MB в гигабайтном убунтовом контейнере - дисонанс с моим калькулятором МК-61 с 104 однобайтными ячейками памяти... * Зачем вообще разбираться с Puppet, Ansible, Salt, CFEngine и т.д., если все пакуется в контейнеры? Что бы менеджить оставшийся не "микросервисный" софт (базы данных, файерволы и остальное, что требует больше чем RAM+CPU)? * Можно ли жить без Docker? По идее Docker не нужен, нужен только формат пакета и "исполнятор". Запускать как бы и раньше умели другими технологиями... Прибавочная стоимость в оркестрации, а не голом запускании... По идее тут будет у нас https://packages.debian.org/source/sid/kubernetes Да и сам Докер не без приключений добрался в Debian https://www.collabora.com/news-and-blog/blog/2018/07/04/docker-io-debian-package-back-to-life/ -- http://defun.work/
