Подпишусь.

Аналогично. не понял преимуществ докера перед ручным lxc. Хочу услышать саккес стори докера

мне лично кажеться что docker это эталонное ненужно.

Поясни пожалуйста.

эээ. ну не вижу я смысла использовать докер.

Ну так почему?)

Насколько я помню свое столкновение с докером он дает небольшую по взможностям обертку над lxc, однако при этом требует:

1. компиялятор Go

2. Только 64 разряда и еще что-то менее существенное, ИМХО многова-то предусловий для обертки

А в чем суть этих возможностей «над lxc»?

64 - не проблема, компилятор Go вроде тоже

Это просто чуть более юзер-френдли утилита для управления lxc?

Нет. По сути, это эдакий репозиторий виртуальных машин с плюшками. Т.е. работа выглядит примерно так.
— Создаёшь виртуалку из образа, коих много, целый репозиторий с разными готовыми решениями.
— Запускаешь, входишь, делаешь что хочешь.
— Если закроешь виртуалку, все изменения откатятся, вернётся к исходному состоянию
— Можно сделать push и зафиксировать изменения в виде нового образа. Соответственно, всегда можно сделать виртуалку с такого образа и менять потом её отдельной веткой.
— Всё это обёрнуто ещё в эффективные средства сетевого проброса.
— Дисковое пространство расходуется экономно. За счёт aufs общие части системы не дублируются.

По сути, да, всё, что делаешь через Docker, можно делать вручную. Но Docker позволяет очень многое автоматизировать.

Практическая же польза, ИМХО, очень узкая — массовое создание типовых виртуалок с экономией места и времени на допиливании.

В моей практике места для Docker пока не нашлось, мне проще работать с чистым LXC, ибо у меня всех виртуалок вместе взятых десятка два от силы и все разные :)

Вообще, по Docker немало простых и наглядных уроков, у него очень низкий порог вхождения для начального изучения. Фактически в несколько команд можно изучить основное применение и тонкости.

Docker - НЕ_НУ-ЖЕН!!!

Ну теперь ты расскажи почему

Потому-что это ЛОР (:

Практическая же польза

Вообще не нужно разбираться в LXC чтобы пользоваться докером.

Вообще не нужно разбираться в LXC чтобы пользоваться докером.

И чтобы пользоваться LXC — не нужно разбираться в Докере :)

Порог базового вхождения в Докер чуть ниже (команда для старта проще :D), но со всеми проблемами, которые всплывут при переходе к реальному использованию (идеология персистентности, продумывание версионности) Докер будет сложнее и неоднозначнее чистого LXC.

Есть кто, кто осилил LXC непривилегированные?
нормально работает?

типа основная суть в том что изменения дельтой пишуться в гит к каждому образу, экономит место, удобно и быстро откатываешся.(потом все aufs маунтит)

А так вообщем нет, много ограничений пока. Для девелопмента пойдет, для прода - разве что P(I)AAS-а.

Они типа позиционируют как контейнер - один аппликейшен, типа все минимально. Но ничто тебе не мешает так же сделать с LXC, примером.

Вроде ж докер - это LXC для одного приложения, не?

Вот, кстати, пару-тройку лет назад можно было было создать тред Ruby vs Rails, и добиться примерно того же результата, что ТС.

Вот и я о том же. Rails будет сложнее и неоднозначнее чистого Ruby. А может ещё и подойдёт не всем.

И да, про докер :)

Как по мне, так самая серьёзная фишечка это возможность распространять приложения как Dockerfile. Ну и, соответственно, из этих докерфайлов быстро поднимать инфраструктуру.

А в остальном докер это довольно компактная и мало кому подходящая надстройка над LXC.

Если закроешь виртуалку, все изменения откатятся, вернётся к исходному состоянию

Не откатываются, остаются в контейнере. Еще в контейнер можно смонтировать внешнюю директорию, вроде так рекомендуется делать для директорий с изменяемыми данными.

Концептуально, но не технологически

И корректнее сказать не «приложения», а «роли».

надстройка над LXC.

Уже не только LXC

Не откатываются, остаются в контейнере.

Если ты их не закоммитил, то их нет в последнем слое образа, соответственно, они не сохраняются.

Почему же?

$ docker run -t -i --name test_persistent ubuntu /bin/bash
# docker touch qwe
# exit
$ docker start test_persistent
$ docker attach test_persistent
# ls

Файл qwe на месте

bump

А все таки, почему говорят что в docker контейнеры не сохраняют состояние, когда этот пример показывает обратное?

Есть ещё systemd-nspawn. Есть из коробки в любом дистрибутиве со свежим systemd.

Все эти lxc, syste md-nspawn, docker это интерфейсы над ядерными namespaces (для изоляции) и cgroups (для ограничения ресурсов), все тоже самое можно сделать на баше из (echo, unshare, mount). Из этого nspawn самая минималистичная, но с интеграцией с монстром, в lxc неплохо сделано управление доступом к железу (в докере такого не видел, но может не осилил), в docker куча возможностей для управления Биллом, удалённого управления, образами из репозитория, готовым подходом к настройке сети. В общем-то получается, как и в других случаях если программа хочет сделать все хорошо, то все прекрасно пока попадаешь в тот юзкейс, который предполагают разработчики, и хоть к докеру может быть много претензий - он простой и работает. Лично у меня используется на разработческой системе и докер и самописный контейнер для разных целей.

Ну, Docker для Linux LXC — это как менеджер Jail из nullfs хоста FreeBSD с возможностью отката к снапшотам ZFS, если что пошло не так.

это как менеджер Jail

Только вот джейлам даже до LXC еще пилить и пилить.

Потому что не могут в терминологию. Контейнеры сохраняют состояние, образы — нет.

$ docker run -t -i --name test_persistent ubuntu /bin/bash
root@72458dc05c26:/# touch qwe
root@72458dc05c26:/# exit
$ docker commit test_persistent qwe_ubuntu
df8b55cd917bbdd9492a28e2c7eb55a4a08377cdc2f542bb1db1d2e7eeffe067
$ docker run -it --rm qwe_ubuntu
root@ebf5c70ad293:/# test -e qwe
root@ebf5c70ad293:/# echo $?
0
root@ebf5c70ad293:/# touch rty
root@ebf5c70ad293:/# exit
$ docker run -it --rm qwe_ubuntu
root@0d4a667e69c2:/# test -e qwe
root@0d4a667e69c2:/# echo $?
0
root@0d4a667e69c2:/# test -e rty
root@0d4a667e69c2:/# echo $?
1
root@0d4a667e69c2:/# exit

В чем собственно суть docker? Это просто чуть более юзер-френдли утилита для управления lxc? Или это все же нечто большее?

Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups). Для создания контейнеров предлагается использовать libcontainer (обёртка над namespaces и cgroups), также возможно применение lxc, libvirt, systemd-nspawn и других систем изоляции. Для формирования контейнера достаточно загрузить базовый образ окружения (docker pull base), после чего можно запускать в изолированных окружениях произвольные приложения (например, для запуска bash можно выполнить «docker run -i -t base /bin/bash»).

via http://www.opennet.ru/opennews/art.shtml?num=42058

Докер нужен, когда идет непрерывная разработка и выброс новой фичи в продакшен. Связка Vagrant, docker, lxc, npm, jenkins, gitlab (порядок не важен) очень спасает. Каждый разраб имеет шикарную возможность из общей репы поднять себе рабочее полностью готовое окружение как на реальной машине (или кусочек общего окружения, например, только frontend). Минимальные конфиги и все взлетело. Я сначала тоже хотел взять бейдж неосилятора, но потом раскурил мануал и втянулся. Такие дела.

Ну во-первых, я уже более чем освоился с докером, и мало того - ежедневно его юзаю.

А во-вторых - что в перечне делает npm?

так а чем любая другая контейнеризация не подходит?

с твоих слов не увидел отличий от vagrant :)

Тут скорее преимущество не в самой контейнеризации как таковой, а в удобной обвязке (иструменты управления и тулзы, идущие в комплекте с Docker), а также в большом количестве сторонних инструментов для управления контейнерами.

Читал только первые две строки?

читал

говорю же, контекст другой :)

npm замени (добавить) на любой пакетный менеджер. автоматика, люк

Тогда так бы и написал, зачем в сообщении хардкодить npm?

с твоих слов не увидел отличий от vagrant :)

Vagrant (англ. бродяга) — свободное и открытое программное обеспечение для создания и конфигурирования виртуальной среды разработки[1]. Является обёрткой для программного обеспечения виртуализации, например VirtualBox.

В версии 1.6 реализована встроенная поддержка для использования контейнерной виртуализации на базе LXC с применением инструментария Docker.

vagrant — скорее что-то сравнимое с docker compose:
http://www.newmediacampaigns.com/blog/docker-for-php-developers

ну что там такого в обвязке? С текущими недочетами об обвязке не может быть и речи и это не очень аргумент.

А чем не устраивает OpenVZ?

текущими недочетами

Какими например?

А чем не устраивает OpenVZ?

Некропостишь)

OpenVZ не устраивает в первую очередь тем, что требует кастомного vz-ядра.

Некропостишь)

да не. в продакшене еще 2.6.18 присутствуют.

OpenVZ не устраивает в первую очередь тем, что требует кастомного vz-ядра.

Завести тачку в qemu/kvm, а в ней уже контейнеры - я делаю так.

да не. в продакшене еще 2.6.18 присутствуют.

Посмотри на дату начального поста.

ну, годик прошел - а что изменилось? Ничего =)