Я прод образ кладу, это решает 100500 практических проблем, образ сразу готов к работе и не надо проводить деплой на нём. А что с этим способом не так?
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
А если composer.lock поменялся, ручками пересобирать что ли? А если забыл? А если поменял, выложил новый билд, а потом, опа, чот упало и надо откатиться?
Все нормальные CI умеют кэшировать степы джобов по хэшу контента, и composer install сводится к копированию из кэша.
в проде? его уже может и нет там,
для dev монтирую соурс для прода копирую.
нет, я так не считаю, есть готовый контейнер со всеми зависимостями, это к соурс никакого отношения уже не имеет, это другой уровень.
задача простая, docker run name
все контроли версий умеют хранить изменения
Creating Multi-Stage Docker Builds for Laravel
Starting in Docker version 17.05 multi-stage builds are available to help you optimize Dockerfiles. Using multi-stage builds is a clean way to set up a Docker build pipeline that simplifies the requirements you need on your CI/build server to create a Docker image for your app. Come along with...
laravel-news.com
ну да, вместо того, чтобы банально на ci сделать git clone, composer install и npm run build, давайте извращаться и расписывать каждый файл. Симплифай!
против слоя с вендорами я ничего не имею (это легко автоматизируется на ci), но это по сути вариация на тему кэша, и делается это все не так
против слоя с вендорами я ничего не имею (это легко автоматизируется на ci), но это по сути вариация на тему кэша, и делается это все не так
вместо того чтоб иметь банально простой контейнер с пхп, простой с композером, простой с нодой и все из официальных источноков ставим гит ноде и остальную лабудень в один
Гиту и композеру вообще нечего делать в имеджах для продакшена. Они только в том специальном сборочном имедже, который запускается в CI, и задача которого собрать другие имеджи. Обычно сборочный наследуется от некоторого базового продового.
Простой контейнер с пхп, да, конечно, я где-то предлагал все класть в один? Образ с самим php отдельно, код приложения отдельно. А вот с вендорами это сомнительная затея.
Я не знаю, может, у вас зависимости зафиксированы так, что добавление библиотеки в проект - это целая история с согласованиями и прочим. Тогда можно и отдельно.
А когда библиотека может просто появиться в любом фиче бранче, да и свои приватные зависимости точно так же ставятся через композер из приватных репозиториев и обновляются регулярно, это все становится диким оверхедом. Намного проще иметь весь PHP-код с зависимостями как единое целое, и считать git clone и composer install единой операцией "сборки". Ну, деплоиться будет на пару секунд подольше, и чо.
Простой контейнер с пхп, да, конечно, я где-то предлагал все класть в один? Образ с самим php отдельно, код приложения отдельно. А вот с вендорами это сомнительная затея.
Я не знаю, может, у вас зависимости зафиксированы так, что добавление библиотеки в проект - это целая история с согласованиями и прочим. Тогда можно и отдельно.
А когда библиотека может просто появиться в любом фиче бранче, да и свои приватные зависимости точно так же ставятся через композер из приватных репозиториев и обновляются регулярно, это все становится диким оверхедом. Намного проще иметь весь PHP-код с зависимостями как единое целое, и считать git clone и composer install единой операцией "сборки". Ну, деплоиться будет на пару секунд подольше, и чо.
Последнее редактирование:
хороший вопрос, пока в кучу кидаем, но еще не потерял обзор, не то чтоб зоопарк, хотя фронт еще тот пис... но это не про меня ) может я че не понимаю )
я про тоже, и просто kubectl apply или как там
да, просто docker build и какая разница че внутри, на выходе чистая аппликация без кужурок в готовом php-fpm образе опять же со всеми расширениями и тд и тп
Никакой, если оно работает.
Вот я добавил зависимость, запушил фичу вместе с обновленными composer.json и composer.lock в веточку, по хуку запустился CI, отдеплоил на стейдж, и все работает.
А уж отдельным там слоем вендоры или нет, это не суть важно.
Понятно, что ту же логику можно применить и к, скажем, pecl-расширениям, но добавлять pecl-расширения надо очень редко, а вот composer.lock меняется часто.
А если фичеветка - это переход со, скажем, Laravel 5.x на Laravel 7? Но ладно, это само по себе большая затея, а вот что-то менее глобальное, какая-нибудь новая версия, скажем, Guzzle, так что в коде меняется только свой враппер вокруг него, сохраняя совместимое API, и чем-то мажорным вообще не является?
Последнее редактирование:
на данный момент будет отдельный контейнер с 5 и отдельный с 7, тесты есть, тестеры есть, и не понимаю как тут feature toggle использовать
тут надо уточнять: не "когда библиотека может просто появиться в любом фиче бранче", а "когда денег в проекте немного, высокоуровневой архитектурой никто не занимается, одна команда разработки, зависимости не отслеживаются, и всем пофиг"
в проекте, которому больше 5 лет, я вижу три версии ноды, yii с контейнером symfony, и вендоров на пару гигабайт
А rolling updates aka blue-green deployment. Ты как приложение-то выкатываешь, что у тебя старые вендоры могут остаться?
Вообще, это надо постараться выкатить deployment на pod-ы так, чтобы часть файлов осталась от другого pod-а ... просто не клади вендоров в volume на продах.
> деплоиться будет на пару секунд подольше
сам деплой усложняется: на продах сеть закрыта, доставка идет из репы образов, как именно это организовать?
на build-сервере добавлять vendors в деплой рядом с кодом приложения? какое преимущество выполнения composer install на build-сервере?
> какая-нибудь новая версия, скажем, Guzzle, так что в коде меняется только свой враппер вокруг него, сохраняя совместимое API
Как этот вопрос подтверждает тезис о том, что коммитить вендоров неудобно?
в проекте, которому больше 5 лет, я вижу три версии ноды, yii с контейнером symfony, и вендоров на пару гигабайт
Если vendors в репе - git не дает забыть про изменения.
А rolling updates aka blue-green deployment. Ты как приложение-то выкатываешь, что у тебя старые вендоры могут остаться?
Вообще, это надо постараться выкатить deployment на pod-ы так, чтобы часть файлов осталась от другого pod-а ... просто не клади вендоров в volume на продах.
> деплоиться будет на пару секунд подольше
сам деплой усложняется: на продах сеть закрыта, доставка идет из репы образов, как именно это организовать?
на build-сервере добавлять vendors в деплой рядом с кодом приложения? какое преимущество выполнения composer install на build-сервере?
> какая-нибудь новая версия, скажем, Guzzle, так что в коде меняется только свой враппер вокруг него, сохраняя совместимое API
Как этот вопрос подтверждает тезис о том, что коммитить вендоров неудобно?
Последнее редактирование:
Да, нет, да, нет, нет.
то это какой-то звездец, может, еще бинарь php в репу положить?
У меня - не могут. Выкатываю я уже говорил как. На CI сборочный образ, он делает git clone, composer install, и собирает образ, который по сути чистый data volume с php-кодом вместе со всеми вендорами. Каталог vendor кэшируется на CI по хэшу composer.lock, но это для ускорения билда, принципиально это ничего не меняет.
А вот как этого простым способом избежать, если вендоры билдятся отдельно, я не знаю.
А где, блин, запускать процедуру билда (частью которой по определению является composer install), кроме как на билд-сервере? "Какое преимущество того, чтобы суп есть ложкой?" Я не знаю как ответить на такой вопрос
Последнее редактирование:
только что-то они реально описание отфонарное написали, типа WSL 2 это не HyperV - хотя как раз именно он родимый в отличие от WSL 1
кстати на счет vendor и dev-env как вы делаете? те есть windows с php-storm, есть vm. синхронизация кода по scp типа deploy.
git встроен в ide. composer запускаем в vm но папка vendor нужна и на хосте, после git switch обновления должны уйти в vm.
те вопрос как вы это делаете (постоянно нажимать upload/download поднадоело)
git встроен в ide. composer запускаем в vm но папка vendor нужна и на хосте, после git switch обновления должны уйти в vm.
те вопрос как вы это делаете (постоянно нажимать upload/download поднадоело)
docker
я помучался с docker под виндой с этими PowerShell плюс на каждом шаге свои исключения, и собрал vm там со всеми proxy и dns достаточно хлопот
Последнее редактирование:
Код лежит на хостноде, монтируется в контейнер через bind mount.
Код:
dev-docker$ cat composer
#!/bin/sh
docker-compose exec php composer $@git pull ...
cd dev-docker
./composer install
зачем? WSL же есть. Хотя у нас никто на винде не работает, но вроде с WSL там проблемы ровно такие же, как на маке (единстванная - с disk io).
С disk io проблема решается через docker-sync, хотя я сам не пробовал, но люди пользуются.
Вообще никаких проблем не должно быть.
Последнее редактирование: