Парни, а кто как добавляет композеровские пакеты в образ докера? Есть несколько вариантов 1. Добавлять композер в образ, а устанавливать зависимости при деплое \ + Маленький размер образа \ - Версия композера может протухнуть на момент деплоя, версии же пакетов фиксированы \ - Необходимо после разворачивания контейнера предпринимать какие-то доп. действия 2. Добавлять пакеты непосредственно в образ \ + Разворачиваешь контейнер, и он уже полностью готов к работе \ + Не нужно таскать композер (который может обновиться) \ - Размер образа раздувается значительно (+ ~100Mb на каждую версию образа в реджистри)

я в образ зашиваю

Билд стейдж

Билд стейдж

А как именно влияет билд стейдж?

А как именно влияет билд стейдж?

Он и сделает твой composer install

так это билд, а я говорю про итоговый образ

Короче, чёрт знает сколько раз разбирали. Мы вендор в образ ложим

ну вот, 2 человека именно так и делают) это я и хотел узнать. Спасибо

Парни, а кто как добавляет композеровские пакеты в образ докера? Есть несколько вариантов 1. Добавлять композер в образ, а устанавливать зависимости при деплое \ + Маленький размер образа \ - Версия композера может протухнуть на момент деплоя, версии же пакетов фиксированы \ - Необходимо после разворачивания контейнера предпринимать какие-то доп. действия 2. Добавлять пакеты непосредственно в образ \ + Разворачиваешь контейнер, и он уже полностью готов к работе \ + Не нужно таскать композер (который может обновиться) \ - Размер образа раздувается значительно (+ ~100Mb на каждую версию образа в реджистри)

У нас отдельный билд контейнер с композером и всем остальным, необходимым для сборки. Используем его для дева. А для стейджа и прода на СиАй делаем билд, архивируем его и его разворачиваем на стейдже и проде.

Обычно делал json_decode и тестировал как обычно.

https://github.com/fesor/json_matcher - можешь в ридми у меня почитать какие проблемы с просто json_encode

Парни, а кто как добавляет композеровские пакеты в образ докера? Есть несколько вариантов 1. Добавлять композер в образ, а устанавливать зависимости при деплое \ + Маленький размер образа \ - Версия композера может протухнуть на момент деплоя, версии же пакетов фиксированы \ - Необходимо после разворачивания контейнера предпринимать какие-то доп. действия 2. Добавлять пакеты непосредственно в образ \ + Разворачиваешь контейнер, и он уже полностью готов к работе \ + Не нужно таскать композер (который может обновиться) \ - Размер образа раздувается значительно (+ ~100Mb на каждую версию образа в реджистри)

https://github.com/fesor/project-skeleton/blob/master/docker/php/Dockerfile#L31-L34

примерно так

Парни, а кто как добавляет композеровские пакеты в образ докера? Есть несколько вариантов 1. Добавлять композер в образ, а устанавливать зависимости при деплое \ + Маленький размер образа \ - Версия композера может протухнуть на момент деплоя, версии же пакетов фиксированы \ - Необходимо после разворачивания контейнера предпринимать какие-то доп. действия 2. Добавлять пакеты непосредственно в образ \ + Разворачиваешь контейнер, и он уже полностью готов к работе \ + Не нужно таскать композер (который может обновиться) \ - Размер образа раздувается значительно (+ ~100Mb на каждую версию образа в реджистри)

Как по мне, Dockerfile должен мочь собрать любой проект лишь на основе исходников, поэтому везде в докерфайле делаю composer install

Как по мне, Dockerfile должен мочь собрать любой проект лишь на основе исходников, поэтому везде в докерфайле делаю composer install

для сложных случаев всегда можно воспользоваться мультистэйдж билдами, если хочется например в продакшен образе только продакшен зависимости

p.s. я по итогу прихожу к тому что для node например всеравно отказываюсь от сборки внутри Dockerfile и собираю своим башем. Что-то типа... docker build npm build // подготовка продакшен билда docker create docker cp docker commit

для php необходимости в этом особо нету, а вот для ноды сборка чисто докерфайлом в моем случае дико ограничивает (с учетом того насколько херово продумана система кэширования для мульстэйдж билдов в условиях CI)

@fes0r спасибо, а почему не использовать простой assertArraySubset от phpUnit для проверки? Выходит вроде тоже самое вдеь. $this->assertArraySubset( [ [ 'name' => 'John', ], ], $aliceFiendsArray, );

Как по мне, Dockerfile должен мочь собрать любой проект лишь на основе исходников, поэтому везде в докерфайле делаю composer install

чо эта?

Dockerfile != Makefile

чо эта?

Чтобы не ломать голову над тем, что я должен сделать перед тем, как буду запускать сборку образа

Dockerfile это как запаковка бинарника в архив

make build docker к примеру, чтобы не ломать голову

https://github.com/fesor/project-skeleton/blob/master/docker/php/Dockerfile#L31-L34

Т.е. у тебя во время билда полностью качается кеш с нуля, а потом чистится?

Вообще, если так подумать, к примеру релиз каждые 2 недели. Докер-образ по ~200Мб улетает на реджистри - то это очень весомо, не критично но весомо

А у нас дык вообще релиз тогда, когда готов, и даже роадмапов пока особо нет, бывает такое, что одно поле в сущность добавить да в интерфейс, лепить по этому поводу целый еще один образ - жесть. Но это так, мысли вслух, не больше

Хм. У нас релиз каждый день, иногда два раза в день. Не парит таскать по 300 метров собранного докер образа - код, зависимости и ещё картинки, документы и прочая хрень, которая в репе живёт. По факту готовый к релизу образ собираться на каждый коммит. Вендоры из кэша приходят за пару секунд.

Хм. У нас релиз каждый день, иногда два раза в день. Не парит таскать по 300 метров собранного докер образа - код, зависимости и ещё картинки, документы и прочая хрень, которая в репе живёт. По факту готовый к релизу образ собираться на каждый коммит. Вендоры из кэша приходят за пару секунд.

вендоры тоже инжектятся в образ?

и сколько релизов хранится в реджистри? все когда-либо собраные?

там же слоями хранится в регистри все

а блин, сорян, тупанул)) забыл про слоистость aufs

вендоры тоже инжектятся в образ?

Все инжектиться, образ готовый запуститься в любом месте. В регистри периодически подчищаем. Больше 2х недель не храниться. Слой один получается.

у нас на новые релизы всего пару мб выкачивает образов

Можно по слоям, но сложно..

все остальное с прошлых слоев берет

Можно по слоям, но сложно..

разве? это ж дефолтное поведение реджистри, наоборот приходится перед каждым билдом сбрасывать кэш докера, чтобы одним слоем собирался (или сколько их там у вас в dockerfile)

@fes0r спасибо, а почему не использовать простой assertArraySubset от phpUnit для проверки? Выходит вроде тоже самое вдеь. $this->assertArraySubset( [ [ 'name' => 'John', ], ], $aliceFiendsArray, );

почитай ридми. Там три пункта всего. Если совсем лень - таймстэмпы, айдишки, вложенности, реюз матчеров. Да можно своих ассертов нафигачить - это не сложно. Но как-то хз. Опять же - я свою задумку до конца так и не реализовал)

У на фактически один слой - код. Берём контейнер с пыхом, кладём в него код со всеми зависимостями.

У на фактически один слой - код. Берём контейнер с пыхом, кладём в него код со всеми зависимостями.

ну эт вы зря)

Вообще, если так подумать, к примеру релиз каждые 2 недели. Докер-образ по ~200Мб улетает на реджистри - то это очень весомо, не критично но весомо

1. Релиз != деплой. У меня деплой на прод каждый день - обычная практика. В день билдится где-то 20-30 образов 2. За эти 2 недели как часто у тебя меняется composer.json/composer.lock? у меня - где-то 1-2 раза за спринт, не чаще. А потому размер образов в среднем пару мегабайт то что пушится сверху. А те 200 метров - пару раз за спринт. не чаще.

COPY web/app.php web/app.php COPY composer.json composer.json COPY composer.lock composer.lock COPY bin bin/ COPY vendor vendor/ COPY config config/ COPY templates templates/ COPY src src/ у нас примерно в таком порядке идет

ну эт вы зря)

Да можно оптимизировать, но пока это не проблема, в других местах проблем больше, а ресурсы ограничены...

COPY web/app.php web/app.php COPY composer.json composer.json COPY composer.lock composer.lock COPY bin bin/ COPY vendor vendor/ COPY config config/ COPY templates templates/ COPY src src/ у нас примерно в таком порядке идет

Спасибо!)

COPY web/app.php web/app.php COPY composer.json composer.json COPY composer.lock composer.lock COPY bin bin/ COPY vendor vendor/ COPY config config/ COPY templates templates/ COPY src src/ у нас примерно в таком порядке идет

если мой вариант мне начнет мешать я скорее перейду на docker create && docker cp && docker commit чем на это...

заморачиваться с порядком еще

хотя... не вендоры всеравно буду копировать что бы кэш реюзался

с тобой спорить опять не буду)

у тебя странные понятия о контейнерах)

?

может быть у тебя странные поняттия о контейнерах? ;)

у нас были проблемы с образами и мы умудрялись ложить диски на амазоне при деплоях

p.s. твое "странное" оттношение обусловлено тем что у тебя мак)

у нас были проблемы с образами и мы умудрялись ложить диски на амазоне при деплоях

можешь поподробнее?

когда за деплой тебе нужно поднять пару сотен подов(контейнеров)

а, ну... тогда понятно

то каждый раз тащить туда новый слой вендоров, который не менялся

это больно

у меня вендоры всегда будут отдельным слоем. Так что да, я скорее всего буду ближе к твоему варианту юзать

и это единственное что мне мешает комфортно себя с мультистэйдж билдами чувствовать. Как по мне мультистэйдж отлично когда у тебя проект компилится.

хотя... можно и с мультистэйдж слой отдельный держать...

просто я не представляю пока как

ни на гошных, ни на котлин проектах нигде мультистейдж не юзается

бинари отдельно собираются

бинари отдельно собираются

а потом просто зашиваются в образ?

FROM openjdk:8-jre-slim VOLUME /tmp COPY ./build/libs/app.jar app.jar ENV JAVA_OPTS="" ENV ARGS="" CMD java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $ARGS тип такого

с пхп +- так же

У нас фронты мультистейдж сейчас собираются делать. Сейчас мультистейдж через баш)

только делается еще RUN php bin/console cache:warmup

FROM openjdk:8-jre-slim VOLUME /tmp COPY ./build/libs/app.jar app.jar ENV JAVA_OPTS="" ENV ARGS="" CMD java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $ARGS тип такого

так а как ты хэндлишь штуки типа composer install? оно ж автолоад всегда будет перегенеривать, или ты с --no-autoload делаешь вендоры а уже потом автолоад генеришь?

или пофиксили уже в композере? А то я уже давно не смотрел

У нас фронты мультистейдж сейчас собираются делать. Сейчас мультистейдж через баш)

хз, я хочу у фронта вообще докер убрать. Нинужон он им

ну разве что у тебя там SSR есть и ноду под это дело надо держать

или пофиксили уже в композере? А то я уже давно не смотрел

хз, все ок работает

у меня в контейнере симфони можно сказать в рид онли лежит, туда юзер ниче даже записать не сможет

хз, я хочу у фронта вообще докер убрать. Нинужон он им

для сборки ж

хз, все ок работает

гляну. я просто для фронта перевожу сборку на пайплайны + вшивать уже билд в образ. Так если с composer-ом не будет пробем в плане копирование вендоров если ничего не ставилось нового будет приводить к одинаковому слою и будет юзаться кэш - то можно будет юзануть и тогда у нас с тобой будет одинаково

для сборки ж

я запутался. Но ты ж для сборочки докер не юзаешь, нет?

локально не

а на CI?

там через образы с фикс версиями

или у тебя воркеры на докерах и ты докер образ внутри докера собираешь?

мм, не. просто node/npm идут образами

там через образы с фикс версиями

еще раз - composer install или npm ci ты где делаешь? на хосте или в контейнере (пусть и при сборке)

вместо локальных бинарей

а, понял

тогда все ок

тогда я понимаю что происходит

ну вот я так же буду делать)))

я проиграл короч

есть куча волокиты, которая делается образами композеров, npm и прочей херни, собирают конечный набор файликов

а потом это все раскладывается по образам

чето в фронт образ, чето в пхп

помимо этого еще всякие линты и тесты гоняются, это тоже контейнеры

ну вот у меня сча есть общий код который как общий модуль между несколькими проектами и за счет этого мы сильно сборку переделываем. Так проще и мороки меньше чем с приватными регистри

короче все для того чтобы на CI кроме докера ниче не надо было держать и сборка повторялась локально

да, понимаю. Аналогично делаю.

А ты на дженкинсе или на чем-нибудь модном?

дженкинс не модный?)

ну можно тимсити взять, с kotlin dsl