Приложение в docker: зачем разделять по контейнерам?

Question

[sindrom]

Начинаю знакомиться с Docker. Мне нравится идея изоляции всех зависимостей сложного приложения внутри одного контейнера. Но из чтения мануалов узнал о необходимости разделения сервисов (например: nginx, php-fpm, mysql, mongo, redis), входящих в состав приложения, на разные контейнеры и последующая их линковка. Не совсем понимаю зачем это нужно делать. Почему нельзя создать один контейнер со всеми необходимыми зависимостями внутри? Или это невозможно технически?

Answer 1

[Сергей]

я бы поспорил относительно изоляции =). на хабре как раз была великолепная статья на эту тему. habrahabr.ru/post/258595 дыр столько что данное супермегачудо подходит разве только для домашнего сервака для "поиграться!"

Answer 2

[iborzenkov]

Да ни зачем это не нужно.
У них мануалы написаны потому что круто мы так могем.
Сделайте отдельный контейнер с (nginx, php-fpm, mysql, mongo, redis) и вашим сайтом и отлично. Я вообще вижу смысл разделять только на 3 части на продакшене - хранилище, в котором лежат все ваши базы и которое нужно бэкапить (как раз удобно - контейнером), код, который вы при деплое меняете и маштабируете и балансеры, которые одни у приложения
В базовых контейнерах задача развернуть по быстрому утилиту чтобы посмотреть.
Поверьте, ничего хорошего из этого не выйдет

sudo docker ps | wc -l
92

при 10 сервисах

Объединяйте в контейнер ваше приложение, если вашему веб-приложению требуются для работы несколько баз, с десяток воркеров на бэкэнде, сложный конфиг нгинкса куча кронов и так далее, то вот это все и заверните в один контейнер.
Ну а если у вас простой сайт на стандартном фреймворке и одной базе, то не очень то и нужны вам контейнеры.

Comments

[evnuh]

Вот у меня случай с кучей разных баз разных конфигов всякие компиляторы кроны и т.д и все это работает только вместе. Стоит ли мне начинать париться с докером чтобы получить плюсы быстрого разворачивания всего добра или все же можно обойтись одним мега скриптом для автонастройки всего и вся?)

[sindrom]

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

[iborzenkov]

Конечно стоит, только не плодите кучу контейнеров, иначе это не будет особо отличаться от того что у вас сейчас

[evnuh]

iborzenkov: sindrom: а какой тогда смысл? Всё запихать в 1 контейнер и разворачивтаь его одной командой - это всё равно что установить чистую ОСь и запустить мой скрипт. Разницы принципиальной в удобстве вроде бы нет.

[iborzenkov]

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

[sindrom]

evnuh: Смысл есть.
Во-первых, это быстрее. Намного быстрее. Развернуть готовый докер контейнер на новой машине - дело нескольких секунд. Скрипт установки может выполняться десятки минут, а то и дольше (в зависимости от сложности приложения).
Во-вторых, это надежнее. Да, скрипты установки и системы провижинга серверов (вроде ansible или chef) конечно решают проблему быстрого развертывания приложения, но все равно не дают полной уверенности что все установится и настроится на 100% правильно. Вы до сих пор зависите от дистрибутива операционной системы, а это значит, что какого-то пакета может не оказаться в репозитории, или какая то утилита будет работать немного иначе и т.д.
Кроме того, нужно быть очень внимательным, чтобы не забыть указать в скрипте установки все необходимые настройки, переменные окружения, конфиги и многое другое.
В-третьих, это легче тестировать. Представьте, что вы хотите установить новую версию PHP, но не уверены, что после этого приложение будет работать корректно. В этом случае вы можете сделать форк своего образа с новой версией PHP, а если что-то пойдет не так, то за секунды запустить приложение на старом образе.
Скрипты деплоя в этом случае помочь вам точно не смогут.

Есть еще много причин, но я постарался описать три самых важных.

[evnuh]

sindrom: спасибо за разъяснения!