blog [dot] hook

Записи

Данная статья является копией публикации на хабре В данной статье я расскажу о своём опыте “заворачивания” Laravel-приложения в Docker-контейнер да так, что бы и локально с ним могли работать frontend и backend разработчики, и запуск его на production был максимально прост. Так же CI будет автоматически запускать статические анализаторы кода, phpunit-тесты, производить сборку образов. “А в чём, собственно, сложность?” - можешь сказать ты, и будешь отчасти прав. Дело в том, что этой теме посвящено довольно много обсуждений в русскоязычных и англоязычных комьюнити, и почти все изученные треды я бы условно разделил на следующие категории: “Использую докер для локальной разработки. Ставлю laradock и беды не знаю”. Круто, но как обстоят дела с автоматизацией и запуском на production? “Собираю один контейнер (монолит) на базе fedora:latest (~230 Mb), ставлю в него все сервисы (nginx, бд, кэш, etc), запускаю всё супервизором внутри”. Тоже отлично, прост в запуске, но как на счёт идеологии “один контейнер - один процесс”? Как обстоят дела с балансировкой и управлением процессами? Как же размер образа? “Вот вам куски конфигов, приправляем выдержками из sh-скриптов, добавим магических env-значений, пользуйтесь”. Спасибо, но как же на счёт хотя бы одного живого примера, который я бы мог форкнуть и полноценно поиграться? Всё, что ты прочитаешь ниже - является субъективным опытом, который не претендует быть истиной в последней инстанции. Если у тебя будут дополнения или указания на неточности - welcome to comments. Для нетерпеливых - ссылка на репозиторий, склонировав который ты сможешь запустить Laravel-приложение одной командой. Так же не составит труда его запустить на том же rancher, правильно “слинковав” контейнеры, или использовать продуктовый вариант docker-compose.yml как отправную точку.

Столкнулся с ситуацией, когда необходимо переопределить расположение .env файла, который используется, к примеру - для запуска phpunit тестов. Да, если в корне приложения имеется файл .env.testing - то он автоматически будет прочитан фреймворком при APP_ENV равным testing, но вот что делать, если этот файл необходимо разметить в какой-либо другой директории? Давай расположим его в ./env.d/ дабы, например, не “мусорить” в корне приложения.