Gunicorn: Какой-то способ обслуживать множество приложений WSGI через один и тот же экземпляр Gunicorn.

Созданный на 29 мар. 2010  ·  7Комментарии  ·  Источник: benoitc/gunicorn

Как вы думаете, это хорошая идея, если у нас есть способ запускать множество приложений через один и тот же экземпляр Gunicorn, чтобы они использовали один и тот же интерпретатор (-ы) Python.
По крайней мере, для меня это будет очень полезно, потому что это сэкономит много оперативной памяти, так как у меня есть много небольших приложений (с очень низкой нагрузкой), которые работают на одном компьютере.

Add Example

Самый полезный комментарий

Я должен согласиться с jbergstroem, что это не относится к ядру. Но я пошел дальше и добавил пример, показывающий, как этого можно добиться с помощью Routes:

http://github.com/benoitc/gunicorn/blob/master/examples/multiapp.py

Все 7 Комментарий

Я думаю, что такое поведение лучше всего решает конечный пользователь. Есть явная разница в том, как Gunicorn работает с «несколькими сайтами» по сравнению с обычным веб-сервером.
Я бы предложил использовать простую библиотеку Python, такую ​​как werkzeug, и заставить ваши два приложения отвечать на разных маршрутах.

Я должен согласиться с jbergstroem, что это не относится к ядру. Но я пошел дальше и добавил пример, показывающий, как этого можно добиться с помощью Routes:

http://github.com/benoitc/gunicorn/blob/master/examples/multiapp.py

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

Да, это вполне возможно. Вы можете написать простое отображение среды ['HTTP_HOST'] в приложения.

Я думаю, это может быть встроено в Gunicorn, как вы думаете?

Это может быть какая-то необязательная часть Gunicorn, например, contrib, да.

Думаю, лучше всего было бы как отдельное приложение-мультиплексор с отдельной конфигурацией. Здесь также должна пройти специализация Django / Paste. Нравится:

$ gunicorn wsgi_multi django:project1 myblog.wsgi:wsgi_app anotherapp.foo

Здесь gunicorn запускает только одно приложение wsgi_multi, остальные аргументы передаются ему через какой-то специальный API. Или через конфиг, или как-то еще.

Я потратил много времени, пытаясь написать что-то вроде того, что предлагается в этом билете. Сначала я попробовал использовать код, который переключал virtualenv на основе HTTP_HOST. Оказывается, вы действительно не можете деактивировать virtualenvs в чистом питоне, так что это была промывка.

Затем я подумал: может быть, у нас может быть просто требование, чтобы это был один-единственный virtualenv, поэтому я написал код для переключения на разные приложения WSGI на основе HTTP_HOST только для того, чтобы обнаружить, что вы не можете запускать два приложения django бок о бок, потому что django поддерживает поистине поразительное количество глобальных переменных повсюду.

По сути, я хочу сказать, что это не так просто или даже выполнимо, как предлагалось выше.

Может быть, более целесообразно сделать какую-то вещь с балансировкой нагрузки, когда рабочие работают в разных виртуальных средах в зависимости от приложения, а центральный мастер-пулемет следит за тем, чтобы приложения, которым нужно больше рабочих, получали их? Наверное, писать нелегко или весело :(

Я бы очень хотел, чтобы django был очищен, чтобы сделать такие вещи возможными ...

Была ли эта страница полезной?
0 / 5 - 0 рейтинги