- Home »

Развёртывание Flask-приложений через uWSGI и Nginx на Ubuntu 24.04
Если ты когда-нибудь пытался выкатить своё Flask-приложение в продакшн, то наверняка сталкивался с кучей вопросов: как сделать это быстро, надёжно и без боли? Почему нельзя просто запустить app.run()
на сервере? Как связать всё это с Nginx, чтобы не ловить 502 Bad Gateway? Эта статья — для тех, кто хочет не просто «чтобы работало», а чтобы работало стабильно, быстро и с возможностью масштабирования. Здесь разберём, как развернуть Flask-приложение через uWSGI и Nginx на свежей Ubuntu 24.04, какие подводные камни бывают, и как их обойти. Всё с примерами, схемами и советами из реального опыта.
Как это вообще работает?
Давай разложим по полочкам. Flask — это микрофреймворк для Python, который отлично подходит для создания веб-приложений. Но вот беда: его встроенный сервер — это не для продакшна. Он не умеет работать с несколькими процессами, не держит нагрузку, не дружит с безопасностью. Поэтому на проде Flask обычно запускают через WSGI-сервер (например, uWSGI или Gunicorn), а перед ним ставят фронтенд-прокси — чаще всего Nginx.
- uWSGI — это сервер, который запускает твой Python-код, умеет работать с несколькими воркерами, процессами, потоками, и общается с фронтендом по протоколу WSGI или через сокеты.
- Nginx — быстрый и лёгкий веб-сервер, который принимает запросы от клиентов, раздаёт статику и проксирует динамику на uWSGI.
- Ubuntu 24.04 — свежая стабильная ОС, где всё это можно быстро поднять и автоматизировать.
В итоге схема такая: Клиент → Nginx → uWSGI → Flask. Nginx принимает запросы, если это статика — отдаёт сам, если динамика — прокидывает на uWSGI, который уже дергает Flask-приложение.
Почему не просто Flask?
Flask — это круто, но его встроенный сервер не для боевого применения. Вот почему:
- Нет поддержки многопоточности и мультипроцессности (нагрузка = смерть).
- Нет защиты от DoS, нет логирования, нет graceful restart.
- Не умеет работать с сокетами и прокси.
uWSGI и Nginx решают эти проблемы. uWSGI — это как швейцарский нож для Python-приложений, а Nginx — как бронированный щит, который держит удар и раздаёт статику со скоростью света.
Как быстро и просто всё настроить?
Погнали по шагам. Всё покажу на примере Ubuntu 24.04. Предполагается, что у тебя уже есть VPS или выделенный сервер (если нет — заказать VPS или выделенный сервер).
1. Установка Python, pip и venv
sudo apt update
sudo apt install python3 python3-pip python3-venv -y
2. Создаём виртуальное окружение и ставим Flask
python3 -m venv venv
source venv/bin/activate
pip install flask uwsgi
3. Пишем простое Flask-приложение
# app.py
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "Hello, World from Flask + uWSGI + Nginx!"
if __name__ == "__main__":
app.run()
4. Проверяем, что Flask работает
python app.py
Открываем http://localhost:5000
— должно работать.
5. Настраиваем uWSGI
Создаём файл uwsgi.ini
:
[uwsgi]
module = app:app
master = true
processes = 4
socket = /tmp/flask.sock
chmod-socket = 660
vacuum = true
die-on-term = true
Теперь запускаем uWSGI:
uwsgi --ini uwsgi.ini
uWSGI создаст сокет /tmp/flask.sock
, через который Nginx будет общаться с приложением.
6. Установка и настройка Nginx
sudo apt install nginx -y
Создаём конфиг для сайта, например, /etc/nginx/sites-available/flaskapp
:
server {
listen 80;
server_name example.com;
location / {
include uwsgi_params;
uwsgi_pass unix:/tmp/flask.sock;
}
location /static {
alias /path/to/your/static;
}
}
Символическая ссылка:
sudo ln -s /etc/nginx/sites-available/flaskapp /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx
7. Проверяем!
Открываем браузер, вводим IP или домен — если всё ок, видим «Hello, World from Flask + uWSGI + Nginx!».
Практические советы, схемы и кейсы
Положительный кейс
У тебя несколько Flask-приложений, каждое на своём сокете, Nginx проксирует по разным доменам. Всё работает быстро, нагрузка распределяется между воркерами uWSGI, логи пишутся, можно легко делать zero-downtime деплой через touch reload
.
Отрицательный кейс
Ты запускаешь Flask через app.run()
на 0.0.0.0:5000, прокидываешь порт наружу, ловишь DDOS, приложение падает при нагрузке, статика грузится медленно, логи не пишутся, обновления требуют kill процесса.
Решение | Плюсы | Минусы | Когда использовать |
---|---|---|---|
Flask + uWSGI + Nginx | Скорость, безопасность, масштабируемость, поддержка сокетов, zero-downtime деплой | Чуть сложнее настройка, нужен root-доступ | Продакшн, высокая нагрузка, несколько приложений |
Flask встроенный сервер | Просто, быстро для теста | Нет защиты, не держит нагрузку, нельзя масштабировать | Только разработка и тесты |
Flask + Gunicorn + Nginx | Похож на uWSGI, чуть проще, меньше фич | Меньше настроек, не все плагины uWSGI | Если нужен простой деплой без тонкой настройки |
Похожие решения и альтернативы
- Gunicorn — альтернатива uWSGI, проще, но чуть менее гибкий.
- wsgiref — встроенный сервер, только для тестов.
- Tornado — асинхронный сервер, если нужен WebSocket и высокая производительность.
- Nginx — стандарт де-факто для фронтенда.
- Caddy — альтернатива Nginx с автоматическим SSL.
Статистика и сравнение
- uWSGI — один из самых популярных серверов для Python-приложений (по данным WSGI servers).
- Nginx держит более 30% рынка веб-серверов (по данным Netcraft).
- uWSGI быстрее Gunicorn на 10-20% при большом количестве воркеров, но Gunicorn проще в настройке.
- uWSGI поддерживает плагины, Emperor mode (управление множеством приложений), hot reload без даунтайма.
Интересные факты и нестандартные способы
- uWSGI можно запускать не только для Python, но и для Ruby, Perl, PHP — если вдруг понадобится.
- Можно использовать Emperor mode для управления десятками приложений на одном сервере.
- uWSGI поддерживает автоматический reload при изменении файлов — удобно для CI/CD.
- Через uWSGI можно делать балансировку нагрузки между несколькими приложениями и даже серверами.
- Можно запускать uWSGI как systemd-сервис, чтобы он автоматически стартовал при перезагрузке.
Автоматизация и новые возможности
С такой связкой легко автоматизировать деплой через скрипты или CI/CD (например, GitHub Actions или GitLab CI). Можно писать скрипты для zero-downtime деплоя: выкатываешь новую версию, делаешь touch uwsgi.reload
— и всё обновляется без остановки сервиса. Через systemd можно мониторить состояние uWSGI, автоматически рестартить при падении, логировать ошибки.
Если нужно масштабировать — просто увеличиваешь количество воркеров в uwsgi.ini
или поднимаешь несколько инстансов на разных портах/сокетах, а Nginx сам балансирует нагрузку.
Выводы и рекомендации
- Если хочешь надёжный, быстрый и гибкий продакшн для Flask — ставь uWSGI + Nginx на Ubuntu 24.04.
- Не используй встроенный сервер Flask для продакшна — это путь к боли и страданиям.
- uWSGI даёт гибкость, масштабируемость и кучу фич для автоматизации и мониторинга.
- Nginx — идеальный фронтенд для проксирования и отдачи статики.
- Для простых случаев можно попробовать Gunicorn, но если нужен контроль и мощь — uWSGI вне конкуренции.
- Не забывай про автоматизацию: systemd, CI/CD, скрипты деплоя — всё это экономит время и нервы.
Если нужен сервер для экспериментов или продакшна — VPS или выделенный сервер — отличный старт. А дальше — только вперёд, к автоматизации и стабильности!
Официальные ссылки для изучения:
Если остались вопросы — смело спрашивай в комментариях или на Stack Overflow. Удачного деплоя!
В этой статье собрана информация и материалы из различных интернет-источников. Мы признаем и ценим работу всех оригинальных авторов, издателей и веб-сайтов. Несмотря на то, что были приложены все усилия для надлежащего указания исходного материала, любая непреднамеренная оплошность или упущение не являются нарушением авторских прав. Все упомянутые товарные знаки, логотипы и изображения являются собственностью соответствующих владельцев. Если вы считаете, что какой-либо контент, использованный в этой статье, нарушает ваши авторские права, немедленно свяжитесь с нами для рассмотрения и принятия оперативных мер.
Данная статья предназначена исключительно для ознакомительных и образовательных целей и не ущемляет права правообладателей. Если какой-либо материал, защищенный авторским правом, был использован без должного упоминания или с нарушением законов об авторском праве, это непреднамеренно, и мы исправим это незамедлительно после уведомления. Обратите внимание, что переиздание, распространение или воспроизведение части или всего содержимого в любой форме запрещено без письменного разрешения автора и владельца веб-сайта. Для получения разрешений или дополнительных запросов, пожалуйста, свяжитесь с нами.