Зачем мне нужен Nginx и что-то вроде Gunicorn?

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

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

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

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

Слишком упрощенно: вам нужно что-то, что выполняет 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 Руби), чтобы отделить вещи от Nginx, полагаясь на поведение прокси Nginx. В частности, если мы можем предположить, что Gunicorn никогда не будет читать соединения напрямую из Интернета, то нам не нужно беспокоиться о клиентах, которые работают медленно. Это означает, что модель обработки для Gunicorn очень проста.

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

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

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

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

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

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

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

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

Я ищу слишком упрощенный ответ ...

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

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

Слишком упрощенный ответ:

ДА.

И Nginx и Gunicorn.

Поскольку вы развертываете на Nginx, конечно, вам нужен Nginx.

Поскольку вы развертываете Django, который является веб-фреймворком, вам нужно что-то связующее между веб-сервером (Nginx) и веб-фреймворком (Django). В мире Python такая вещь называется сервером WSGI (но думаю, что это промежуточное ПО), примерами которого являются Gunicorn и uWSGI. При обработке запроса Nginx передает запрос в Gunicorn или uWSGI, который, в свою очередь, вызывает код Django и возвращает ответ.

Этот документ и ответ Пола помогут вам узнать его лучше.

Gunicorn - это пустая трата ресурсов. Вы можете просто прокси передать django, слушая порт, вместо запуска gunicorn поверх django и снова nginx поверх всего этого. В тестах я видел очень заметное увеличение скорости. Nginx может легко обрабатывать прямые запросы к django. Gunicorn - это не что иное, как эстакада (фактически более медленный эстакада) над обычной дорогой. Он просто сидит и пожирает ваши ресурсы и пытается заявить, что работает на вашем сайте.

nginx в основном буферизует все запросы и обрабатывает запросы статических файлов самостоятельно (если вы настроили его таким образом). И передает весь динамический контент на другой сервер. (Gunicorn / django).

Gunicorn не имеет другого применения, кроме как просто передать запрос в приложение. Это как соломинка, которую можно пить из стекла напрямую или пить из соломы в ограниченном темпе (здесь пьющий - джанго). А nginx - официант, который принес тебе стакан сока.

Я проверил и нашел это - с оружейным: 22 тыс. Запросов / с без оружейного: 34 тыс. Запросов / с

Вашему сайту понадобятся дополнительные требования при большой нагрузке.