Vendors в git

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Есть общепринятая практика в репозитории хранить composer.lock и выполнять composer install при установке проекта.
Я так понимаю, основная цель - уменьшить потребление диска репозиториями.
У меня это регулярно создает проблемы.

Последние года два я запускаю сайты в контейнерах, и на самом сервере я не ставлю ни php, ни mysql.

1. Чтобы выполнить composer install мне надо сначала зайти в контейнер `docker exec -ti a9 /bin/sh`, потом в нем установить composer, и потом выполнить composer install.
Сomposer - не часть OS, не часть php, как был pear, и не часть приложения.
Следствие: у контейнера с php появляется внешний артефакт - composer, который нужен один раз.
Можно добавить composer в образ при сборке, но это как корове седло - у него отдельные от php релизы.
Можно ставить composer в контейнер при первом запуске службы, это просто небольшая лишняя работа.

2. Чтобы поставить vendors, нужны права записи php в контейнере в vendors/, и открырый исходящий трафик. А зачем они процессам, которые обрабатывают только входящий трафик?

3. Завсисимость от сторонних ресурсов

4. Из всего этого вытекает отдельный build-процесс, который должен собрать пакет, доставить его на POD или вместе с vendors, или выполнить composer install -o.
А какие средства доставки? Баду когда-то раскатывали образ FS, но мне такие навороты не нужны. Gitlab использует свой же репозиторий и докер-образы - вышли снова на Дерибасовскую.

Что я делаю не так, почему мне все время хочется один раз запушить vendors в git, и забыть о нем?
 
Последнее редактирование:

WMix

герр M:)ller
Партнер клуба
а снаружи все собрать, и просто ADD /app /app и git не нужен будет..
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
что такое ADD? через dockerfile билдить образ вместе с кодом приложения? предлагаешь в дополнение к git поднимать, мейнтейнить или платить за registry для каждого проекта, и перекомпилировать образ целиком при обновлении любой строчки кода? мне php вообще нужен чтобы этого не делать
 
Последнее редактирование:

WMix

герр M:)ller
Партнер клуба
https://docs.docker.com/engine/reference/builder/#add но можешь и rsync
через dockerfile билдить образ вместе с кодом приложения
а снаружи все собрать
в дополнение к git поднимать,
и git не нужен будет
и перекомпилировать образ целиком при обновлении любой строчки кода
ну да но только последний layer (для dev сделай --mount)
 
Последнее редактирование:

grigori

( ͡° ͜ʖ ͡°)
Команда форума
да, сделаю как volume, он ставится за секунду
вопрос в библиотеках

> git не нужен будет
git нужен в любом случае для управления изменениями в команде

> снаружи все собрать
> для dev сделай --mount
ты можешь описать преимущества такого решения?
то, что я могу билдить образ в gitlab pipelines и заливать в registry - я знаю,
я не пойму зачем мне эти навороты, если собирать образы становится не нужно вообще после одного коммита
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
вопрос в библиотеках
А, ты php-код заранее в контейнеры суешь?
Как по мне, это дело билд-сервера. Тем более, на билд-сервере docker-compose (где вообще даже entrypoint может отличаться), а на продакшене swarm-stack или k8s какой.
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
ты можешь описать преимущества такого решения?
то, что я могу билдить образ в gitlab pipelines и заливать в registry - я знаю,
я не пойму зачем мне эти навороты, если собирать образы становится не нужно вообще после одного коммита
А я чот не понял как ты делаешь.
Вот есть у меня пачка php-кода в гит-репозитории, мне его надо запускать и через php-fpm, и через обычный cli - очереди всякие разбирать, кроны запускать и так далее (тут отличие только в entrypoint). Или у тебя все по микросервисам разнесено и такого не надо? Ну все равно.
Вот закомитили что-то в production (или staging) веточку, дернулся деплой на том же circleci/pipelines/whatever, дальше у тебя как?
 

WMix

герр M:)ller
Партнер клуба
как бы контейнер это аппликация а не виртуальная машина.
есть сервис, он собирает аппликацию (git pull, yarn update, composer install, phpunit, docker build). нечто под названием CI
дальше остается только развернуть созданый image на любой машине. нечто под названием CD
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
А, ты php-код заранее в контейнеры суешь?
Как по мне, это дело билд-сервера. Тем более, на билд-сервере docker-compose (где вообще даже entrypoint может отличаться), а на продакшене swarm-stack или k8s какой.
Нет, я монтирую код в контейнер
Я стараюсь, чтобы на dev был такой же stack/swarm, как на на проде, отличаются только credentials и сетевые настройки, потому что под маком-виндой не разрешена host network.
Если отличается entrypoint - будут ошибки, когда одно обновили, а другое забыли, невосвоспроизводимые баги.

Вот есть у меня пачка php-кода в гит-репозитории, мне его надо запускать и через php-fpm, и через обычный cli - очереди всякие разбирать, кроны запускать и так далее (тут отличие только в entrypoint). Или у тебя все по микросервисам разнесено и такого не надо?
Конечно, когда новое пишу - по микросервисам разбиваю.
Но есть легаси. Код монтирую в несколько контейнеров, кроны и fpm запускаю отдельно.

Вот закомитили что-то в production (или staging) веточку, дернулся деплой на том же circleci/pipelines/whatever, дальше у тебя как?
Я сейчас разгребаю новый проект, где пытались что-то сделать на pipelines со сборкой образа, который должен был забирать gitlab worker, но у них не получилось. Думаю, как именно сделать лучше.

а) проверить в git status --porcelain, забрать релиз через git pull/checkout, рестартануть fpm чтобы сбросить opcache и 7.4 preload
б) забрать архив релиза по http/sftp, и сменить папку для монтирования через docker service update
зачем вообще собирать образ?
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
как бы контейнер это аппликация а не виртуальная машина.
есть сервис, он собирает аппликацию (git pull, yarn update, composer install, phpunit, docker build). нечто под названием CI
дальше остается только развернуть созданый image на любой машине. нечто под названием CD
Дубль два. Зачем эти навороты со сборкой образа, если у нас нет этапа компиляции?
Можно просто забрать архив релиза по http, распаковать в папку - и оно работает!

composer install, npm i выполняют только копирование одних и тех же файлов при каждой сборке, не компиляцию, менять версии можно только в ручном режиме
yarn upgrade (команды update нет) при автобилде гарантированно сломает приложение в течение нескольких месяцев
 
Последнее редактирование:

WMix

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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
@WMix дубль три. Да, ты 3й раз повторяешь, что собираешь образы вместе с кодом, и я понял это с первого раза, но стриминг о твоей жизни - это не то, что поможет в решении инженерных задач :)

Напиши, пожалуйста, что-то о причинах, следствиях, между какими вариантами ты выбирал, какие преимущества, недостатки, и как это относится к vendors?
Я вижу в твоем алгоритме только несколько ненужные действия, неконтролируемые зависимости, невоспроизводимые баги и необязательные затраты - одни недостатки, и отлично бы узнать о преимуществах такого подхода.
 
Последнее редактирование:

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Если следовать принципу "я девочка, я не хочу ничего решать, я хочу платье" - понятно, что вы положите в один репозиторий монолит на php, ваша соседка закоммитит в document root папку с precss-файлами, которые компилируются 3м gulp, который ставится yarn-ом, и работает только с 11й нодой, а клевый чувак из поцдамского офиса сделает субрепозиторий с SPA на ангуляре или vue, который компилируется свежим grunt с webpack на 12й ноде - тогда вам обязательно нужен серьезный многоэтапный процесс сборки вашего мусора в образ. А если вы настоящие взрослые пацаны в большой корпорации типа Oracle - вы собираете не хипстерский образ, а солидный rpm-пакет - ну, не умеют в оракле докер.

Поэтому важное уточнение: у меня front end в отдельном репозитории, и backend-задачи тоже работают отдельно от fpm. Вопрос касается только php и composer. Спасибо!
 

fixxxer

К.О.
Партнер клуба
зачем вообще собирать образ?
Да только чтобы volume_from оттуда делать, больше незачем. :)
Можно и так раскидывать, конечно.

Если отличается entrypoint - будут ошибки, когда одно обновили, а другое забыли, невосвоспроизводимые баги.
не, я имею ввиду что-то типа docker-compose run --entrypoint

для билдилки - why not
 

WMix

герр M:)ller
Партнер клуба
Напиши, пожалуйста, что-то о причинах
советуют так делать


Containers are immutable
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
советуют так делать


Containers are immutable
Это общие рекомендации для всех случаев, для тех, кто знакомится с контейнерами, но специфика php в том, что у нас нет компиляции и сборки приложений, как в большинстве случаев.

Аналогично: "Don’t rely on IP addresses" В случае с IPv6 прямо в документации написано, что в docker.json нужно прописать реальную подсеть /80, единственный вариант не привязывать ip к контейнеру - запускать сервис в host-сети. Реальность, как обычно, сложнее.

У меня ощущение, что люди сами надевают седло на корову, и ведут себя, будто пишут на java. Мне не нужны советы и статьи для новичков, спасибо.
 
Последнее редактирование:

AnrDaemon

Продвинутый новичок
почти год работает стабильно
Что именно?
специфика php в том, что у нас нет компиляции и сборки приложений, как в большинстве случаев.
Есть, просто ты не хочешь этого видеть и пытаешься убедить в этом нас.
Это хорошо, что у тебя есть рабочий образ с собранным как тебе надо PHP, а теперь накати на него свой код и уже этот контейнер устанавливай на продакшене.
 
Сверху