Как работает развёртывание Python-приложений: от запроса до ответа

Зачем нужен gunicorn? А зачем — Nginx? Эти вопросы часто задают разработчики, впервые сталкивающиеся с деплоем Python-приложений. Может показаться, что веб-приложение — это просто код на Flask или Django, который запускается и принимает запросы. Но на практике между пользователем и вашим кодом выстраивается целая цепочка инфраструктурных компонентов, каждый из которых решает важную задачу. На схеме показан путь HTTP-запроса от клиента до конечного обработчика в приложении и обратно.

Accept: принимаем запрос

Когда пользователь открывает ваш сайт, он отправляет HTTP-запрос. Этот запрос в первую очередь встречается с внешним сервером — чаще всего это nginx. Его задача — понять, куда направить запрос: отдать ли статику, переписать URL, направить на конкретное приложение, или вовсе отклонить (например, по причине отсутствия авторизации). Он также может выполнять кэширование, сжатие и защищать от некоторых видов атак. Сюда же можно отнести балансировщики нагрузки и ingress-контроллеры в Kubernetes.

Translate: превращаем байты в Python

Следующий этап — перевод сетевого запроса в то, что понимает ваше Python-приложение. Это задача gunicorn или аналогичных серверов, поддерживающих WSGI (или ASGI, если речь о FastAPI и асинхронных приложениях). gunicorn создаёт рабочие процессы, слушает сокет, принимает соединения от nginx и передаёт их дальше в код Python. Он изолирует логику приложения от низкоуровневой сетевой части и обеспечивает масштабируемость.

Process: бизнес-логика и генерация ответа

Завершающий этап — сам Python-код во фреймворке (Django, Flask, FastAPI и пр.). Здесь выполняются проверки, обращения к БД, формируются HTML-страницы или JSON-ответы. Именно здесь происходит «магия» — добавление ценности, решение задач пользователей и реализация бизнес-логики.

#факт #основы
@zen_of_python

👀 — Если пришлось перечитать три раза