Спасибо!

Пока это тайна покрытая мраком. Проект новый и пилится на ходу новым разработчиком. У нас вообще все на питоне. А этот оказался битрицистом/пхпшником. Пилит отдельный проект. Типа партнерки.

Выгоните его

И сделайте на джанге

Бггг. Я бы так и сделал. ?

Битрикс это же совсем пиздец

Битрикс это же совсем пиздец

Пиздец. Но был в своё время внедрен в качестве crm.

Выгоните его

пока не поздно )

пока не поздно )

?

If you work with docker-compose, you will notice that in containers created by docker-compose, the MTU of the daemon is not inherited. This happens because the mtu entry in /etc/docker/daemon.json file only affects the default bridge. Therefore you have to specify the MTU explicitly in the docker-compose.yml for the newly created network:

#compost

обожаю docker-compose. оказывается, публикуемые порты по умолчанию биндятся на 0.0.0.0. Задал демону другой дефолтный IP? пофиг

#compost

Всем привет ? Ребят такой вопрос, в докере крутится апликуха на PHP. Для её полноценной работы надо поднять пару воркеров (php файлики запустить короче) Схема примерно такая, есть веб морда, и есть очередь, в веб морде что-то сделали, это попало в очередь и воркеры должны разгребсти. В чем проблема. Без докера если, я бы воркеры запихал в супервизор, чтобы они жили всегда. А как правильно сделать сейчас, я хз. Вот докер-композ version: "3.3" services: nginx: image: nginx restart: always php: build: ./docker/php restart: always mysql: image: mysql volumes: restart: always rabbit: image: rabbitmq restart: always redis: image: redis restart: always

Поднимать супервизор внутри php контейнера странно. А пилить еще один контейнер с теми же зависимостями что и первый тоже не круто.

Как сделать?

Понравился подход что есть тут https://github.com/mcuadros/ofelia

Но это аля крон, а нужен аля супервизор

вообщем толи лыжы не едут, толи я что-то туплю.

Но это аля крон, а нужен аля супервизор

Так воркеры поднимают отдельными контейнерами и работают они через мессендж-брокер.

Поднимать супервизор внутри php контейнера странно. А пилить еще один контейнер с теми же зависимостями что и первый тоже не круто.

А чем конкретно "не круто"? Слои кешируются же, можно попробовать сделать образ с supervisord и php, почему нет?

Так воркеры поднимают отдельными контейнерами и работают они через мессендж-брокер.

Через брокер они и воркуют (кролик да) Просто пытаюсь понять как лучше поднять такую связку. С одной стороны воркер просто кусочек одной апликухи, с другой он требует себе зависимость в виде супервизора для нормальной работы.

А супервизор в докер пихать вроде как моветон

Вот и бьюсь как баран об новые ворота)

А супервизор в докер пихать вроде как моветон

Ну тогда без супервизора запускай контейнер с консюмером очереди

Да, в соседнем чате дали хороший пример с мульти стейджом. Думаю так и сделаю

php: build: context: ./ image: ./docker/php target: target1 restart: always worker: build: context: ./ image:./docker/php target: target2 restart: always command: php worker.php

Через брокер они и воркуют (кролик да) Просто пытаюсь понять как лучше поднять такую связку. С одной стороны воркер просто кусочек одной апликухи, с другой он требует себе зависимость в виде супервизора для нормальной работы.

ну, когда вариантов нет совсем - можно и супервизор в докер

php: build: context: ./ image: ./docker/php target: target1 restart: always worker: build: context: ./ image:./docker/php target: target2 restart: always command: php worker.php

а вот это ты каку пишешь

во-первых, у тебя нет названия имиджа

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

И это не мультистейдж)

во-вторых, лучше собирать образы снаружи, docker build, а лучше buildah и прочие альтернативы

потому что это можно лучше контролировать

в четвертых, у тебя формат 3.3, хотя у тебя не сварм. Поставь 2.4

в пятых, у тебя нет порядка запуска сервисов

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

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

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

Так есть depends_on.

Хм, т.е. depends_on: mysql Не хватит?

во-вторых, лучше собирать образы снаружи, docker build, а лучше buildah и прочие альтернативы

Т.е. я где-то собрал образ, а потом в композе просто пишу image: блаблабла верно?

Хм, т.е. depends_on: mysql Не хватит?

На первое время может хватить.

ч

Хм, т.е. depends_on: mysql Не хватит?

Нет, это depends_on : service_started

А не healthy

Разница понятна, надеюсь

Т.е. я где-то собрал образ, а потом в композе просто пишу image: блаблабла верно?

Да

Понял

Спасибо, буду копать

Народ, кто настраивал докер прокси в нексусе? level=info msg="Attempting next endpoint for pull after error: Get http://docker.autobp.foo.ru/v2/library/mysql/manifests/latest: no basic auth credentials"

При этом курлом этот url доступен. Не понимаю что ему не нравится

После перезагрузки постоянно отваливается контейнер, докер в процессах его отображает но по порту он недоступен. В чем может быть проблема ?

В логах что?

хай, народ! подскажите, а при каких условиях docker может не юзать кеш слоёв при билде? т.е. даже лейблы не берутся из кеша. dockerfile типа того FROM centos:7 LABEL maintainer="e@mail.com" ...... ......

ну, ты удалил временные образы, например

или базовый изменился

говорят, что помогает стянуть старый целевой образ, а потом в docker build указать —cache-from и айди образа

говорят, что помогает стянуть старый целевой образ, а потом в docker build указать —cache-from и айди образа

не, не помогает

так, временные образы я специально не чистил. алгоритм следующий: 1. билд 2. пуш режистри 3. rmi сбилженый образ

так, временные образы я специально не чистил. алгоритм следующий: 1. билд 2. пуш режистри 3. rmi сбилженый образ

кэш сборки - пока пока

так, временные образы я специально не чистил. алгоритм следующий: 1. билд 2. пуш режистри 3. rmi сбилженый образ

уже на 3-м этапе у тебя все кэши кирдык

так, окей, только что попробовал не удалять, все равно не кешируется

говорят, что помогает стянуть старый целевой образ, а потом в docker build указать —cache-from и айди образа

https://github.com/moby/moby/issues/22600

так, окей, только что попробовал не удалять, все равно не кешируется

а вот этого быть не может. У меня кэширует.

но повторюсь, что если ты перетянул базовый образ, то привет

так, окей, только что попробовал не удалять, все равно не кешируется

скинь команду, которой ты собираешь. может там --no-cache затесался)

а вот этого быть не может. У меня кэширует.

у меня вообще странно просто. есть gitlab-ci, часть образов собирается с кешем, часть не кешируется. пытаюсь понять что к чему

скинь команду, которой ты собираешь. может там --no-cache затесался)

не не, точно нет но-кеш)

сколько агентов сборочных?

ну, докер вообще гавнюк

один

в докере? или шелл?

не похоже, что дело в докере. @ru_gitlab

агент в шелле

не похоже, что дело в докере. @ru_gitlab

думал об этом, решил с самого низа начать разбираться. мало ли

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

но непонятно только почему при выполнении докер хистори все слои миссинг

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

такое обычно, когда сборка падает

в идеальном мире - не будет образов без тега и имени

как вариант - если ты не чистишь образы, то со старого образа снимается тег, но имя-то остается (!)

это если один и тот же имя:тег

да

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

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

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

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

?

Докер такой докер