Хм... Можно я тут немножко флейма по теме разведу? Я недавно ковырялся в докере, и как-то... разочаровался в нём, в общем. Разработчики обещали чуть ли ни серебряную пулю, решающую все проблемы сразу, а на деле вышло как обычно: интересная хренька для решения достаточно ограниченного круга задач.

Если более развёрнуто:

• Docker расчитан на запуск ровно одного приложения внутри контейнера. Но большинство реальных линусковых демонов обычно имеют неявные зависимости, вроде syslog, cron/logrotate, etc. Да, можно их все запустить под каким-нибудь supervisord. Я вообще пропатчил upstart для запуска полноценной CentOS 6 внутри контейнера. Но зачем весь этот геморрой, если есть LXC, в котором это всё работает из коробки?
• Предполагается, что все данные, используемые приложением, должны быть вынесены на внешний volume. И тут опять возникают проблемы. Во-первых, непонятно как это всё бэкапить (представьте себе тяжёлую БД внутри контейнера). Во-вторых, непонятно что именно нужно выносить. Нужно ли выносить /var/log? Или /etc/appname?
• На данный момент, нельзя менять настройки существующих контейнеров. Хочешь заэкспозить ещё один порт или добавить вольюм? Хрен тебе, а не вольюм: удаляй и пересоздавай =).
• docker-registry (тот, который можно поставить на свой сервер) работает через задницу и пользоваться им крайне неудобно.
• Весь трафик для exposed портов идёт через юзерспейсный прокси. Непонятно нафига это было сделано, если docker всё равно модифицирует правила iptables. Руками сделать по нормальному тоже не выйдет без страшных костылей, так как у всех контейнеров динамические IP и это никак не настраивается.
• Стандартный и рекомендуемый сторадж-драйвер для docker - это aufs, но его нет в мейнлайновом ядре. Если aufs не доступна, то используется device mapper. А там ЕМНИП до сих пор размеры контейнеров захардкожены.
• Обновления контейнеров... По идеологии докера, для обновления нужно просто снова создать образ с помощью докерфайла, а затем пересоздать все инстансы (естественно, все данные должны быть на внешних вольюмах, иначе они удалятся вместе с инстансами). Для большого числа разношорстных контейнеров это создаст кучу проблем, так как нормальных средств автоматизации пока не предусмотрено.

Но, есть как минимум два случая, когда docker юзабелен:

• Сервисы, которые специально разработаны для работы «в одиночку».
• Короткоживущие «виртуалки» со сборочными/тестовыми средами для CI.

Вся идеология в одном посте

Виртуализация (комментарий)

lol

Вот, кстати да, ещё один минус - Убунту ZverDockerImage с нескучными обоями и комплектом бэкдоров! =)

Когда возникли те же самые вопросы, я не нашел причин не использовать lxc.

Я недавно ковырялся в докере, и как-то... разочаровался в нём, в общем.

Я поначалу тоже: Docker vs голый LXC (комментарий)

Но всё меняется, порой — очень быстро :) И поэтому есть желание не оставаться в хвосте.

Docker расчитан на запуск ровно одного приложения внутри контейнера

Именно так. Но не:

Но большинство реальных линусковых демонов обычно имеют неявные зависимости, вроде syslog, cron/logrotate, etc

Это всё компоненты приложения. Если без лишних сущностей — всё это уже стоит в настроенном образе. При чём это может быть образ из любого дистрибутива, который лучше подходит под задачу.

Но зачем весь этот геморрой, если есть LXC

А Docker — это формально просто надстройка над LXC (хотя сейчас LXC ему уже не обязательно нужна), облегчающая жизнь и автоматизацию. Экономит ресурсы (не требуя копию ОС под каждый контейнер), облегчает разворачивание и связь контейнеров (мапинг портов и т.п.), добавляет инфраструктуру для работы с готовыми решениями.

Предполагается, что все данные, используемые приложением, должны быть вынесены на внешний volume

Вот тут и у меня возникают вопросы. Почему и завёл тему ;) Решать их можно разными способами, но не хочется плясать по граблям и ищутся уже проверенные решения.

Во-первых, непонятно как это всё бэкапить (представьте себе тяжёлую БД внутри контейнера).

Это, как раз, не вопрос. Бэкап БД в контейнере Докера не будет отличаться от бэкапа БД в контейнере LXC, а бэкап последней принципиально не отличается от бэкапа БД на хосте. Если БД тяжёлая, то хоть той же репликацией, хоть снэпшотом — в общем, тут уши те же.

Нужно ли выносить /var/log? Или /etc/appname?

Вот это как раз из серии вопросов «а как лучше сделать?» ради которых я тему и завёл. По идее, логи, которые хранить нужно персистентно, должны лежать на внешнем томе. Или в отдельном персистентном контейнере (если такие появились — я не очень понял идеи с --link, разбираюсь, раньше — не было) с лог-сервером.

Стандартный и рекомендуемый сторадж-драйвер для docker - это aufs, но его нет в мейнлайновом ядре

Ну, слава Богу, я пока такого не видел, aufs есть на всех системах, где работаю. И, тем паче, посматриваю на CoreOS, где docker вообще полагается из коробки :)

два случая, когда docker юзабелен
Сервисы, которые специально разработаны для работы «в одиночку»

Я, как раз, на это и ориентируюсь :) Мне со своим фреймворком часто приходится делать инстансы отдельных мелких проектов. Каждый раз начинается чехарда в виде создания нового LXC-контейнера, индивидуальных настроек его, разворачивания виртуального проекта... Хочется всё это автоматизировать и сделать независимым от хоста.

Это всё компоненты приложения. Если без лишних сущностей — всё это уже стоит в настроенном образе. При чём это может быть образ из любого дистрибутива, который лучше подходит под задачу.

Когда таких «компонент» становится много, становится непонятно как ими управлять. Конфиг там отдельный подправить, лог грепнуть и т.п. И опять же не понятно чем это лучше LXC.

А Docker — это формально просто надстройка над LXC (хотя сейчас LXC ему уже не обязательно нужна), облегчающая жизнь и автоматизацию. Экономит ресурсы (не требуя копию ОС под каждый контейнер), облегчает разворачивание и связь контейнеров (мапинг портов и т.п.), добавляет инфраструктуру для работы с готовыми решениями.

Docker и LXC по сути используют одни и те же средства линуксового ядра для получения почти одинакового результата. Раньше Docker использовал их посредством LXC, а теперь научился сам напрямую. Сути это не меняет: LXC - это почти полноценные виртуальные машины, а Docker - это виртуализация отдельных приложений. Причём граница тут не техническая, а какая-то... идеологическая что-ли. В LXC можно пускать отдельные приложения сами по себе, но неудобно. В Docker'е можно запускать полноценные виртуалки, с sshd и logrotate'ом, но неудобно.

Это, как раз, не вопрос. Бэкап БД в контейнере Докера не будет отличаться от бэкапа БД в контейнере LXC, а бэкап последней принципиально не отличается от бэкапа БД на хосте. Если БД тяжёлая, то хоть той же репликацией, хоть снэпшотом — в общем, тут уши те же.

Принципиально то то же, но докер всё усложняет. В случае «полноценных» виртуалок можно просто в каждую поставить тот же bacula-fd и применить к нему обычные универсальные файлсеты вроде «всё, кроме /tmp, /proc и т.п.». В случае докера идеологически более правильный способ - делать это всё снаружи контейнера, что создаёт дополнительные проблемы.

По идее, логи, которые хранить нужно персистентно, должны лежать на внешнем томе.

И придётся отдельно руками натравливать на них logrotate. Который в случае обычных виртуалок работает из коробки и с вполне адекватными настройками по умолчанию.

Каждый раз начинается чехарда в виде создания нового LXC-контейнера, индивидуальных настроек его, разворачивания виртуального проекта... Хочется всё это автоматизировать и сделать независимым от хоста.

LXC-контейнер разворачивается из тарболла, запускается (это две команды), затем в дело вступает puppet/chef/salt/etc. и донастраивает всё как надо автоматически.

Docker и задумывался как штука для виртуализации именно приложений (для демонов и несольких сервисов они рекомендуют Supervisor). Плюс git-овская схема коммитов/push/pull довольно удобна (почти всегда).

На счет device-mapper (thin pool) - уже напоролся на проблемы которые касаются заданных размеров пула при его создании, но не критичные. А aufs я думал есть в виде модуля доступного в репах федор/убунт.

А aufs я думал есть в виде модуля доступного в репах федор/убунт.

В Ubuntu оно по зависимостям штатно ставится в пару с docker.io

Когда возникли те же самые вопросы, я не нашел причин не использовать lxc.

Я тоже. LXC активно использую больше двух лет, на 4-6 машинах, десятка три контейнеров. Но теперь, похоже, дорос до виртуализации не целых проектов, а конкретных сервисов :)

Docker и задумывался как штука для виртуализации именно приложений

Да, я это понимаю. Но дело в том, что «хренька на питоне» - это приложение, а вот «httpd + cron + syslog + sshd + etc.» - уже нет =).

для демонов и несольких сервисов они рекомендуют Supervisor

supervisord - это костыль. Нужно либо поддерживать штатные init-системы, либо никак.

Плюс git-овская схема коммитов/push/pull довольно удобна (почти всегда).

Во-первых, да, ПОЧТИ. Пока не появится нормальных средств для автоматизации руления (в том числе - обновления, накатывания секьюрити-фиксов и т.п.) кучей контейнеров сразу - «не готово для продакшена». Во-вторых, как я уже сказал, использование приватного docker-registry сейчас сделано очень через задницу. Именно со стороны юзабилити.

А aufs я думал есть в виде модуля доступного в репах федор/убунт.

aufs нельзя просто так собрать модулем для ванильного ядра, в любом случае нужно патчить. В Ubuntu все патчи (как и модуль aufs, и юзерспейсные тулзы) есть из коробки. В RHEL и производных в стандартном ядре нужных патчей нет, так что aufs на нём без пересборки не завести вообще.

В RHEL и производных в стандартном ядре нужных патчей нет

Как хорошо, что я окончательно расплевался с RH ещё в 2004-м :D Правда, приходится, порой, админить CentOS, но, к счастью, не свою :D

И искренне не понимаю, как на _этом_ можно жить. Постоянно одни проблемы. То чего-то нет, то версии старые, то структура убогая, то при обновлении заглючит... Enterprise! :D

Как хорошо, что я окончательно расплевался с RH ещё в 2004-м :D Правда, приходится, порой, админить CentOS, но, к счастью, не свою :D

Конкретно в данном случае проблема не в RH, а в aufs. Её ведь нету не только в RHEL, а даже на kernel.org =).

Её ведь нету не только в RHEL, а даже на kernel.org =).

На kernel.org много чего нет :)

А так — мне не важны шашечки. Важно, чтобы ехало.

Результаты текущих изысканий по Docker в виде коллекции ссылок можно посмотреть на https://bitbucket.org/Balancer/bors-dev/src/e97297ec421cd4c32b50a68bffb3840bd...

Со связью контейнеров через --link разобрался, ничего сложного.

Про персистентные контейнеры пока не ковырял.

Так ничего толкового не нашёл по запуску контейнеров при старте системы. Это как-то автомтизируется (на манер lxc.start.auto = 1 у LXC) или же, всё же, надо запускать из своего скрипта по docker start ...?

Попутно прошёлся по современному состоянию серверов приложений, PaaS и прочему. Года два назад щупал, но не впечатлило ни разу. Потом следил только краем уха в теории. Сейчас полез — офигенно :) Выдают на халяву сразу виртуальные машины, готовые решения, порой, с полноценной ОС в виртуалке. OpenShift поюзал — интересно. Особенно впечатлила интеграция с Online IDE на примере Cloud 9: http://www.wrk.ru/tech/forum/2014/09/t90198--razrabotka-v-oblake.203.html

Надо будет по приколу привести свой фреймворк к варианту, легко разворачиваемому и в виде docker-образа, и на том же OpenShift.

И, похоже, судьба мне переезжать на GitHub :-/ Очень много сервисов, работающих с GitHub и git, но не работающих с Bitbucket и Mercurial. А жаль, мне Mercurial намного больше нравится :)

для демонов и несольких сервисов они рекомендуют Supervisor

внутри контейнера?

или супервизор на хосте должен дергать контейнеры?

В контейнере

http://docs.docker.com/articles/using_supervisord/

У меня тоже контейнеры начали плодиться. Раньше только при разработке разносил по контейнерам сервисы, которые в продакшене могут оказаться на разных серверах, чтобы тестировать было проще, но теперь и при переносе на рабочий сервер, даже если на нем все сервисы крутятся, я их разношу по контейнерам. Пока не определился хорошо это или плохо, но т.к. контейнеров становится многовато, задумался о централизованном управлении ими.

Результаты текущих изысканий по Docker в виде коллекции ссылок можно посмотреть на...

Вот за это спасибо, почитаем. Респект за то, что не забываешь делиться результатами поисков.

Как обновляются и обновляются ли готовые образы Docker?

Вот, к примеру, я использую образ dockerfile/elasticsearch без привязки к версии. Что будет и будет ли, когда появится новая версия elasticsearch?

Что будет и будет ли, когда появится новая версия elasticsearch?

Автоматически - ничего не будет. Тебе придётся пересоздавать контейнер для обновления.

Жаль :-/

Ещё вопрос. Что такое всякие user/package — это понятно. А вот чем отличаются (концептуально, так-то я вижу), скажем, ubuntu и dockerfile/ubuntu?

не пробовали что-то типа этого http://panamax.io/ ?

Сам себе отвечаю пол-года спустя:

Как лучше оформлять запуск контейнеров

Тут всё просто. --restart=always в параметрах запуска и контейнер сам стартует вместе с Docker. На всякий случай с каждум контейнером есть ещё и скрипт аварийного рестарта с docker stop ...; docker rm ...; docker run ...

как лучше организовывать/подключать персистентные данные (файлы, базы данных, логи) и т.п.?

Файлы и БД — в каталогах хоста и мапинг через -v

Логи пока особо не обрабатываю, но как раз сейчас дошёл до желания централизовать это дело. Например, https://www.loggly.com/blog/centralize-logs-docker-containers/

Или каждый лепит как попало в силу своей приверженности хаосу?

По факту так и есть, приходится самому для себя вырабатывать правила и искать оптимальные решения.