Как работает Gunicorn и для чего он используется?

Question

Gunicorn — это сервер приложений для Python, который запускает ваше веб-приложение (обычно WSGI-приложение) и управляет несколькими рабочими процессами. Он принимает входящие соединения, распределяет запросы по worker’ам и перезапускает их при сбоях. Gunicorn часто ставят за reverse proxy (например, Nginx). Он нужен, чтобы приложение могло обслуживать много запросов и работать стабильнее, чем встроенный dev-сервер.

YeaHub · Accepted Answer

Gunicorn (Green Unicorn) — это production-сервер для запуска Python веб-приложений. Его ключевая роль — не “писать бизнес-логику”, а надёжно принимать запросы и отдавать их вашему приложению в нескольких процессах (и иногда потоках), обеспечивая параллельность и устойчивость.Где он находится в архитектуреЧастая схема:Клиент (браузер/мобильное приложение)Reverse proxy (часто Nginx)завершает TLS (HTTPS)умеет раздавать статикуможет буферизовать запросыGunicornдержит пул worker’овпроксирует запросы в приложениеПриложение (Django/Flask и др.)выполняет бизнес-логикуходит в БД/кэш/очередьКак Gunicorn обслуживает запросыОсновная идея: один процесс Python неэффективен для параллельной обработки большого числа запросов. Поэтому Gunicorn запускает несколько worker-процессов.Master processстартует и контролирует worker’овперезапускает worker, если он упалможет делать “graceful reload” конфигурацииWorker processesреально выполняют обработку запросовкаждый worker обрабатывает запросы независимоесли один worker завис/упал, остальные продолжают работатьТипы worker’ов (важно для понимания ограничений)Sync workers (по умолчанию)один worker обрабатывает один запрос за разпараллельность достигается количеством процессовхорошо подходит для CPU/IO-смешанных задач, если запросы не “висят” очень долгоThread workers (gthread)внутри worker есть несколько потоковполезно, если много I/O и хочется меньше процессовAsync workers (gevent/eventlet)рассчитаны на большое количество одновременных соединенийтребуют определённой модели кода и аккуратности с блокирующими вызовамиПочему Gunicorn “лучше dev-сервера”Встроенные dev-серверы (например, Flask/Django) предназначены для разработки:слабее по устойчивостине рассчитаны на высокую нагрузкучасто однопроцессныеGunicorn даёт:управление worker’амиперезапуск при паденияхнормальную модель запуска в productionПример запускаДля WSGI-приложения (например, Django):gunicorn myproject.wsgi:application --workers 4 --bind 0.0.0.0:8000
Для Flask-приложения:gunicorn app:app --workers 4 --bind 0.0.0.0:8000
Где:--workers 4 — количество процессов--bind — адрес и портКак выбирать число worker’овНа практике ориентируются на:количество CPUхарактер нагрузки (CPU-bound или I/O-bound)лимиты памятиЧасто используют эмпирическое правило (как стартовую точку):workers = 2 * CPU + 1Но это не “закон”, потому что:если запросы тяжёлые по памяти, много worker’ов приведёт к OOMесли запросы mostly I/O, можно использовать threads или asyncВажные параметры для стабильностиТаймаутызащищают от “вечных” запросовпример: --timeout 30Лимиты на запросыперезапуск worker после N запросов помогает лечить утечки памятипример: --max-requests 1000 --max-requests-jitter 100Логидоступы и ошибки важны для диагностикиобычно логирование централизуют (stdout/stderr в контейнере)ВыводGunicorn используют для запуска Python веб-приложений в production, потому что он обеспечивает параллельность через worker-процессы, устойчивость через контроль и перезапуск, и удобную интеграцию с reverse proxy. Он особенно полезен, когда нужно обслуживать много запросов и не зависеть от ограничений dev-сервера.