Какие серверы используются для развертывания Django-приложений в production?

Так, слушай, раз уж ты полез в это болото под названием "продакшен", давай я тебе на пальцах, но без потери технической сути, объясню, как там всё устроено, а то иначе наебнёшься на ровном месте.

Представь себе: твой Django — это такой гениальный, но слегка заумный повар на кухне ресторана. Он умеет готовить блюда (твою логику) по высшему разряду, но если к нему ворвутся сразу сто голодных посетителей и начнут орать свои заказы — он просто встанет в ступор, блядь. Ему нужен нормальный организатор.

Вот тут и появляется наша двухэтажная конструкция, без которой нихуя не работает.

Этаж первый, WSGI-сервер (Gunicorn / uWSGI). Это — старший по кухне, суровый бригадир. Его задача — растолкать твоего Django-повара, заставить его работать и передавать ему сырые заказы (HTTP-запросы), а готовые блюда (HTTP-ответы) — забирать. Без него Django в продакшене — просто кусок умного, но беспомощного кода. Запускаешь его примерно так, и он начинает слушать на порту:

gunicorn myproject.wsgi:application --bind 0.0.0.0:8000

Этаж второй, Веб-сервер (Nginx / Apache). А это — лицо ресторана, харизматичный метрдотель и вышибала в одном флаконе. Он стоит у входа. Его работа:

1. Встретить клиента (браузер).
2. Принять у него заказ (запрос).
3. НЕ пускать его на саму кухню (это важно, ёпта!), а отнести бумажку с заказом тому самому бригадиру (WSGI-серверу).
4. Забрать готовое блюдо и красиво подать.
5. А ещё он мастерски раздаёт всем желающим меню и картинки блюд — то есть твои статические файлы (CSS, JS, картинки). Делает он это в сотни раз быстрее, чем это будет делать Python.
6. И, как вишенка на торте, он же отвечает за HTTPS — тот самый зелёный замочек. Он расшифровывает все эти SSL-шифры, чтобы кухне не париться.

Популярные связки, которые просто работают:

• Gunicorn + Nginx — это как «вода и хлеб», стандарт де-факто. Gunicorn — простой и надёжный, Nginx — быстрый и жадный до статики. В 95% случаев бери это и не думай.
• uWSGI + Nginx — это уже для ценителей, когда нужно тонко настроить каждый болтик. Мощнее, гибче, но можно так закопаться в настройках, что хуй выкопаешься.
• Apache + mod_wsgi — это типа старый, проверенный дедовский способ. Но он жрёт память, как не в себя, и сложнее. Сейчас его берут, только если вся инфраструктура уже под него заточена.

А если у тебя там веб-сокеты или асинхронная магия (Django Channels)? Тогда забудь про WSGI, ему это не по зубам. Тебе нужны ASGI-серверы: Daphne или Uvicorn. Они понимают этот новый асинхронный шифр. Но Nginx перед ними всё равно нужен — как тот же метрдотель и вышибала.

И главное, блядь, ЗАПОМНИ НАВСЕГДА:

• python manage.py runserver — это НЕ ДЛЯ ПРОДАКШЕНА. Это как тренировочная кухня в гараже. Для друзей и для разработки — ок. Выпускать с этим сервером проект в мир — это всё равно что пригласить всех желающих прямо к повару на кухню, где он один и спит на раскладушке. Безопасность — ноль, производительность — пиздец. Не делай так, а то потом будешь чесать репу и думать, почему всё легло от пяти пользователей.
• Статику отдавай через Nginx. Заставь его работать, не заставляй Django этим заниматься — он для другого.
• HTTPS — это must have. В 2024 году без него — просто стыд и срам.
• И да, если хочешь себе жизни проще — посмотри в сторону Docker. Это такая универсальная упаковка для твоего повара, кухни и всех соусов, чтобы это гарантированно работало где угодно. Но это уже отдельная песня, про контейнеры и оркестры.

Короче, суть: Nginx встречает и фильтрует, Gunicorn (или другой) — запускает и управляет работой Django. Всё.