Pull to refresh

Comments 16

Не совсем понял вопроса. После того как запускаю PostgreSQL и Redis через docker-compose они стартуют вместе с docker-machine. А разработка вся ведется в PyCharm с использованием удалённого интерпретатора, то есть работаю так же как и с локальным. Контейнер сам подхватывает изменения и рестартует при необходимости. Для production я так же использую докер, но уже нативный на linux, и всё запускаю через docker-compose.
Я про реальный опыт. Насколько долго оно работает, насколько устойчиво, какие проблемы возникают?
База тоже в докере?
Да, база так же в докере, используется data контейнер, так что данные не пропадают после того, как контейнер перезапускается.
Проблемы в принципе могут быть разные, в зависимости от конфигурации да и то, от того что невнимательно читал документацию чаще всего. Пока для меня данная конфигурация даёт больше удобств, чем каких-то проблем.
Само собой, не в UnionFS же с докером класть данные.
Но кто юзал докер под нагрузкой, говорили, что ему часто «отрывает» примонтированный раздел — просто база внутри контейнера переставала его видеть и в итоге базе сильно плохело. Поэтому сейчас важны реальные отзывы пользователей. Отсюда и вопрос под насколько большой нагрузкой и как долго эксплуатировали?
тут вы вряд ли ответ получите, так как статья про разработку под докером, а не продакшн.

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

но опять же это все development — тут нет высокой нагрузки
Ну да, всё правильно. Я поэтому вопроса и не понял. Всё-таки статья про dev
Не подскажите, а сейчас как актуальнее всего разворачивать Django в продакшен? У меня просто был перерыв в года 1.5 в разработке на нём, раньше пользовался Gunicorn. Сейчас все больше вижу статей про docker, vergant и прочее. Как сейчас обычно делают? Поверить в контейнеры и пользоваться уже спокойно ими или лучше делать все как раньше через инструменты на подобии gunicorn ( в свое время прост опришёл с RoR, поэтому сразу стал использовать аналог, но как правильно сейчас в экосистеме Django не особо могу понять ).
Да как удобнее в принципе. Docker сейчас это стильно, модно, молодежно) Он даёт некоторые преимущества, например можно легко поднять тестовое окружение идентичное продакшену. Но я к сожалению не так долго использую докер, и тем более под большими нагрузками, чтобы давать советы по поводу нужно ли вам его использовать на продакшене. Может кто использует такую связку в продакшене, нам напишет.
Да понятно, что это тренд, просто думаю дошло все это до этапа, когда можно развернуть заказчику контейнер и сказать так правильно, или на собеседовании ответить, что уже все через Docker гоняю, а gunicorn'ы прошлый век…
Так а в докере то все равно gunicorn, просто используете вы в основном уже настроенный образ.
> Docker сейчас это стильно, модно, молодежно)
А для эксплуатации ждать Docker 2.0 и потом на него переходить.
> тестовое окружение идентичное продакшену.
Не очень понял за счет чего, если оно создается разными инструментами. Значит между ними всегда будет расхождение.
Почему разными? Тестовое можно при желании поднять так же как и продакшен только на других железках
Потому что бой у вас поднимается с помощью рук/puppet/chef/ansible/salt/…, а тест докером. Обязательно какие-то расхождения да будут.
Сравнивать Docker и gunicorn — это как тёплое с мягким. Они не заменяют друг друга. Использование Docker или Vagrant не избавляет вас от необходимости запустить Django-проект в каком либо production ready веб-сервере (gunicorn, uwsgi и др.)
верно, просто можно запускать gunicorn`ом либо сразу в системе, либо в докер контейнере.
Пример из docker-compose:
command: /usr/local/bin/gunicorn project.wsgi:application -w 2 -b :8000 --reload
Sign up to leave a comment.

Articles