Перейти на PRO

Как Django взаимодействует с Nginx и Gunicorn?

Тип вопроса: Devops Вероятность: 10% Категория: Python Разработчик

Ответ

В производственной среде Django-приложения обычно развертываются с использованием связки Nginx и Gunicorn. Эта архитектура обеспечивает масштабируемость, производительность и надежность, разделяя обязанности между компонентами:

  1. Gunicorn (Green Unicorn):

    • Роль: Gunicorn — это WSGI (Web Server Gateway Interface) HTTP-сервер для Python. Он запускает Django-приложение, выступая в роли посредника между веб-сервером (Nginx) и самим Django.
    • Функции: Gunicorn принимает HTTP-запросы от Nginx, преобразует их в формат, понятный Django, передает их приложению, а затем отправляет ответы обратно Nginx. Он управляет пулом рабочих процессов (workers) Django, обеспечивая параллельную обработку запросов.
    • Пример запуска: 
      gunicorn myproject.wsgi:application --bind 0.0.0.0:8000 --workers 3

      Здесь myproject.wsgi:application указывает на WSGI-файл Django-проекта, --bind определяет адрес и порт, а --workers — количество рабочих процессов.

  2. Nginx:

    • Роль: Nginx — это высокопроизводительный веб-сервер, обратный прокси-сервер и балансировщик нагрузки. Он является первой точкой контакта для клиентских запросов.
    • Функции:
      • Обратный прокси: Nginx принимает все входящие HTTP-запросы от клиентов и перенаправляет (проксирует) запросы, предназначенные для Django-приложения, на Gunicorn.
      • Обслуживание статических и медиафайлов: Nginx эффективно отдает статические файлы (CSS, JavaScript, изображения) и медиафайлы напрямую клиентам, не нагружая Django-приложение. Это значительно повышает производительность.
      • Балансировка нагрузки: Может распределять запросы между несколькими экземплярами Gunicorn для повышения отказоустойчивости и масштабируемости.
      • SSL/TLS-терминация: Обрабатывает HTTPS-соединения, снимая эту нагрузку с Gunicorn/Django.

Пример конфигурации Nginx (/etc/nginx/sites-available/myproject):

server {
    listen 80;
    server_name example.com www.example.com;

    # Обслуживание статических файлов напрямую Nginx'ом
    location /static/ {
        alias /path/to/your/django/project/staticfiles/;
        expires 30d;
        add_header Cache-Control "public, no-transform";
    }

    # Обслуживание медиафайлов напрямую Nginx'ом
    location /media/ {
        alias /path/to/your/django/project/mediafiles/;
        expires 30d;
        add_header Cache-Control "public, no-transform";
    }

    # Проксирование всех остальных запросов к Gunicorn
    location / {
        proxy_pass http://127.0.0.1:8000; # Адрес, на котором слушает Gunicorn
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 100M; # Увеличение лимита на размер тела запроса
    }
}

Схема работы:
Клиент ➡️ Nginx (обслуживает статику/медиа, проксирует динамические запросы) ➡️ Gunicorn (запускает Django-приложение) ➡️ Django-приложение (обрабатывает логику) ➡️ Gunicorn ➡️ Nginx ➡️ Клиент

Эта связка позволяет Django сосредоточиться на бизнес-логике, Gunicorn — на эффективном выполнении Python-кода, а Nginx — на высокопроизводительной обработке HTTP-запросов и статического контента.

Ответ 18+ 🔞

А, слушай, ну это ж классика, блядь! Ну как без этого, ёпта! Всё равно что хлеб без масла, а водка без закуски — нихуя не работает.

Вот смотри, в продакшене твой Django-проект — это как баба в декрете, сама по себе нихуя не сделает, ей нужна поддержка. И поддержка эта — два здоровых мужика: Nginx и Gunicorn. Один — мозги и лицо, другой — рабочие руки, которые впахивают.

Gunicorn (Зелёный Единорог, блядь, ну назвали так, хули):

  • Чем занимается? Это, типа, главный по Python-шабашке. WSGI-сервер, ёбта. Он берёт твой Django, запускает его, как раба на галерах, и начинает принимать команды.
  • Что делает? Сидит на каком-нибудь порту (типа 8000) и ждёт, когда ему принесут HTTP-запрос. Получил — суёт его в Django, Django пошевелил извилинами, отдал ответ, а Gunicorn — обратно тому, кто принёс. И так в несколько потоков (workers), чтобы не один запрос обрабатывать, а овердохуища.
  • Как его пнуть? Да вот так, смотри:
gunicorn myproject.wsgi:application --bind 0.0.0.0:8000 --workers 3

Всё, приложение живое. Три работяги пашут.

Nginx (А это уже серьёзный пацан):

  • Чем занимается? Это лицо проекта, вышибала и курьер в одном флаконе. Веб-сервер, обратный прокси и по совместительству — силач.
  • Что делает? Всё, блядь!
    • Вышибала/Приёмная: Все запросы от пользователей сначала идут к нему. Он смотрит: "А, тебе статические файлы (css, js, картинки)? На, получай, хули Django грузить!" — и отдаёт их сам, моментально.
    • Курьер: Если запрос динамический (типа "покажи мою страницу"), он берёт его и несёт тому самому Gunicorn'у на порт 8000. "На, обработай, братан".
    • Охранник: Может HTTPS расшифровывать, чтобы Gunicorn не парился. Может запросы между кучей Gunicorn'ов распределять, если их, как тараканов, расплодилось.

Вот как его настроить, чтоб не косячил (/etc/nginx/sites-available/myproject):

server {
    listen 80;
    server_name example.com www.example.com;

    # Статику — сам, быстро, без вопросов
    location /static/ {
        alias /path/to/your/django/project/staticfiles/;
        expires 30d;
        add_header Cache-Control "public, no-transform";
    }

    # Медиа — тоже сам, не дергаем Django по пустякам
    location /media/ {
        alias /path/to/your/django/project/mediafiles/;
        expires 30d;
        add_header Cache-Control "public, no-transform";
    }

    # Всё остальное — вёслами на Gunicorn
    location / {
        proxy_pass http://127.0.0.1:8000; # Тут наш работяга Gunicorn киснет
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        client_max_body_size 100M; # Чтобы жирные файлы залить можно было
    }
}

Итоговая схема, блядь, проще пареной репы: Пользователь → Nginx (отдал статику или сказал "иди нахуй" плохому запросу) → Gunicorn (кричит "Эй, Django, шевелись!") → Django (думает, потеет) → Gunicorn → Nginx → Пользователь (довольный).

Короче, Nginx — это хитрая жопа, которая всё организует, а Gunicorn — это мудя, который заставляет твой Python-код впахивать. Без этой парочки на серьёзных просторах интернета — просто пидарас шерстяной, а не продакшен.

© ХакСобесов, 2026
support@hacksobesov.com