Docker‑контейнеры в Termux: установка, настройка и управление многокомпонентными микросервисами через Docker Compose

Termux — один из самых удобных способов запускать серверные задачи прямо с Android-устройства: от утилит командной строки до полноценных сервисов. Когда же проект превращается в набор микросервисов, становится критически важно управлять несколькими компонентами согласованно — сетью, зависимостями, конфигурациями и жизненным циклом сервисов. В этом случае на первый план выходит Docker Compose.

В данной статье мы рассмотрим практический подход к запуску Docker‑контейнеров в Termux и организации многокомпонентных микросервисов через Docker Compose. Акцент будет на управляемости, предсказуемости и корректной настройке сетевого взаимодействия между сервисами.

Важно: в Termux классический Docker как на Linux-сервере обычно требует дополнительных условий и может зависеть от архитектуры устройства и доступности компонентов ядра. Поэтому мы рассмотрим рабочую схему, которая на практике используется: запуск Docker‑совместимых контейнеров в Termux через контейнерный движок (например, podman) либо через доступный Docker-совместимый вариант. В рамках статьи вы получите понятный план, а конкретный выбор движка под вашу конфигурацию — сможете подтвердить по доступным пакетам/релизам в вашей среде.

Что потребуется

Android-устройство с установленным Termux
Доступ к интернету для скачивания пакетов
Достаточно места на диске (образы и тома могут занимать заметно)
Возможность запускать контейнерный движок в окружении Termux

Подготовка Termux

Сначала обновим пакеты и установим базовые инструменты. Выполните:

pkg update && pkg upgrade -y

pkg install -y proot tar wget curl git nano ca-certificates

Дальше создадим рабочую директорию для проекта микросервисов:

mkdir -p ~/lab-microservices && cd ~/lab-microservices

Установка контейнерного движка и Docker Compose

Поскольку реальная доступность Docker может отличаться, корректнее ориентироваться на Docker‑совместимые варианты и доступные пакеты в Termux. На практике часто используют podman (Docker‑совместимый по подходу) и отдельно ставят Compose-клиент.

Проверьте, какие варианты доступны в вашем окружении:

pkg search podman

pkg search docker

Если в вашем окружении доступен podman, установите его:

pkg install -y podman

Далее установим Docker Compose. В зависимости от текущего состояния репозиториев Termux удобнее поставить Compose как отдельный бинарник либо через пакет. Попробуйте вариант с пакетами:

pkg search compose

Если Compose не находится как пакет, установите бинарник из официального релиза Docker Compose (версию подберите по текущей стабильной ветке):

ARCH="arm64" # при необходимости уточните архитектуру устройства

VERSION="v2.27.0" # пример; подберите актуальную стабильную версию

wget -O docker-compose https://github.com/docker/compose/releases/download/${VERSION}/docker-compose-linux-${ARCH}

chmod +x docker-compose

mkdir -p ~/.local/bin && mv docker-compose ~/.local/bin/

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc

source ~/.bashrc

Проверьте:

docker-compose version || docker compose version

Если у вас установлен именно podman, то команда Compose может требовать настройки интеграции. Самый надежный путь — использовать Compose в связке с Docker‑совместимым API/окружением либо запускать Compose так, чтобы он создавал контейнеры через подлежащий движок. Далее мы покажем универсальную структуру проекта и проверяемость сервисов.

Создание структуры проекта

Для микросервисов удобно выделить отдельные папки под конфигурации. Например:

mkdir -p ~/lab-microservices/app

mkdir -p ~/lab-microservices/nginx

mkdir -p ~/lab-microservices/db

Создадим docker-compose.yml в корне проекта:

nano ~/lab-microservices/docker-compose.yml

Пример: многокомпонентный стек (web + api + db)

Ниже пример стека из трех сервисов:

db — хранилище данных (например, PostgreSQL)
api — приложение, обращающееся к БД
web — прокси/фронтенд (например, Nginx)

Пример конфигурации docker-compose.yml:

version: "3.9"

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: lab
      POSTGRES_PASSWORD: labpass
      POSTGRES_DB: labdb
    volumes:
      - db_data:/var/lib/postgresql/data
    networks:
      - labnet

  api:
    image: python:3.12-slim
    working_dir: /srv
    command: "sh -c 'pip install --no-cache-dir flask psycopg[binary] && python -u app.py'"
    volumes:
      - ./app:/srv
    environment:
      DATABASE_URL: "postgresql+psycopg://lab:labpass@db:5432/labdb"
    depends_on:
      - db
    ports:
      - "8000:8000"
    networks:
      - labnet

  web:
    image: nginx:1.27-alpine
    volumes:
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
    ports:
      - "8080:80"
    depends_on:
      - api
    networks:
      - labnet

networks:
  labnet:
    driver: bridge

volumes:
  db_data:

Создадим приложение Flask для сервиса api. Файл ~/lab-microservices/app/app.py:

nano ~/lab-microservices/app/app.py

import os
from flask import Flask
import psycopg

app = Flask(name)

@app.get("/")
def index():
    return "API OK", 200

@app.get("/health")
def health():
    db_url = os.environ.get("DATABASE_URL")
    try:
        conn = psycopg.connect(db_url)
        cur = conn.cursor()
        cur.execute("SELECT 1")
        res = cur.fetchone()
        cur.close()
        conn.close()
        return {"db": res[0]}, 200
    except Exception as e:
        return {"error": str(e)}, 500

@app.run(host="0.0.0.0", port=8000)

Создадим конфигурацию Nginx, чтобы проксировать запросы на API. Файл ~/lab-microservices/nginx/default.conf:

nano ~/lab-microservices/nginx/default.conf

server {
  listen 80;

  location / {
    proxy_pass http://api:8000/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

Пояснение: внутри общей сети Compose контейнеры видят друг друга по именам сервисов (db, api, web) благодаря встроенному DNS Compose.

Запуск стека через Docker Compose

Перейдите в каталог проекта и запустите сервисы:

cd ~/lab-microservices

docker-compose up -d

Проверка логов:

docker-compose logs -f --tail=200

Статус контейнеров:

docker-compose ps

Остановка:

docker-compose down

Остановка с удалением томов БД (осторожно — удалятся данные):

docker-compose down -v

Настройка сети и имен сервисов

Секция networks в примере задает отдельную виртуальную сеть labnet. Это дает два важных эффекта:

контейнеры из стека изолированы от других контейнеров/сетей
службы адресуются по стабильным именам (например, db)

Если вы планируете подключать внешний сервис или прокидывать порты, используйте ports. Например, "8080:80" открывает веб на локальном порту 8080.

Практика управления: обновление конфигураций и образов

Обновить образы и пересоздать сервисы:

docker-compose pull

docker-compose up -d --force-recreate

Сбросить только измененный сервис: (например, nginx/web):

docker-compose up -d --no-deps web

Если вы меняете код приложения, но сервис api использует bind-mount ./app:/srv, то перезапуск контейнера обычно не требуется для заметных изменений при корректной настройке перезагрузки. Тем не менее, в простом варианте с Flask часто удобнее сделать:

docker-compose restart api

Сценарий: работа с локальным VPN для развертывания на одной сети (без обхода блокировок)

Если вам нужно, чтобы другие устройства в вашей локальной сети видели сервисы с Termux (например, доступ к 8080 или 8000), можно организовать связь через локальный VPN или overlay-сеть. В таком случае контейнеры продолжают общаться внутри Compose-сети, а доступ с внешних устройств обеспечивается только маршрутизацией/сетевым доступом со стороны Termux. Это помогает тестировать микросервисы без публикации в публичный интернет.

Конкретная настройка VPN зависит от выбранного решения; главное правило — не использовать такие механизмы для обхода блокировок, а применять только для формирования локальной сети и тестовой связности.

Типичные проблемы и как их диагностировать

1) Контейнер не стартует

Сначала посмотрите логи:

docker-compose logs --tail=200 <service_name>

Затем проверьте переменные окружения и монтирование томов (особенно для БД).

2) Не работает подключение между сервисами

В 95% случаев причина — неверное имя хоста или отсутствие сети. Убедитесь, что оба сервиса находятся в одной сети labnet и обращение идет к имени сервиса из Compose (например, db вместо localhost).

3) Порты не доступны

Проверьте, что сервис опубликован портом, и что на Android нет ограничений на входящий трафик. Команда:

docker-compose ps

Также полезно посмотреть, что контейнер реально слушает адреса 0.0.0.0. В примере Flask это уже сделано.

4) Архитектурные несоответствия образов

На некоторых устройствах образы могут не подходить по архитектуре. Тогда выбирайте совместимые теги образов или используйте легковесные образы, которые имеют нужные сборки. Для диагностики — смотрите логи старта контейнера.

Безопасность и практики эксплуатации

Не храните реальные пароли в docker-compose.yml на проде; для учебных стендов — допустимо, но лучше перейти на env-файлы или секреты.
Ограничивайте порты: публикуйте наружу только то, что нужно (например, web/8080), а внутренние сервисы держите без ports.
Используйте volume для БД, чтобы переживать перезапуски контейнера.
Регулярно обновляйте образы (docker-compose pull) и документируйте версию compose/образов.

Заключение

Docker‑контейнеры в Termux — реальная и практичная платформа для экспериментов и развертывания учебных микросервисных стеков. Главное преимущество Docker Compose — предсказуемая оркестрация: сеть между сервисами, зависимости, параметры и жизненный цикл контейнеров описываются в одном файле. Следуя приведенной схеме (движок контейнеров, Compose-клиент, сеть labnet, корректные имена хостов и хранение данных в volume), вы сможете быстро собрать надежный много-компонентный стенд.

Если хотите, чтобы ваш стенд на Termux был собран «под ключ», с корректной архитектурой, настройками сети и шаблонами Compose под вашу задачу — обращайтесь в РыбинскЛАБ. Мы поможем спроектировать и развернуть микросервисы так, чтобы ими было удобно пользоваться и развивать.