Навіщо мені потрібен Nginx і щось на зразок гунікорна?

Я шукаю надто спрощену відповідь на наступне запитання. Я намагаюся побудувати фундаментальне розуміння того, як Nginx працює поряд із чимось на зразок Гунікорна.

Чи потрібні мені і 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 ми прийняли конкретне рішення (копіювання з Єдинорога Рубі), щоб тримати речі окремо від Nginx, покладаючись на близьку поведінку Nginx. Зокрема, якщо ми можемо припустити, що Гунікорн ніколи не читатиме з'єднання безпосередньо з Інтернету, то нам не доведеться турбуватися про повільних клієнтів. Це означає, що модель обробки для Гунікорна незручно проста.

Розділення також дозволяє записати Gunicorn на чистому Python, що мінімізує витрати на розробку, не суттєво впливаючи на продуктивність. Він також дозволяє користувачам використовувати інші проксі-сервери (якщо припустимо, що вони буферизовані правильно).

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

Тож на завершення, так. Для правильного розгортання Django вам потрібні і Nginx, і Gicicorn (або щось подібне). Якщо ви спеціально прагнете приймати 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, звичайно, вам потрібен Nginx.

Оскільки ви розгортаєте Django, який є веб-рамкою, вам потрібно щось з’єднати розмови між веб-сервером (Nginx) та веб-рамкою (Django). У світі Python таке поняття називають сервером WSGI (але думайте, що це середній посуд), приклади якого включають Gunicorn та uWSGI. Обробляючи запит, Nginx передає запит Gunicorn або uWSGI, який, в свою чергу, викликає код Django і повертає відповідь.

Цей документ та відповідь Павла допоможуть вам краще його навчитися.

Гунікорн - це марна трата ресурсів. Ви можете просто проксі пройти до прослуховування джанго на порту замість запуску рушниці на верхньому джанго і знову nginx на вершині всього цього. У орієнтирах я бачив дуже помітне зростання швидкості. Nginx може легко обробляти прямі запити на джанго. Гунікорн - це не що інше, як проліт (фактично повільніший проліт) над звичайною дорогою. Він просто сидить і їсть ваші ресурси і намагається заявити, що він працює на вашому веб-сайті.

nginx в основному буферизує всі запити та обробляє запити статичного файлу сам (якщо ви його так налаштували). І передає весь динамічний вміст на інший сервер (gunicorn / django).

Гунікорну немає іншого використання, ніж просто передавати запит заявці. Це як солома, яку можна пити безпосередньо зі скла або пити з соломи обмеженим темпом (тут людина, яка п'є, - джанго). А nginx - це офіціант, який приніс тобі склянку соку.

Я зробив орієнтир і знайшов це - з gunicorn: 22k req / s без gunicorn: 34k req / s

Вашому сайту знадобиться додаткова кількість запитів / с у великому навантаженні.