Разработка и деплой микросервисов на базе FastAPI в Termux с автоскейлингом через AWS Fargate и Google Cloud Run

Разработка микросервисов на FastAPI в Termux возможна и практична: вы можете писать код, запускать сервисы локально, тестировать API и готовить контейнеры к публикации в облака. В этом материале покажу типовой производственный подход: как выстроить рабочий цикл «на телефоне» (Termux) и затем развернуть сервисы в AWS Fargate и Google Cloud Run с автоскейлингом.

Фокус статьи — архитектура и инженерная дисциплина: одинаковая структура проекта, воспроизводимые сборки Docker-образов, управляемые переменные окружения, корректная обработка логов и масштабирование.

Целевая архитектура

Рассмотрим простой микросервис (например, «users»), который принимает запросы по HTTP. В основе — FastAPI. Далее сервис контейнеризируется и деплоится в:

AWS Fargate: запуск контейнеров в ECS с автоматическим масштабированием (через ECS Service Auto Scaling и/или Target Tracking).
Google Cloud Run: управляемый серверлесс платформой, масштабируется автоматически по входящему трафику (concurrency и автомасштабирование).

Такой подход снижает «разрыв» между разработкой и продакшеном: вы в Termux готовите образ, а облако исполняет его в согласованной среде.

Подготовка Termux: окружение для разработки

Начните с установки базовых инструментов. Термукс предоставляет доступ к Linux-подобной среде, но важно помнить: контейнеры обычно удобнее собирать через Docker на ПК. Если Docker в Termux не является вашим целевым инструментом, вы можете:

разрабатывать и тестировать FastAPI локально в Termux;
готовить файлы проекта (Dockerfile, requirements, настройки);
производить сборку образов и деплой с помощью CI/CD или с внешней машины.

Ниже — вариант, когда Termux используется как рабочая среда для кода, а сборка/публикация образа — через Docker build на стороне сборочного узла.

Установим Python и инструменты.

pkg update -y
pkg install -y python git

Далее создайте рабочую директорию и виртуальное окружение.

mkdir -p ~/fastapi-microservice
cd ~/fastapi-microservice
python -m venv .venv
source .venv/bin/activate

Скелет проекта FastAPI

Стандартная структура, которая хорошо ложится на контейнеризацию и деплой:

fastapi-microservice/
  app/
    init.py
    main.py
    settings.py
  requirements.txt
  Dockerfile
  README.md

Установите зависимости.

pip install fastapi uvicorn[standard] pydantic-settings

Сохраните список зависимостей в requirements.txt.

pip freeze > requirements.txt

Реализация микросервиса FastAPI

Создайте настройки окружения (для параметров сервиса и портов).

mkdir -p app
touch app/init.py app/settings.py app/main.py

app/settings.py:

from pydantic_settings import BaseSettings

class Settings(BaseSettings):
    app_name: str = "users-service"
    environment: str = "local"
    port: int = 8000

settings = Settings()

app/main.py:

from fastapi import FastAPI
from app.settings import settings

app = FastAPI(title=settings.app_name)

@app.get("/health")
def health():
    return {
        "status": "ok",
        "service": settings.app_name,
        "env": settings.environment
    }

@app.get("/v1/users/{user_id}")
def get_user(user_id: int):
    # Заглушка. В реальной системе здесь будет доступ к БД/кэшу.
    return {
        "id": user_id,
        "name": "User " + str(user_id)
    }

Локальный запуск в Termux и проверка API

Запустите сервер:

uvicorn app.main:app --host 0.0.0.0 --port 8000

Проверьте endpointы. В зависимости от вашей сети может быть удобнее использовать curl внутри Termux.

curl -s http://127.0.0.1:8000/health

Если нужен доступ с другого устройства в локальной сети, корректный вариант — создание локальной сети через VPN/туннель только для локального обмена (не для обхода блокировок). Однако в рамках статьи не будем уходить в детали настройки сети — логика сервиса от этого не зависит.

Контейнеризация: Dockerfile для FastAPI

Подготовьте Dockerfile, чтобы запуск в AWS и GCP был консистентным.

touch Dockerfile

Dockerfile:

FROM python:3.12-slim

WORKDIR /app

# Установка зависимостей
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Копирование исходников
COPY app ./app

# Принцип: слушаем внешний порт (переменные окружения задаются при деплое)
ENV PORT=8000
EXPOSE 8000

CMD ["sh", "-c", "uvicorn app.main:app --host 0.0.0.0 --port ${PORT}"]

Сборка и публикация образа (рекомендуемый подход)

На практике удобнее и надежнее собирать Docker-образ не внутри Termux, а в CI/CD (GitHub Actions, GitLab CI, Jenkins) или на отдельной сборочной машине. Termux в этом случае остается средой для разработки и проверки.

Типовые шаги:

собрать образ: docker build;
пометить тегом (например, git sha);
запушить в registry (ECR для AWS или Artifact Registry/Container Registry для GCP);
вызвать деплой сервисов.

Для ясности приведу пример команды сборки (при наличии доступа к Docker на стороне сборщика):

docker build -t your-registry/fastapi-users:1.0.0 .

И публикация (пример):

docker push your-registry/fastapi-users:1.0.0

Деплой в AWS Fargate с автоскейлингом

В AWS вам нужно обеспечить:

контейнеризацию через ECS Task Definition;
сервис ECS (ECS Service);
автоскейлинг по метрикам (например, CPUUtilization или ALB RequestCountPerTarget).

Шаг 1. Подготовьте инфраструктуру: кластер ECS, роли, сеть (VPC), и желательно ALB (чтобы получать HTTP-трафик и метрики по запросам).

Шаг 2. Создайте Task Definition, указав образ, порт контейнера (8000) и переменные окружения (ENV).

В разделе настройки контейнера задайте port mapping: контейнерный порт 8000. Переменную PORT можно оставить 8000 или подстроить под требования.

Шаг 3. Создайте ECS Service с desired count (минимум/база) и включите Service Auto Scaling.

Пример принципа настройки (без привязки к конкретным GUI/CLI параметрам):

целевая метрика: CPU utilization (например, 50%)
или метрика нагрузки: requests per target через ALB
политика: масштабирование вверх при росте и вниз при снижении

Результат: когда FastAPI начинает получать больше запросов, ECS поднимает больше задач в Fargate, сохраняя SLA/производительность.

Деплой в Google Cloud Run с автоскейлингом

Google Cloud Run — один из самых удобных вариантов для FastAPI, потому что он:

масштабируется автоматически по входящему трафику;
не требует ручного управления числом инстансов;
работает со статическим контейнерным образом, как и в случае Fargate.

Шаг 1. Подготовьте образ и запушьте в подходящий registry GCP.

Шаг 2. Деплой на Cloud Run, задав:

image (контейнер)
region
environment variables (например, environment=prod)
port (если отличается; в нашем Dockerfile используется PORT и дефолт 8000)

Шаг 3. Настройте параметры автоскейлинга Cloud Run:

min instances — ноль или небольшое значение (опционально для снижения холодных стартов)
max instances — ограничение по верхней планке
concurrency — число одновременных запросов на один экземпляр

В Cloud Run автоскейлинг запускается автоматически при росте нагрузки и учитывает concurrency. Обычно для FastAPI оптимально начать с разумного concurrency (и тестировать под реальную нагрузку).

Переменные окружения, конфигурация и разделение сред

Чтобы сервис работал одинаково и в Termux, и в облаке, используйте единый механизм конфигурации.

В текущей реализации pydantic-settings читает параметры по умолчанию, но в облаке вы подставляете environment variables. Например:

environment=prod
app_name=users-service
PORT=8000

Это дает предсказуемость и упрощает сопровождение.

Логи, трассировки и отладка

И в Fargate, и в Cloud Run вам важно видеть логи контейнера.

FastAPI/uvicorn по умолчанию пишет логи в stdout/stderr.
В Fargate логи обычно направляются в CloudWatch (через конфигурацию log driver).
В Cloud Run логи автоматически агрегируются платформой и доступны через Cloud Logging.

Для практики добавляйте корреляцию (request id) при необходимости, но базовая связка «stdout logs» уже дает быстрый выигрыш на этапе эксплуатации.

CI/CD: привязка к версии и стабильность релизов

Чтобы автоскейлинг работал не только «в моменте», а надежно на протяжении релизов, нужен стабильный цикл сборки:

версионирование образа (тег по git sha или по semver);
отдельные шаги для теста (unit/integration);
продвижение образа из staging в prod.

Это особенно важно, когда вы параллельно поддерживаете деплой в двух облаках.

Практический checklist перед продакшеном

health endpoint (у вас есть /health) для проверок.
корректная настройка порта (PORT / EXPOSE / port mapping).
лимиты ресурсов (в Fargate) и разумная concurrency (в Cloud Run).
переменные окружения вынесены из кода.
обработка ошибок и понятные коды статусов HTTP.
наблюдаемость: логи и метрики.

Заключение

Разработка FastAPI в Termux отлично подходит для этапа написания и локальной проверки кода. Дальше контейнеризация через Dockerfile позволяет переносить один и тот же сервис в AWS Fargate и Google Cloud Run, а автоскейлинг берут на себя платформы: ECS Service Auto Scaling и собственная модель масштабирования Cloud Run по входящему трафику.

Если хотите ускорить путь от идеи до продакшена (архитектура, репозиторий, Docker, подготовка инфраструктуры, рекомендации по автоскейлингу и наблюдаемости), команда РыбинскЛАБ поможет с разработкой, внедрением и сопровождением решений под ваши задачи.