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

AmdY

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

fixxxer

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

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

WMix

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

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 достаточно хлопот
Вообще никаких проблем не должно быть.
 
Последнее редактирование:
Сверху