Комментарии 13
Я обычно решаю проблему раздачи статики выделяя общий volume между контейнерами app и nginx, в которой app, при старте копирует то что должен раздавать nginx - js, css и прочие файлы изменяющиеся только при деплое новой версии приложения.
Кстати ещё нужные отдельные volume для storage/app и storage/logs
А как же кэши или вы при каждом рестарте контейнера их в ините прогреваете?
У меня как раз один из вариантов, о которых писал, был выделение volume, но от него отказался, так как особо смысла не имеет.
А зачем для storage и logs отдельный делать? Что за счет этого получаете?
Storage отдельно, потому что контентные файлы обычно хранятся в отдельном хранилище, например NFS или Ceph. Или S3, но тогда уже volume не нужен.
Volume для logs чтобы расшарить его с контейнером сборщика логов.
Ну тогда да, это не volume.
Не лучший вариант по логам. Лучше например отправлять в вектор.
```
'vector' => [
'driver' => 'monolog',
'handler' => \Monolog\Handler\SocketHandler::class,
'handler_with' => [
'connectionString' => 'tcp://vector:9000',
],
'formatter' => \Monolog\Formatter\JsonFormatter::class,
],
Один из немногих, но существенный недостаток php - это его синхронность. Отправка логов/трейсов по сети снижает производительность приложения и создаёт опасность зависания, если принимающая сторона ляжет. Запись в файл выступает неблокирующим буфером.
Тут конечно можно порассуждать, что сайдкар vector врядли ляжет, а если и ляжет то это проблема всего пода. Можно ещё подумать что запись на диск не сильно медленее чем взаимодействие с вектором через локалхост. Да. Но у меня осадочек остался, а попытаться ещё раз пока руки не дошли.
а как же контейнеры для очередей и шедулера, желательнее на кроне) а ну и локальный контейнер для пхп лучше запускать от юзера 1000:1000 ведь не все разрабатывают на ликунсе, многие на винде + wsl а там без этого юзера будут проблемки. затем ещё надо бы добавить ротацию логов со всех контейнеров, так или иначе логи критически важная часть приложения. а ещё для тестов надо бы отдельную БД. и в пайплане деплоя миграцию запускать только после готовности БД
ну да ладно у меня перфекционизм просто в терминальной стадии🤒
В моем кейсе было не актуально, но если требуется - рядом можно запустить Supercronic.
UID и GID - 999, дистр совместим на сколько я знаю и под винду, в явном виде отдельно не имеет смысла ставить. Если бы собирал с alpine руками, тогда наверное да.
Ротация да, обязательно. Сейчас себе хочу подсистему мониторинга и логирования развернуть, под мои проекты на VPS. Статья вроде зашла, поэтому напишу вторую с результатами.
Для тестов отдельная БД поднимается в рамках Action. Я переписал в последней итерации почти все, времени уже на тесты не было - поэтому в workflow последнем база не создается, но в начале статьи, вы можете увидеть пример.
Отличный у вас на самом деле перфекционизм :)
пхп лучше запускать от юзера 1000:1000 ведь не все разрабатывают на ликунсе, многие на винде + wsl
Я обычно решаю это так: разработчики клонируют репозиторий с конфигами для локального разворота, и там в конфигах есть докерфайл для сборки dev образа, куда через аргумент передаётся uid/gid пользователя которого надо создать в образе, чтобы далее при монтировании папки с исходниками, независимо от того где создаётся файл - на хосте или в контейнере, у него был один и тот же uid владельца.
FROM unit:php8.4 AS production
RUN php artisan key:generate
Так нельзя в проде, это приведёт к потере доступа к зашифрованным данным
История создания идеального Docker для Laravel