Для чего нужен Gunicorn?

Зачем нужен Gunicorn

Gunicorn (Green Unicorn) — это **WSGI HTTP сервер** для Python приложений. Это критически важный компонент при развёртывании production-приложений. Давайте разберёмся, почему он нужен.

Проблема: встроенный Flask/Django сервер

Часто новички запускают приложение так:

# app.py
from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello!"

if __name__ == "__main__":
    app.run(debug=True)  # ❌ НИКОГДА не используй в production!

Почему это плохо:

• Однопоточность: Может обработать только 1 запрос одновременно
• Медленнее: Нет оптимизации для production нагрузок
• Нестабильность: Падает при ошибках, нет автоперезагрузки
• Не масштабируется: Cannot handle significant traffic

Что такое Gunicorn

Gunicorn — это production-grade WSGI сервер, который решает все эти проблемы:

# Архитектура Gunicorn
"""
Client → Load Balancer → Gunicorn Master Process
                         ├─ Worker Process 1
                         ├─ Worker Process 2
                         ├─ Worker Process 3
                         └─ Worker Process N

Каждый worker может обрабатывать свой запрос одновременно!
"""

Основные преимущества

1. Многопроцессность (Multi-worker)

Gunicorn запускает несколько рабочих процессов, каждый может обрабатывать отдельные запросы:

# Запуск с 4 workers (по умолчанию 2)
gunicorn --workers 4 app:app

# Теперь сервер может обработать 4 одновременных запроса
# Без Gunicorn Flask может только 1

2. Graceful shutdown и reload

Gunicorn корректно перезагружает приложение без потери запросов:

# Kill и restart workers без downtime
gunicorn --reload app:app  # Перезагружает при изменении кода

# Или сигнал HUP для graceful restart
kill -HUP <gunicorn-master-pid>

3. Обработка различных типов workers

# Sync worker (по умолчанию, для быстрых запросов)
gunicorn --workers 4 app:app

# Async worker (для I/O операций)
gunicorn --worker-class gevent --workers 4 app:app

# Tornado worker
gunicorn --worker-class tornado app:app

# Asyncio worker (Python 3.5+)
gunicorn --worker-class uvicorn.workers.UvicornWorker app:app

Реальный пример конфигурации

# gunicorn_config.py
import multiprocessing

# Основные параметры
bind = "0.0.0.0:8000"  # Слушаем на всех интерфейсах
workers = multiprocessing.cpu_count() * 2 + 1  # Правило для CPU-bound
worker_class = "sync"  # или "gevent" для I/O
worker_connections = 1000  # Макс соединений на worker

# Timeouts
timeout = 30  # Убить worker если не ответил за 30 сек
keepalive = 2  # Keep-alive timeout

# Логирование
accesslog = "-"  # Log to stdout
errorlog = "-"  # Error log to stdout
loglevel = "info"

# Graceful shutdown
graceful_timeout = 30  # Время на graceful shutdown

# Preload
preload_app = True  # Загруз код в master процесс

# Server hooks
def on_starting(server):
    print("Gunicorn server is starting...")

def when_ready(server):
    print(f"Server is ready. Spawning workers")

Запуск с конфигом:

gunicorn --config gunicorn_config.py app:app

Docker пример (лучшая практика)

# Dockerfile
FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

# Стартуем через gunicorn, а не python
CMD ["gunicorn", "--workers", "4", "--bind", "0.0.0.0:8000", "app:app"]

Gunicorn vs другие серверы

Ключевые метрики при конфигурации

# Сколько workers нужно?
# Формула для CPU-bound: cpu_count * 2 + 1
# Формула для I/O-bound: cpu_count * 4 + 1

import multiprocessing

workers_cpu_bound = multiprocessing.cpu_count() * 2 + 1
workers_io_bound = multiprocessing.cpu_count() * 4 + 1

print(f"Рекомендуемые workers для CPU: {workers_cpu_bound}")
print(f"Рекомендуемые workers для I/O: {workers_io_bound}")

Интеграция с Nginx (best practice)

# Nginx конфиг
upstream gunicorn {
    server 127.0.0.1:8000;
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://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;
    }
}

Вывод

Gunicorn нужен потому что:

• ✅ Обрабатывает множество одновременных запросов (многопроцессность)
• ✅ Production-ready (graceful shutdown, monitoring, logging)
• ✅ Легко конфигурируется и масштабируется
• ✅ Работает с любыми WSGI фреймворками (Flask, Django, Pyramid)
• ✅ Стабилен и надёжен, проверен тысячами приложений
• ✅ Меньше памяти чем uWSGI, проще конфигурация

Bез Gunicorn (или аналога) в production вы получите медленное, нестабильное приложение. С ним — scalable, надёжный сервис.