Полный стек разработки на Termux: настройка Nginx + uWSGI + Flask с поддержкой systemd‑сервисов

Termux удобен для разработки: быстрый старт, доступ к полноценному окружению Linux и гибкая настройка. Для производственного подхода (или близко к нему) часто нужен reverse proxy, изоляция процесса приложения и предсказуемый запуск. Поэтому соберём стек:

Nginx — будет принимать HTTP‑запросы и проксировать на uWSGI.
uWSGI — будет запускать Flask как WSGI‑приложение.
Systemd‑сервисы — чтобы процессы поднимались стабильно и управляемо.

В результате вы получите воспроизводимый дев‑стенд, который можно перезапускать командой systemctl/подобными инструментами и который меньше «ломается» при перезапусках Termux.

Предпосылки и оговорки по окружению

На Android systemd в классическом смысле не всегда доступен «из коробки». Обычно используют пакет proot‑based или deb‑chroot варианты либо включают поддержку systemd через совместимые решения. В этой статье предполагается, что на вашем Termux установлен работающий systemd‑совместимый механизм (например, через сторонний модуль/пакет, который размещает unit‑файлы и запускает демоны). Если systemd ещё не работает, сначала нужно включить/установить соответствующую возможность в вашем окружении.

Также учтите: порты на Android могут требовать маршрутизации через loopback и корректного binding’а к адресам. Мы будем слушать локальные интерфейсы и проксировать внутри устройства.

Установка зависимостей

Обновим репозиторий Termux и установим базовые пакеты. Начнём с Python, Nginx, необходимых библиотек и инструментов сборки uWSGI.

pkg update && pkg upgrade -y
pkg install -y python git curl nginx build-essential libffi-dev openssl-dev pkg-config

Далее поставим uWSGI зависимости и утилиты для работы с virtualenv и сборкой.

pkg install -y python-dev
pip install --upgrade pip setuptools wheel

Создание проекта Flask

Рекомендуется держать проект в каталоге внутри Termux (например, $HOME/dev).

mkdir -p $HOME/dev/flask-nginx-uwsgi
cd $HOME/dev/flask-nginx-uwsgi

Создадим виртуальное окружение и установим Flask и uWSGI.

python -m venv .venv
source .venv/bin/activate
pip install -U pip
pip install flask uwsgi

Сделаем минимальное WSGI‑приложение. Создайте файл app.py:

cat > app.py <<'EOF'
from flask import Flask
import os

app = Flask(name)

@app.get('/')
def index():
    return {
        'status': 'ok',
        'service': 'flask',
        'pid': os.getpid(),
    }

if name == 'main':
    app.run(host='127.0.0.1', port=8000, debug=True)
EOF

Проверим, что Flask запускается в режиме разработки (это не обязательная часть продакшн‑сценария, но помогает убедиться, что код рабочий).

python app.py

После проверки нажмите Ctrl+C, чтобы остановить сервер.

Настройка uWSGI

uWSGI будет запускать приложение Flask через WSGI entry point. Вариантов много; мы выберем простой конфиг с socket‑файлом (для проксирования Nginx по локальному сокету) или через TCP. На Android проще и надёжнее начать с локального TCP, но сокет тоже возможен. Рассмотрим TCP‑вариант — универсальнее.

Создадим конфиг uWSGI в uwsgi.ini:

cat > uwsgi.ini <<'EOF'
[uwsgi]
; WSGI module: app:app (файл app.py и объект app)
module = app:app

; Подключаем Python virtualenv
home = /data/data/com.termux/files/home/dev/flask-nginx-uwsgi/.venv

; Внутренний адрес, на котором слушает uWSGI
http-socket = 127.0.0.1:8001

; Процессы/воркеры
master = true
processes = 2
threads = 2

; Чистый старт/останов
vacuum = true
die-on-term = true

; Логи
logto = /data/data/com.termux/files/home/dev/flask-nginx-uwsgi/uwsgi.log
log-reopen = true

; Безопасность: запретить изменения прав исполняемых файлов (по желанию)
; chmod-socket = 660
EOF

Важно: путь в директиве home должен соответствовать вашему actual‑пути Termux. Обычно базовый путь — /data/data/com.termux/files/home, но при переносах нужно поправить. Проверьте переменные и при необходимости замените на ваш путь:

echo $HOME

Если $HOME отличается, используйте именно его.

Убедимся, что uWSGI стартует:

./.venv/bin/uwsgi --ini uwsgi.ini

Откройте другой терминал и проверьте, что приложение отвечает:

curl -s http://127.0.0.1:8001/

После теста остановите uWSGI (в том терминале, где он запущен — Ctrl+C).

Настройка Nginx как reverse proxy

Теперь настроим Nginx так, чтобы он принимал запросы на порт 8080 (или 80, если вы понимаете последствия и у вас есть разрешения) и проксировал их на 127.0.0.1:8001.

Создадим конфиг nginx (в зависимости от сборки пути конфигов могут отличаться; типично Termux использует $PREFIX/etc/nginx).

Проверим, где лежит конфиг Nginx:

nginx -V 2>&1 | head -n 5
ls -la $PREFIX/etc/nginx

Далее создадим конфиг сервера. Например, так:

cat > $PREFIX/etc/nginx/conf.d/flask.conf <<'EOF'
server {
    listen 8080;
    server_name _;

    client_max_body_size 10m;

    location / {
        proxy_pass http://127.0.0.1:8001;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        ; WebSocket (на будущее, если понадобится)
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    access_log $PREFIX/var/log/nginx/flask_access.log;
    error_log  $PREFIX/var/log/nginx/flask_error.log;
}
EOF

Убедимся, что каталоги для логов существуют:

mkdir -p $PREFIX/var/log/nginx

Проверим конфигурацию Nginx и запустим вручную для теста:

nginx -t
nginx -g 'daemon off;'

В другом терминале проверим:

curl -s http://127.0.0.1:8080/

Остановите Nginx после теста (Ctrl+C).

systemd‑сервисы: uWSGI

Чтобы запуск был управляемым, создадим unit‑файл для uWSGI. Предположим, что systemd‑каталог для user‑units доступен как $HOME/.config/systemd/user или $HOME/.config/systemd/user в вашем окружении. Мы также дадим вариант для system‑level, если он разрешён.

Сначала определим, какой systemd‑путь у вас. Попробуйте:

ls -la ~/.config/systemd/user 2>/dev/null || true
ls -la $PREFIX/lib/systemd/system 2>/dev/null || true

Ориентируемся на user‑units: создадим файл uwsgi.service. Подставьте правильный путь к ini и исполняемому файлу uwsgi.

mkdir -p ~/.config/systemd/user
cat > ~/.config/systemd/user/uwsgi.service <<'EOF'
[Unit]
Description=uWSGI for Flask (Termux)
After=network.target

[Service]
Type=simple
WorkingDirectory=%h/dev/flask-nginx-uwsgi

; Запускем uwsgi из virtualenv
ExecStart=%h/dev/flask-nginx-uwsgi/.venv/bin/uwsgi --ini %h/dev/flask-nginx-uwsgi/uwsgi.ini

; Перезапуск при сбоях
Restart=always
RestartSec=2

; Ограничения по ресурсам (опционально)
; MemoryMax=256M

; environment можно добавить при необходимости
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=default.target
EOF

Перезагрузим daemon‑ы и включим сервис:

systemctl --user daemon-reload
systemctl --user enable --now uwsgi.service

Проверим статус:

systemctl --user status uwsgi.service --no-pager

И убедимся, что приложение доступно из Nginx‑контура:

curl -s http://127.0.0.1:8001/

systemd‑сервисы: Nginx

Теперь unit для Nginx. Мы хотим, чтобы Nginx поднимался после сети и после uWSGI (или хотя бы после того, как uWSGI доступен). Добавим зависимость по order.

cat > ~/.config/systemd/user/nginx.service <<'EOF'
[Unit]
Description=Nginx reverse proxy for Flask (Termux)
After=network.target uwsgi.service
Requires=uwsgi.service

[Service]
Type=simple
ExecStart=/data/data/com.termux/files/home/.local/bin/nginx -g 'daemon off;'

; Если ваш nginx расположен иначе, замените путь в ExecStart.
; Для проверки: which nginx
Restart=always
RestartSec=2

[Install]
WantedBy=default.target
EOF

Важно: проверьте путь к бинарнику nginx на вашем устройстве и при необходимости поправьте ExecStart.

which nginx
ls -la $(which nginx)

Если which nginx вернёт, например, /data/data/com.termux/files/usr/bin/nginx — замените ExecStart соответствующим путем.

Перезагрузим systemd и запустим:

systemctl --user daemon-reload
systemctl --user enable --now nginx.service
systemctl --user status nginx.service --no-pager

Тестируем внешний endpoint на 8080:

curl -s http://127.0.0.1:8080/

Если Nginx не стартует, смотрите логи. В Termux логи могут быть в $PREFIX/var/log/nginx, а также можно смотреть stdout/journal (если доступно):

ls -la $PREFIX/var/log/nginx

Доработка под разработку: статические файлы и настройки Flask

Если ваш Flask сервис будет отдавать статику, вы можете:

либо продолжать отдачу через Nginx (рекомендовано),
либо позволить Flask отдавать статику (обычно для дев‑среды).

Для Nginx добавьте отдельный location под директорию статики. Например, если статика в static/ внутри проекта:

location /static/ {
    alias %h/dev/flask-nginx-uwsgi/static/;
    expires 7d;
}

Добавьте нужный блок внутрь server‑конфига. После правок не забудьте перезагрузить Nginx:

systemctl --user restart nginx.service

Обслуживание и типовые проблемы

uWSGI не стартует

Проверьте путь до virtualenv в uwsgi.ini (директива home).
Проверьте права на файл логов uwsgi.log.
Посмотрите лог uWSGI: uwsgi.log.

Nginx отдаёт 502/504

Убедитесь, что uWSGI слушает на 127.0.0.1:8001.
Проверьте связку: curl http://127.0.0.1:8001/.
Убедитесь, что Nginx конфиг применён: nginx -t.

Неправильный путь к nginx в unit‑файле

Всегда проверяйте which nginx перед фиксацией ExecStart.
Если у вас пользовательские PATH отличаются, лучше использовать абсолютный путь.

Подключение из локальной сети (по желанию)

Если вам нужно открыть доступ к dev‑серверу на вашем устройстве с других устройств в локальной сети (для тестов на реальных девайсах), можно организовать локальную сеть через VPN‑приложение, которое создаёт локальное соединение. В таком случае вам всё равно потребуется, чтобы сервисы слушали правильные интерфейсы (например, 0.0.0.0 или IP устройства) и чтобы firewall/сетевая политика позволяла трафик внутри LAN.

Для базового сценария обычно достаточно заменить binding адреса в uWSGI и/или Nginx, но делайте это аккуратно и только для локального тестирования в вашей сети.

Заключение

Мы собрали полный стек разработки на Termux: Nginx как reverse proxy, uWSGI для запуска Flask‑приложения и systemd‑сервисы для стабильного автозапуска и управления. Такой подход делает дев‑среду предсказуемой и ближе к продакшн‑модели, а значит — меньше сюрпризов в процессе разработки.

Если хотите, чтобы мы помогли вам адаптировать конфиги под вашу конкретную версию Termux/systemd, подобрать оптимальные порты/интерфейсы, настроить логи и обеспечить автозапуск без ручных действий — обращайтесь в РыбинскЛАБ.