Вопрос: Зачем мне Nginx и что-то вроде Gunicorn?


Я ищу слишком упрощенный ответ на следующий вопрос. Я пытаюсь построить фундаментальное понимание того, как Nginx работает рядом с чем-то вроде Gunicorn.

Нужен ли мне Nginx и что-то вроде Gunicorn для развертывания приложений Django на Nginx?

Если да, то на самом деле обрабатывает HTTP-запросы?

Ps. Я не хочу использовать Apache и mod_wsgi!


174
2017-11-15 21:16


Источник


Apache и mod_wsgi - это самый простой способ реализации моста между вашим приложением django и HTTP-запросами, который также очень способен в производственной среде. Для многих разработчиков это означает, что «Apache лучше, чем nginx», если они это сделали, но знают это, но поскольку «бетамакс лучше, чем VHS», увы, правила Dogma - MagicLAMP


Ответы:


Слишком упрощенное: вам нужно что-то, что выполняет Python, но Python не подходит для обработки всех типов запросов.

[отказ от ответственности: я разработчик Gunicorn]

Менее упрощено: независимо от того, какой сервер приложений вы используете (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy), любое нетривиальное развертывание будет иметь что-то вверху, которое будет обрабатывать запросы, которые ваше приложение Django не должно обрабатывать. Тривиальные примеры таких запросов служат для статических ресурсов (images / css / js).

Это приводит к двум первым уровням классической «трехуровневой архитектуры». То есть, веб-сервер (Nginx в вашем случае) будет обрабатывать множество запросов на изображения и статические ресурсы. Запросы, которые должны быть динамически сгенерированы, затем передаются на сервер приложений (Gunicorn в вашем примере). (В стороне, третий из трех уровней - база данных)

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

В современную эпоху у нас теперь есть приложения всех форм и размеров. Не каждый проект на выходные или малый бизнес на самом деле нуждается в лошадиных силах нескольких машин и будет работать вполне счастливо на одной коробке. Это привело к появлению новых записей в массиве решений для хостинга. Некоторые решения выйдут за сервер приложений на веб-сервер (Apache httpd + mod_wsgi, Nginx + mod_uwsgi и т. Д.). И вовсе не редкость размещать базу данных на том же компьютере, что и одна из этих комбинаций веб-приложений.

Теперь, в случае с Gunicorn, мы приняли конкретное решение (копирование с Unicorn Ruby), чтобы отделить вещи от Nginx, полагаясь на прокси-поведение Nginx. В частности, если мы можем предположить, что Gunicorn никогда не будет читать подключения непосредственно из Интернета, тогда нам не нужно беспокоиться о медленных клиентах. Это означает, что модель обработки для Gunicorn неловко проста.

Разделение также позволяет Gunicorn записываться на чистом Python, что минимизирует затраты на разработку, не оказывая значительного влияния на производительность. Он также позволяет пользователям использовать другие прокси (при условии, что они правильно буферизуют).

Что касается вашего второго вопроса о том, что на самом деле обрабатывает HTTP-запрос, то простым ответом является Gunicorn. Полный ответ: Nginx и Gunicorn обрабатывают запрос. В принципе, Nginx получит запрос, и если это динамический запрос (обычно основанный на шаблонах URL), тогда он предоставит этот запрос Gunicorn, который обработает его, а затем вернет ответ Nginx, который затем перенаправляет ответ обратно на оригинал клиент.

Так что в заключение, да. Для правильного развертывания Django вам нужны как Nginx, так и Gunicorn (или что-то подобное). Если вы специально хотите разместить Django с Nginx, я бы исследовал Gunicorn, mod_uwsgi и, возможно, CherryPy в качестве кандидатов на роль Django.


258
2017-11-15 21:49



Спасибо, что нашли время написать такой подробный ответ! Любое рекомендуемое чтение этой «трехуровневой архитектуры»? - a.m.
Отличный ответ, однако я не понимаю проблему с медленными клиентами. - Mads Skjern
@MadsSkjern Я предполагаю, что здесь, но если вы предполагаете, что все клиенты бывают быстрыми, то вы можете использовать фиксированный пул рабочих процессов и не иметь кода для случая, когда многие или все из них блокируются в ожидании клиента. - Jonathan Hartley
@ A.m. en.wikipedia.org/wiki/Multitier_architecture - Jonathan Hartley
мое приложение django только обслуживает json без статического контента, я могу просто пойти с пушкой и не nginx - Sar009


Мне понравилось это объяснение в его простоте:

Nginx столкнется с внешним миром. Он будет обслуживать мультимедийные файлы (изображения,   CSS и т. Д.) Непосредственно из файловой системы. Однако он не может говорить   непосредственно в приложениях Django; ему нужно что-то, что будет запускать   приложение, подавать его запросы из Интернета и возвращать ответы.

Это работа Гуникорна. Gunicorn создаст сокет Unix и будет служить   ответы на nginx по протоколу wsgi - сокет передает данные в   в обоих направлениях:

The outside world <-> Nginx <-> The socket <-> Gunicorn

https://gist.github.com/Atem18/4696071


17
2017-12-13 07:52



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