Каковы плюсы и минусы запуска (i) gunicorn system-wide и (ii) установки gunicorn на virtualenv (предполагая 5-6 virtualenv на 512MB VM)

Я запускаю 5-6 веб-сайтов поверх django. Каждый проект django находится в своем собственном virtualenv и обслуживает один веб-сайт.

В настоящее время я устанавливаю gunicorn на virtualenv, и поэтому каждый проект django имеет свою собственную установку gunicorn и процессы.

Каковы плюсы и минусы этого подхода, и альтернатива установки gunicorn system wide, с одной установкой gunicorn, управляющей всеми веб-сайтами (как стандартная установка apache).

Окружение-это 512 МБ виртуальной машины под управлением Ubuntu 11.04 на linode. Конечно, я использую nginx для прокси-запросов к gunicorn.

2 4
virtualenv gunicorn

2 ответа:

На куче наших серверов у нас есть целых 10 различных приложений django, все они работают на своем собственном gunicorn, в своем собственном virtualenv.

Мы используем один системный процесс супервайзера для управления ими всеми.

У нас также есть один процесс nginx, который обрабатывает весь трафик (обратный прокси, обслуживание статических носителей и т. д.) Для всех приложений.

Мы решили использовать этот подход, потому что он кажется наиболее разумным и простым для настройки и управления каждым приложением самостоятельно. С помощью супервизор, чтобы запустить/остановить / перезагрузить каждое приложение самостоятельно, дает нам более точный контроль над тем, что мы хотим сделать. Это также делает его действительно легко добавить больше приложений, и не влияет на те, которые уже находятся на машине.

Это также позволяет нам запускать каждое приложение от имени другого пользователя, так что мы лучше контролируем то, что делают эти процессы, и то, что они имеют доступ тоже, что хорошо, если вам нужно беспокоиться о безопасности. Если это все ваши собственные приложения на вашем собственном сервере под вашим столом, тогда это не может быть проблемой для вас.

Если вы запускаете одну версию gunicorn для всего, и что-нибудь случилось с этим процессом gunicorn, то это повлияет на все ваши приложения, что не идеально. Это также ограничивает то, что вы можете сделать, если вы хотите запустить eventlet на одном приложении, gevent на другом и синхронизировать на другом, это проще, если они все работают отдельно. Кроме того, некоторым приложениям может потребоваться больше процессов, чем другим, и это проще настроить если они разделены.

Если вы используете подход apache, это может уменьшить общий объем ресурсов, поскольку вам не нужно будет иметь несколько версий одних и тех же процессов, запущенных для каждого приложения. Если вы ограничены в ресурсах, это может быть более важным для вас, но в настоящее время память и процессор настолько дешевы, что это не проблема.

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

6

Насколько я понимаю, вы говорите о трех вариантах:

  • один единственный процесс Gunicorn для всех ваших проектов
  • одна установка Gunicorn, с отдельными процессами для каждого проекта
  • несколько установок Gunicorn, по одной в каждом virtualenv

Я не уверен, что первый вообще возможен, но Gunicorn docs все, кажется, приспособлены к одному из двух других вариантов, и я думаю, что обычно он должен быть порожден с помощью одного модуля WSGI. Кроме того, вы также потеряете гибкость в том, чтобы убивать или перезапускать серверы для отдельных проектов, не беспокоя других.

Что касается установки отдельного Gunicorn для каждого virtualenv, это, безусловно, подход , предложенный командой Gunicorn, и тот, который даст вам гибкость в использовании функций из более новой версии Gunicorn в новом проекте, не нарушая потенциально существующие версии.

Короткий ответ: вам нужно иметь отдельные экземпляры Gunicorn для каждого проекта; есть ли у вас отдельные установки, также зависит от вас, но это, вероятно, сэкономит вам время и головную боль.

4