Разные development и production окружения не нарушают концепцию Docker?

Question

[l4m3r]

Смысл докера все сделать 1 в 1 как на продакшене, но ведь пока разрабатываешь нужно же подключить php.ini-development, а не production. Xdebug. Composer. NodeJs нужен, чтобы ресурсы скомпилить. Пробрасывать локального пользователя, чтобы в volume не из-под рута файлы были.
На продакшене ничего этого не нужно.
Получается разные docker-compose, разные Dockerfile (хотя я слышал про multi-stage, да), разные пробрасываемые конфиги? Есть пример хорошо написанного boilerplate php-приложения с docker?

Answer 1

[Vamp]

В dev окружении почти никогда не бывает такой же образ как в prod. Но docker позволяет сделать очень близко к проду при помощи наследования. То есть prod наследуется от, допустим, php:7.3.3-fpm, устанавливает нужные модули и опции php.ini, а dev образ наследуется от prod и доустанавливает xdebug, composer, node, модифицирует только нужные для дева опции php.ini.

Такая организация позволяет почти не тратить время на актуализацию dev образа. Поменялся prod - в одну команду пересобрали и dev. Очень удобно.

Корнем всей иерархии будет это базовый prod образ, в котором нет никаких файлов проекта. Уже от него наследуются dev и образы с запакованным приложением. В контейнер на основе dev образа монтируете рабочую директорию проекта и работаете как удобно.

Иерархия наследования получается примерно такая:

php:7.3.3-fpm
└─ prod:base
   ├─ dev:latest
   ├─ prod:0.0.1
   ├─ prod:0.1.15
   └─ prod:1.0.4
      └─ prod:latest  (плавающий тег, указывающий
                       на самый свежий релиз)

При таком подходе у вас будет 3 докерфайла - prod:base, dev и финальный prod.

Можно обойтись двумя докер файлами, если на прод подсовывать скрипты проекта через volume, как и в dev. Я как раз использую этот вариант, так как в моей компании применяется continuous delivery. Грубо говоря, это когда почти каждый коммит в master сразу улетает на прод. Если каждый раз собирать новый образ, становится слишком много образов, за которыми приходится отдельно следить и удалять старые, чтобы избежать переполнения реестра. Плюс возникают сложности с обеспечением атомарности деплоя, так как сервис становится недоступен в момент рестарта контейнера, из-за чего приходится городить балансировку и/или blue-green деплоймент.

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

Comments

[l4m3r]

В prod надо делать COPY всех файлов проекта в образ. В dev - использовать volumes. Каким образом второе от первого наследуется?

[Vamp]

Дополнил решение ответом на ваш вопрос.

[l4m3r]

Vamp, спасибо! Отличный ответ. Буду пробовать. Подскажите, у вас нет ли ссылки на подобный хороший пример docker-compose.yml / Dockerfile? Просто чтобы опираться на что-то.

[Vamp]

Хорошего примера не знаю. Самому пришлось собирать информацию по крупинкам из многочисленных экспериментов и чужих докерфайлов. Чуть позже обновлю решение своим примером.