а зачем тут на 9 шагу прописано volumes: - .:/code, если в dockerfile есть ADD . /code/ ? https://docs.docker.com/compose/django/

https://docs.docker.com/compose/django/

тоже самое на странице про rails https://docs.docker.com/compose/rails/

а зачем тут на 9 шагу прописано volumes: - .:/code, если в dockerfile есть ADD . /code/ ? https://docs.docker.com/compose/django/

потому что монтирование вольюмов происходит при старте контейнера а не при билде

т.е. если изменется код в ./code он и в контейнере изменится?

соответственно разработчики докера тоже согласны со мной?

да, для этого и расшаривается том между хост машиной и контейнером

ну по крайней мере я не знаю другого применения :)

это уже процесс разработки - и тут схема маунтить папки с хоста вполне себе роляет

ну не только разработчики докера :)

This quick-start guide demonstrates how to use Docker Compose to set up and run a simple Django/PostgreSQL app. >quick >simple

хотя simple относится к самому django app

simple Django/PostgreSQL app

речь о том что это простой пример для быстрого старта.

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

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

при разработке. при деплое удобнее билдить код внутрь.

Согласен. Сам поместил nginx, php-fpm и код в один контейнердля удобства деплоя.

а nginx зачем к php-fpm класть,

Согласен. Сам поместил nginx, php-fpm и код в один контейнердля удобства деплоя.

я так не говорил)

а nginx зачем к php-fpm класть,

чтобы статику отдавать

чтобы статику отдавать

имеется в виду зачем нарушать правило 1 сервис - 1 контейнер

Остался вопрос - как отлаживать вопросы сборки в контейнер, если они уходят только в прод?

имеется в виду зачем нарушать правило 1 сервис - 1 контейнер

Какие логические обоснования у этой парадигмы?

логически 1 сервис - веб-сайт

нет

без nginx статику не отдаст, без php динамики не будет

без БД не будет работать тоже

БД почему внутрь не впихнули?

Какие логические обоснования у этой парадигмы?

In almost all cases, you should only run a single process in a single container. Decoupling applications into multiple containers makes it much easier to scale horizontally and reuse containers. If that service depends on another service, make use of container linking.

без БД сайт будет работать, если он пользуется API

2. БД в контейнере тормозит.

логически 1 сервис - веб-сайт

докер - о сервисах-тулзах, а не сервисах-сайтах

2. БД в контейнере тормозит.

лолшто

еще без ntp проблемы с временем могут быть, я бы тоже упаковал...

Виталий 1 сервис - 1 контейнер также используется для рестарта контейнера, когда процесс внутри упадет

еще без ntp проблемы с временем могут быть, я бы тоже упаковал...

и ssh внутрь обязательно

неудобно же админить

(и код заливать внутрь контейнера через ftp)

тотал командером конечно

и гнома не забыть

webmin

без гуи неудобно, верно

ftp должен умереть. Даже к тоталу есть плагин для SSH с авторизацией через pageant

ftp должен умереть. Даже к тоталу есть плагин для SSH с авторизацией через pageant

слава богу. а для фара есть?

In almost all cases, you should only run a single process in a single container. Decoupling applications into multiple containers makes it much easier to scale horizontally and reuse containers. If that service depends on another service, make use of container linking.

Как nginx и php-fpm в 1 контейнере мешает горизонтально масштабировать приложение?

Как nginx и php-fpm в 1 контейнере мешает горизонтально масштабировать приложение?

легко мешает)

логически 1 сервис - веб-сайт

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

В душе не чаю, что там у фара. Пользую, в зависимости от машины, mc, Double Commander и тотал. Как ни прискорбно, у double самый убогий плагин для ssh - крэшит часто

Холиварный аргумент, не счтаете?

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

Холиварный аргумент, не счтаете?

как заскейлить мне пхп?

вот у меня есть нджинкс и пхп в одном контейнере, а мне надо 4 пхп.

как заскейлить мне пхп?

docker service update --replicas=200

docker service update --replicas=200

так я получу 200 нджинксов, а зачем мне это?

вот у меня есть нджинкс и пхп в одном контейнере, а мне надо 4 пхп.

4 контейнера

4 контейнера

4 нджинкса 4 пхп

4 нджинкса 4 пхп

в одном? но зачем?

в одном? но зачем?

об этом речь и идет (читай выше)

так я вот и поддерживаю собственно официальную позицию. 1 докер = 1 сервис

Виталий спросил чем обуславливается правило 1 сервис - 1 контейнер.

Да, 4 nginx и 4 php. В чём проблема?

а для управления всем этим есть сварм

так я же написал - мне хватает 1 нджинкска, но нужно 4 пхп

Задача отмасштабировать сервис решена )

не оптимально

посмотрим на эту проблему со стороны процесса деплоя

сервер получает на входе 1 контейнер, в который проксируются запросы

ERROR: S client not available

вариант с разделением - нужно следить за папками (для nginx) и за папками fpm

не нужно

не понимаю. 1 который проксирует - понимаю. но...

дальше каждому по контейнеру по идее

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

не нужно

Как не нужно? Программист поменял папку root, что делается с сервисом? Как НЕ вносить изменения при этом в конфигурацию?

Женя прав

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

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

и он прав.

Как не нужно? Программист поменял папку root, что делается с сервисом? Как НЕ вносить изменения при этом в конфигурацию?

какую еще папку root?

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

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

Покажите, где ваша схема производительнее

А в его случае это как раз - один контейнер с нгинксом внутри

Виталий, вы до сих пор не рассказали, почему БД в контейнере тормозит.

Покажите, где ваша схема производительнее

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

Виталий, вы до сих пор не рассказали, почему БД в контейнере тормозит.

фс наверное

и почему же она тормозит?

не вынесеный наружу сторадж?

ссзб.

iotop что пишет?

https://github.com/docker-library/mariadb/blob/5faca097859879a9629312ee1d31fb22a06c6bf3/10.1/Dockerfile#L83

как бы в официальных образах вынесено.

Виталий, вы до сих пор не рассказали, почему БД в контейнере тормозит.

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

iotop что пишет?

я б для начала vmstat посмотрел

а, ну да, iotop это уже глубоко. vmstat конечно

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

дисковое io мимо layered fs не тормозит. точнее, тормозит не более, чем mount --bind

а вот сеть... Коллеги, никто не сталкивался с недостаточной производительностью linux bridge + veth?

многие советуют --net=host

это да :)

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

Моветон, по-моему, тоже не аргумент в сторону производительности.

многие советуют --net=host

судя по исследованию percona при таком варианте оверхеда нет

это факт. но это не всегда решение.