Зачем мне Nginx и что-то вроде Gunicorn?
Я ищу слишком упрощенный ответ на следующий вопрос. Я пытаюсь построить фундаментальное понимание того, как Nginx работает рядом с чем-то вроде Gunicorn.
Нужно ли мне как Nginx, так и что-то вроде Gunicorn для развертывания приложений Django на Nginx?
Если да, то на самом деле обрабатывает HTTP-запросы?
Ps. Я не хочу использовать Apache и mod_wsgi!
2 ответа
Слишком упрощенное: вам нужно что-то, что выполняет 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.
Мне понравилось это объяснение в его простоте:
Nginx столкнется с внешним миром. Он будет обслуживать мультимедийные файлы (изображения, CSS и т. Д.) Непосредственно из файловой системы. Однако он не может говорить непосредственно в приложениях Django; ему нужно что-то, что будет запускать приложение, подавать его запросы из Интернета и возвращать ответы.
Это работа Гуникорна. Gunicorn создаст сокет Unix и будет служить ответы на nginx по протоколу wsgi - сокет передает данные в оба направления:
Внешний мир <-> Nginx -> Сокет <-> Gunicorn