Я ищу слишком упрощенный ответ на следующий вопрос. Я пытаюсь сформировать фундаментальное понимание того, как Nginx работает вместе с чем-то вроде Gunicorn.
Нужен ли мне Nginx и что-то вроде Gunicorn для развертывания приложений Django на Nginx?
Если да, то что на самом деле обрабатывает HTTP-запросы?
Пс. Я не хочу использовать 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 мы приняли конкретное решение (копирование из Ruby Unicorn), чтобы держать вещи отдельно от Nginx, полагаясь на поведение прокси Nginx. В частности, если мы можем предположить, что Gunicorn никогда не будет читать соединения напрямую из Интернета, тогда нам не нужно беспокоиться о медленных клиентах. Это означает, что модель обработки для Gunicorn поразительно проста.
Такое разделение также позволяет писать Gunicorn на чистом Python, что минимизирует стоимость разработки, не влияя существенно на производительность. Это также позволяет пользователям использовать другие прокси (при условии, что они правильно буферизуются).
Что касается вашего второго вопроса о том, что на самом деле обрабатывает HTTP-запрос, простой ответ - Gunicorn. Полный ответ заключается в том, что запрос обрабатывают как Nginx, так и Gunicorn. По сути, Nginx получит запрос, и если это динамический запрос (обычно на основе шаблонов URL), он передаст этот запрос Gunicorn, который обработает его, а затем вернет ответ Nginx, который затем перенаправит ответ обратно исходному. клиент.
В заключение, да. Для правильного развертывания Django вам понадобятся и Nginx, и Gunicorn (или что-то подобное). Если вы специально хотите разместить Django с Nginx, я бы исследовал Gunicorn, mod_uwsgi и, возможно, CherryPy как кандидатов на сторону Django.
Мне понравилось это объяснение своей простотой:
Nginx столкнется с внешним миром. Он будет обслуживать медиафайлы (изображения, CSS и т. Д.) Непосредственно из файловой системы. Однако он не может напрямую взаимодействовать с приложениями Django; ему нужно что-то, что будет запускать приложение, подавать ему запросы из Интернета и возвращать ответы.
Это работа Гуникорна. Gunicorn создаст сокет Unix и будет обслуживать ответы nginx через протокол wsgi - сокет передает данные в обоих направлениях:
The outside world <-> Nginx <-> The socket <-> Gunicorn
Gunicorn - пустая трата ресурсов. Вы можете просто перейти к django, прослушивающему порт, вместо того, чтобы запускать gunicorn поверх django и снова nginx поверх всего этого. В тестах я заметил очень заметное увеличение скорости. Nginx может легко обрабатывать прямые запросы к django. Gunicorn - это не что иное, как эстакада (фактически более медленная эстакада) над обычной дорогой. Он просто сидит и ест ваши ресурсы и пытается заявить, что поддерживает ваш сайт.
nginx в основном буферизует все запросы и самостоятельно обрабатывает запросы статических файлов (если вы настроили его таким образом). И передает весь динамический контент на другой сервер (gunicorn / django).
У Gunicorn нет другого использования, кроме как просто передать запрос приложению. Это похоже на соломинку, которую вы можете пить прямо из стакана или пить из соломинки в ограниченном темпе (здесь пьющий человек - джанго). А nginx - это официант, который принес вам стакан сока.
Я проверил тесты и нашел это - с Gunicorn: 22k запросов / с без Gunicorn: 34k запросов / s
Вашему сайту потребуются дополнительные запросы при большой нагрузке.
Я ищу слишком упрощенный ответ ...
Нужен ли мне Nginx и что-то вроде Gunicorn для развертывания приложений Django на Nginx?
Если да, то что на самом деле обрабатывает HTTP-запросы?
Чрезмерно упрощенный ответ:
ДА.
И Nginx, и Gunicorn.
Поскольку вы выполняете развертывание на Nginx, вам, конечно же, понадобится Nginx.
Поскольку вы развертываете Django, который представляет собой веб-фреймворк, вам нужно что-то, соединяющее обмен данными между веб-сервером (Nginx) и веб-фреймворком (Django). В мире Python такая вещь называется сервером WSGI (но считайте его промежуточным продуктом), примеры которого включают Gunicorn и uWSGI. При обработке запроса Nginx передает запрос Gunicorn или uWSGI, который, в свою очередь, вызывает код Django и возвращает ответ.
Этот документ и ответ Павла поможет вам лучше это узнать.