ибо сервер приложений - это ок. А nginx + php + обший вольюм пахнет как 💩

Ещё как пахнет.

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

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

Планируется загрузка клиентами файлов на сервер. Но до этого разработчик ещё не дошёл.

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

S3

S3

да

Планируется загрузка клиентами файлов на сервер. Но до этого разработчик ещё не дошёл.

а эти файлы - какую сущность представляют?

а эти файлы - какую сущность представляют?

Сканы. Картинки.

ну, зачем? кто их процессит?

их же наверняка можно в вебсокет кидать, хотя я хз

или в посте пейлоадом

я просто не в курсе нынешних трендов

а потом класть в S3 😊 или в БД

блобом

ну, зачем? кто их процессит?

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

я бы на пихтоне сделал. Там все понятно

Ну и интеграция там с битрикс24 планируется. Потому проект ему отдали.

А он в питон не умеет.

Идея с разделением статики мне пока нравится. Посмотрю что где лежит.

Спасибо!

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

Выгоните его

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

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

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

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

Пиздец. Но был в своё время внедрен в качестве 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

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

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

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