Всё пропало, файловые блокировки выпилили?

AmdY

Пью пиво
Команда форума
Ты вендоров в образ что ли кладешь? Это примерно то же, что их коммитить в репоз, если чо.
Я прод образ кладу, это решает 100500 практических проблем, образ сразу готов к работе и не надо проводить деплой на нём. А что с этим способом не так?
 

fixxxer

К.О.
Партнер клуба
Я прод образ кладу, это решает 100500 практических проблем, образ сразу готов к работе и не надо проводить деплой на нём. А что с этим способом не так?
А если composer.lock поменялся, ручками пересобирать что ли? А если забыл? А если поменял, выложил новый билд, а потом, опа, чот упало и надо откатиться?

Все нормальные CI умеют кэшировать степы джобов по хэшу контента, и composer install сводится к копированию из кэша.
 

WMix

герр M:)ller
Партнер клуба
А если composer.lock поменялся, ручками пересобирать что ли?
в проде? его уже может и нет там,
для dev монтирую соурс для прода копирую.
Это примерно то же, что их коммитить в репоз, если чо.
нет, я так не считаю, есть готовый контейнер со всеми зависимостями, это к соурс никакого отношения уже не имеет, это другой уровень.
задача простая, docker run name
Все нормальные CI умеют кэшировать степы джобов
все контроли версий умеют хранить изменения
 

WMix

герр M:)ller
Партнер клуба
 

fixxxer

К.О.
Партнер клуба
ну да, вместо того, чтобы банально на ci сделать git clone, composer install и npm run build, давайте извращаться и расписывать каждый файл. Симплифай!

против слоя с вендорами я ничего не имею (это легко автоматизируется на ci), но это по сути вариация на тему кэша, и делается это все не так
 

WMix

герр M:)ller
Партнер клуба
ну да, вместо того, чтобы банально на ci сделать git clone, composer install и npm run build,
вместо того чтоб иметь банально простой контейнер с пхп, простой с композером, простой с нодой и все из официальных источноков ставим гит ноде и остальную лабудень в один
 

WMix

герр M:)ller
Партнер клуба
docker exec -rm git git clone && docker exec -rm composer composer install && docker exec -rm node npm run build
можно так, вопрос только куда?
 

fixxxer

К.О.
Партнер клуба
Гиту и композеру вообще нечего делать в имеджах для продакшена. Они только в том специальном сборочном имедже, который запускается в CI, и задача которого собрать другие имеджи. Обычно сборочный наследуется от некоторого базового продового.

Простой контейнер с пхп, да, конечно, я где-то предлагал все класть в один? Образ с самим php отдельно, код приложения отдельно. А вот с вендорами это сомнительная затея.
Я не знаю, может, у вас зависимости зафиксированы так, что добавление библиотеки в проект - это целая история с согласованиями и прочим. Тогда можно и отдельно.
А когда библиотека может просто появиться в любом фиче бранче, да и свои приватные зависимости точно так же ставятся через композер из приватных репозиториев и обновляются регулярно, это все становится диким оверхедом. Намного проще иметь весь PHP-код с зависимостями как единое целое, и считать git clone и composer install единой операцией "сборки". Ну, деплоиться будет на пару секунд подольше, и чо.
 
Последнее редактирование:

WMix

герр M:)ller
Партнер клуба
А когда библиотека может просто появиться в любом фиче бранче
хороший вопрос, пока в кучу кидаем, но еще не потерял обзор, не то чтоб зоопарк, хотя фронт еще тот пис... но это не про меня ) может я че не понимаю )
Намного проще иметь весь PHP-код с зависимостями как единое целое
я про тоже, и просто kubectl apply или как там
считать git clone и composer install единой операцией "сборки".
да, просто docker build и какая разница че внутри, на выходе чистая аппликация без кужурок в готовом php-fpm образе опять же со всеми расширениями и тд и тп
 

fixxxer

К.О.
Партнер клуба
какая разница че внутри
Никакой, если оно работает.
Вот я добавил зависимость, запушил фичу вместе с обновленными composer.json и composer.lock в веточку, по хуку запустился CI, отдеплоил на стейдж, и все работает.
А уж отдельным там слоем вендоры или нет, это не суть важно.

Понятно, что ту же логику можно применить и к, скажем, pecl-расширениям, но добавлять pecl-расширения надо очень редко, а вот composer.lock меняется часто.

пока в кучу кидаем
А если фичеветка - это переход со, скажем, Laravel 5.x на Laravel 7? Но ладно, это само по себе большая затея, а вот что-то менее глобальное, какая-нибудь новая версия, скажем, Guzzle, так что в коде меняется только свой враппер вокруг него, сохраняя совместимое API, и чем-то мажорным вообще не является?
 
Последнее редактирование:

grigori

( ͡° ͜ʖ ͡°)
Команда форума
тут надо уточнять: не "когда библиотека может просто появиться в любом фиче бранче", а "когда денег в проекте немного, высокоуровневой архитектурой никто не занимается, одна команда разработки, зависимости не отслеживаются, и всем пофиг"

в проекте, которому больше 5 лет, я вижу три версии ноды, yii с контейнером symfony, и вендоров на пару гигабайт

А если composer.lock поменялся, ручками пересобирать что ли? А если забыл? А если поменял, выложил новый билд, а потом, опа, чот упало и надо откатиться?
Если vendors в репе - git не дает забыть про изменения.

А rolling updates aka blue-green deployment. Ты как приложение-то выкатываешь, что у тебя старые вендоры могут остаться?
Вообще, это надо постараться выкатить deployment на pod-ы так, чтобы часть файлов осталась от другого pod-а ... просто не клади вендоров в volume на продах.

> деплоиться будет на пару секунд подольше
сам деплой усложняется: на продах сеть закрыта, доставка идет из репы образов, как именно это организовать?
на build-сервере добавлять vendors в деплой рядом с кодом приложения? какое преимущество выполнения composer install на build-сервере?

> какая-нибудь новая версия, скажем, Guzzle, так что в коде меняется только свой враппер вокруг него, сохраняя совместимое API
Как этот вопрос подтверждает тезис о том, что коммитить вендоров неудобно?
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
когда денег в проекте немного, высокоуровневой архитектурой никто не занимается, одна команда разработки, зависимости не отслеживаются, и всем пофиг"
Да, нет, да, нет, нет.
Если vendors в репе -
то это какой-то звездец, может, еще бинарь php в репу положить?

Ты как приложение-то выкатываешь, что у тебя старые вендоры могут остаться?
У меня - не могут. Выкатываю я уже говорил как. На CI сборочный образ, он делает git clone, composer install, и собирает образ, который по сути чистый data volume с php-кодом вместе со всеми вендорами. Каталог vendor кэшируется на CI по хэшу composer.lock, но это для ускорения билда, принципиально это ничего не меняет.

А вот как этого простым способом избежать, если вендоры билдятся отдельно, я не знаю.

какое преимущество выполнения composer install на build-сервере?
А где, блин, запускать процедуру билда (частью которой по определению является composer install), кроме как на билд-сервере? "Какое преимущество того, чтобы суп есть ложкой?" Я не знаю как ответить на такой вопрос
 
Последнее редактирование:

WMix

герр M:)ller
Партнер клуба
кстати на счет vendor и dev-env как вы делаете? те есть windows с php-storm, есть vm. синхронизация кода по scp типа deploy.
git встроен в ide. composer запускаем в vm но папка vendor нужна и на хосте, после git switch обновления должны уйти в vm.
те вопрос как вы это делаете (постоянно нажимать upload/download поднадоело)
 

флоппик

promotor fidei
Команда форума
Партнер клуба
А почему не делать просто в докере? В vm что-то специфическое собрано?
 

WMix

герр M:)ller
Партнер клуба
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
кстати на счет vendor и dev-env как вы делаете?
Код лежит на хостноде, монтируется в контейнер через bind mount.
Код:
dev-docker$ cat composer
#!/bin/sh
docker-compose exec php composer $@
cd repo
git pull ...
cd dev-docker
./composer install

я помучался с docker под виндой с этими PowerShell
зачем? WSL же есть. Хотя у нас никто на винде не работает, но вроде с WSL там проблемы ровно такие же, как на маке (единстванная - с disk io).
С disk io проблема решается через docker-sync, хотя я сам не пробовал, но люди пользуются.

со всеми proxy и dns достаточно хлопот
Вообще никаких проблем не должно быть.
 
Последнее редактирование:
Сверху