Skip to content

nginx.md

Latest commit

 

History

History
110 lines (78 loc) · 7.31 KB

nginx.md

File metadata and controls

110 lines (78 loc) · 7.31 KB
Raw

← Оглавление

nginx (веб-сервер)

Быстрый привратник перед приложением: раздаёт статику, терминирует HTTPS, балансирует нагрузку

nginx («энджин-икс») — высокопроизводительный веб-сервер и обратный прокси. За счёт событийной (асинхронной) архитектуры держит десятки тысяч одновременных соединений на скромном железе. В типичном бэкенде nginx стоит перед приложением (gunicorn/uvicorn) и берёт на себя всё, с чем сервер приложений справляется хуже.

Что такое веб-сервер

Веб-сервер — программа, принимающая HTTP-запросы и отдающая ответы. Две базовые роли nginx:

  • Отдача статики — HTML, CSS, JS, картинки: nginx читает файл с диска и отдаёт очень быстро, не поднимая Python.
  • Обратный прокси — принимает запрос от клиента и перенаправляет его внутреннему серверу приложений, а ответ возвращает клиенту.

Зачем nginx перед приложением

Сервер приложений (gunicorn/uvicorn) умеет исполнять Python-код, но плохо приспособлен смотреть в интернет напрямую. nginx закрывает это:

  • Статика — раздаёт файлы, разгружая приложение;
  • TLS-терминация — принимает HTTPS, расшифровывает, дальше внутри — обычный HTTP (TLS);
  • Балансировка — распределяет запросы между несколькими воркерами/серверами приложения;
  • Буферизация медленных клиентов — держит медленное соединение на себе, не занимая дорогой воркер приложения;
  • Сжатие (gzip), кеширование, ограничение частоты (rate limit), заголовки безопасности (Веб-безопасность).
Клиент ──HTTPS──▶ nginx ──HTTP──▶ gunicorn/uvicorn ──▶ приложение (Django/FastAPI)
                    │
                    └─ статика (css/js/img) отдаёт сам

Прямой и обратный прокси — не путать

  • Прямой прокси — стоит на стороне клиента, скрывает его от серверов (VPN, корпоративный фильтр).
  • Обратный прокси (nginx) — стоит на стороне сервера, скрывает внутренние серверы приложения от клиента. Клиент думает, что общается с одним сервером.

Балансировка нагрузки

nginx распределяет запросы между группой серверов (upstream):

upstream app {
    server 127.0.0.1:8000;      # воркеры приложения
    server 127.0.0.1:8001;
    # least_conn;  ip_hash;     # стратегия вместо round-robin по умолчанию
}

Стратегии: round-robin (по кругу, по умолчанию), least_conn (кому меньше активных соединений), ip_hash (клиент всегда на тот же сервер — липкие сессии).

Базовый конфиг

Конфигурация — блоки server (виртуальный хост) и location (правило по пути):

server {
    listen 80;
    server_name example.com;

    location /static/ {
        root /var/www/app;           # отдавать файлы с диска
    }

    location / {
        proxy_pass http://app;        # проксировать в upstream "app"
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}
  • listen — порт; server_name — домен;
  • location /static/ — статику отдаёт сам nginx;
  • location / — остальное проксирует в приложение (proxy_pass).

nginx против альтернатив

nginx Apache Caddy
Модель событийная (async) процессы/потоки событийная
Статика/прокси очень быстро медленнее под нагрузкой быстро
HTTPS вручную (+certbot) вручную автоматически (Let's Encrypt)
Когда прод, высокая нагрузка легаси, .htaccess простые проекты, авто-TLS

Типичный прод-стек

nginx (веб-сервер + TLS + балансировка)
  → gunicorn (WSGI, для Django/Flask)  ИЛИ  uvicorn (ASGI, для FastAPI)
    → приложение

Часто всё это упаковано в Docker-контейнеры и оркестрируется Kubernetes (где роль «входной двери» берёт Ingress-контроллер, нередко тот же nginx).

Связи

Источники