@l4m3r

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

Смысл докера все сделать 1 в 1 как на продакшене, но ведь пока разрабатываешь нужно же подключить php.ini-development, а не production. Xdebug. Composer. NodeJs нужен, чтобы ресурсы скомпилить. Пробрасывать локального пользователя, чтобы в volume не из-под рута файлы были.
На продакшене ничего этого не нужно.
Получается разные docker-compose, разные Dockerfile (хотя я слышал про multi-stage, да), разные пробрасываемые конфиги? Есть пример хорошо написанного boilerplate php-приложения с docker?
  • Вопрос задан
  • 572 просмотра
Решения вопроса 1
Vamp
@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. В этом случае можно и ручками обновить базовый образ на сервере. Но этот вариант хорош только когда мало серверов. Для больших кластеров конечно лучше работает вариант с упаковкой приложения в отдельный образ.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы