а как теперь порты кофигрурировать?

а чо, теперь depends_on более кошерно?

дока пиздец

порты вроде также

просто суёшь связанные контейнеры в одну сеть

и вроде как всё

Если сделать рестарт контейнеру просиходит такая херня nginx_1 | nginx: [emerg] bind() to unix:/var/run/nginx_self.sock failed (98: Address already in use) поему он сокет не освобождает?

а компоуз штуки из env в build засунет?

Не,стоп - а у тебя /var/run не чистится?

/var/run внутри контейнера, вот у меня и вопрос остается, run же не диск

а блин..

зачем вообще /var/run , та же просто /run должно быть

там тоже самое будет

это еще почему tmpfs 26G 2.6G 23G 11% /run

Это внутри?

да

ну var run на диске (а run в tmpfs), все равно не понятно почему он его не освобождает при restart, рестарт делал docker-compose restart nginx

Хм, у меня /run внутри персистентный

А почему он его должен освобождать? Рестар не равно удалению и созданию заново

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

в общем я просто listen выпилил покачто , он там мне не нужен , на локал хост похожу если че

м

блин, чота без entrypoint многие вещи получаются очень медленно :(

шта?

ну вот есть 4 имаджа, более-менее одинаковых, но отличается значение одной ENV (путь к продукту)

и уже нельзя сделать так чтоб результат RUN закешировался :(

делай внтури пути одинаковыми

а ему на путь снаружи срать?

хм.

ну да. внутрь копируй в одну и ту же папку

Вот сейчас прямо совсем не туда было, извините

ну вот смотри, у меня получается такая история: ENV PRODUCT_NAME foo COPY $PRODUCT_NAME/Gemfile $PRODUCT_PATH/Gemfile

и вот меняется исключительно PRODUCT_NAME

дальше всё одинаково

из-за ENV слой же другой получается, нет?

а продакт пас?

щас я его сделал фиксированным

/var/www/awesome

или ENV на дерево никак не влияет?

влияет же, кеш сбрасывается при зменении env

Да, влияет

ну тогда пичалька :(

ща вспомню, я как-то обходил

блин, почему нельзя на время сборки с хоста папочку примонтировать

можно было бы кеш гемов на хост вытащить на время сборки

и оно бы мгновенно ставилось

Тебе ж предложили какое-то решение, не?

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

то было для тимсити

а это я щас для девелопмента делаю

Ну сделай для дева базовый образ с постиавленными зависимостями

и от него фромся

типа: services: gems: build: …. foo: depends_on: - gems и в докерфайле foo сделать FROM gems?

ну или делай в локальной папке симлинк ./source -> $PRODUCT а в докерфайле копируй из сорца

это получается надо будет как-то compose препроцессить

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

тогда попробуй с вариантом как ты написал. я не силен в композе - мне все рвемя не хватало что он умеет

а, ну вобщем-то это всё нафиг сломается если у двух продуктов будут разные зависимости

это получается надо будет как-то compose препроцессить

Он на Питоне же, возьми либу и процесс хоть задом на перед

нет, спасибо :)

:)

Ну жди пока на но перепишут :))

I’m not in “diving into python” mood :)

Го*

а, ну вобщем-то это всё нафиг сломается если у двух продуктов будут разные зависимости

а он не доставит нехватающих просто?

хм.

да, там-же не ro

ммм.

Пока нет

Но руки дойдут и фигакнут

и тогда всё сломается!

вот когда сломается, тогда и починим

щас попробуем. в теории можно просто забить болт и сделать один из продуктов базовым

блин, почему нельзя на время сборки с хоста папочку примонтировать

можно rocker

если сработает будет жорошо

сработало :)

Кто в курсе, кстати, как долго ещё docker-compose version 1 будет поддерживаться?

оно сейчас объявлено legacy уже, но вроде поддерживается

у меня тут дико удобные имиджи, которые не линуются через сети

а чинить их руками мне лень