Max
тоже самое на странице про rails https://docs.docker.com/compose/rails/
Roman
а зачем тут на 9 шагу прописано volumes: - .:/code, если в dockerfile есть ADD . /code/ ?
https://docs.docker.com/compose/django/
потому что монтирование вольюмов происходит при старте контейнера а не при билде
Max
т.е. если изменется код в ./code он и в контейнере изменится?
Max
соответственно разработчики докера тоже согласны со мной?
Roman
да, для этого и расшаривается том между хост машиной и контейнером
Roman
ну по крайней мере я не знаю другого применения :)
Roman
это уже процесс разработки - и тут схема маунтить папки с хоста вполне себе роляет
ну не только разработчики докера :)
Evgeny
This quick-start guide demonstrates how to use Docker Compose to set up and run a simple Django/PostgreSQL app.
>quick
>simple
Evgeny
хотя simple относится к самому django app
Evgeny
simple Django/PostgreSQL app
Evgeny
речь о том что это простой пример для быстрого старта.
Виталий
Монтировать папку и вносить в неё изменения быстрее, чем пересобирать контейнеры и стартовать их
Aleksandr
Монтировать папку и вносить в неё изменения быстрее, чем пересобирать контейнеры и стартовать их
при разработке. при деплое удобнее билдить код внутрь.
Виталий
Согласен. Сам поместил nginx, php-fpm и код в один контейнердля удобства деплоя.
Anton
а nginx зачем к php-fpm класть,
Aleksandr
Виталий
Остался вопрос - как отлаживать вопросы сборки в контейнер, если они уходят только в прод?
Виталий
имеется в виду зачем нарушать правило 1 сервис - 1 контейнер
Какие логические обоснования у этой парадигмы?
Виталий
логически 1 сервис - веб-сайт
Anton
нет
Виталий
без nginx статику не отдаст, без php динамики не будет
Anton
без БД не будет работать тоже
Anton
БД почему внутрь не впихнули?
Aleksandr
Какие логические обоснования у этой парадигмы?
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. БД в контейнере тормозит.
Anton
еще без ntp проблемы с временем могут быть, я бы тоже упаковал...
Max
Виталий 1 сервис - 1 контейнер также используется для рестарта контейнера, когда процесс внутри упадет
Aleksandr
еще без ntp проблемы с временем могут быть, я бы тоже упаковал...
и ssh внутрь обязательно
Aleksandr
неудобно же админить
Aleksandr
(и код заливать внутрь контейнера через ftp)
Aleksandr
тотал командером конечно
Roman
и гнома не забыть
Sergei
webmin
Aleksandr
без гуи неудобно, верно
R
ftp должен умереть. Даже к тоталу есть плагин для SSH с авторизацией через pageant
Aleksandr
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 контейнере мешает горизонтально масштабировать приложение?
Aleksandr
Dan
логически 1 сервис - веб-сайт
а если у меня сервис не веб-сайт? а, например, самодельный интерфейс по собственно придуманному протоколу обмена данными между какими-нибудь устройствами и базой данных? )
R
В душе не чаю, что там у фара. Пользую, в зависимости от машины, mc, Double Commander и тотал. Как ни прискорбно, у double самый убогий плагин для ssh - крэшит часто
Виталий
Холиварный аргумент, не счтаете?
Dan
и докер у меня например просто крутит этот сервис и базу данных
Aleksandr
вот у меня есть нджинкс и пхп в одном контейнере, а мне надо 4 пхп.
Dan
так я вот и поддерживаю собственно официальную позицию. 1 докер = 1 сервис
Aleksandr
Виталий спросил чем обуславливается правило 1 сервис - 1 контейнер.
Виталий
Да, 4 nginx и 4 php. В чём проблема?
Dan
а для управления всем этим есть сварм
Aleksandr
так я же написал - мне хватает 1 нджинкска, но нужно 4 пхп
Виталий
Задача отмасштабировать сервис решена )
Aleksandr
не оптимально
Виталий
посмотрим на эту проблему со стороны процесса деплоя
Виталий
сервер получает на входе 1 контейнер, в который проксируются запросы
Виталий
вариант с разделением - нужно следить за папками (для nginx) и за папками fpm
Aleksandr
не нужно
Dan
не понимаю. 1 который проксирует - понимаю. но...
Dan
дальше каждому по контейнеру по идее
Evgeny
ребят, чо вы накинулись? у Виталия просто сайт который упакован в докер, для него норм. Вопросы масштабирования, нагрузки, автоскейла, деплоя и иже с ним его не парят и я его понимаю. нафига для 6 калек в день напрягаться?
Виталий
не нужно
Как не нужно? Программист поменял папку root, что делается с сервисом? Как НЕ вносить изменения при этом в конфигурацию?
Dan
Женя прав
Aleksandr
ребят, чо вы накинулись? у Виталия просто сайт который упакован в докер, для него норм. Вопросы масштабирования, нагрузки, автоскейла, деплоя и иже с ним его не парят и я его понимаю. нафига для 6 калек в день напрягаться?
вопрос был "чем обуславливается парадигма". обосновали. Виталий же пытается обосновать праивльность своего подхода "шестью калеками".
Evgeny
и он прав.
Aleksandr
Evgeny
потому что давайте пойдем немного дальше. чем обусловлена эта парадигма? экономия времени и сил
Виталий
Evgeny
А в его случае это как раз - один контейнер с нгинксом внутри
Sergei
Виталий, вы до сих пор не рассказали, почему БД в контейнере тормозит.
Evgeny
Покажите, где ваша схема производительнее
у меня другая схема, у меня много микросервисов и держать по 200 нгинксов на хосте просто чтобы они были - моветон