Termux как кросс‑платформенный CI/CD‑агент: настройка GitLab Runner и автоматическое развертывание контейнеров

Termux давно перестал быть просто «терминалом на телефоне»: при правильной организации его можно использовать как кросс‑платформенный CI/CD‑агент. В этой статье показан практический сценарий для GitLab CI/CD: запускаем GitLab Runner в Termux, принимаем задания от GitLab и выполняем сборку/проверки, а затем автоматически разворачиваем контейнеры (Docker/Podman) в целевой среде.

Материал ориентирован на легальные и безопасные практики в рамках инфраструктуры заказчика: без обхода блокировок и без «скрытых» методов доступа. При необходимости мы рассмотрим создание локальной сети для подключения к хосту развертывания (VPN — только для локального сегмента).

Предпосылки и требования

Вам понадобятся:

• Устройство с Android и установленным Termux.
• Доступ к GitLab (URL инстанса, токен проекта или группы).
• Целевой хост для развертывания контейнеров (например, сервер с Docker/Podman), доступный из сети.
• Git и базовые инструменты сборки (в зависимости от проекта).
• Учетные данные, необходимые для публикации артефактов/образов (registry, SSH, переменные окружения).

Рекомендуемая архитектура:

• Termux выступает как runner для задач CI/CD.
• Контейнеры разворачиваются на заранее подготовленном хосте (или в том же хосте, если вы разворачиваете локально).
• Конфигурация pipeline хранится в репозитории в файле .gitlab-ci.yml.

Шаг 1. Подготовка Termux

Начнем с обновления пакетов и установки базовых зависимостей. В Termux откройте терминал и выполните:

pkg update && pkg upgrade -y

pkg install -y git curl ca-certificates gnupg

Дальше установим средства для работы с контейнерами (в зависимости от выбранного подхода). Есть два распространенных варианта:

• Runner выполняет сборку/скрипты, а контейнеры развертываются на удаленном хосте по SSH.
• Runner запускает сборку образов прямо в Termux (если используется совместимая среда/движок контейнеров, например через внешние механизмы). На практике чаще выбирают первый вариант: проще, предсказуемее и безопаснее.

Для большинства корпоративных сценариев достаточно подготовить SSH-клиент и инструменты для управления артефактами:

pkg install -y openssh-client jq

Если планируете собирать контейнеры на удаленном хосте, то на Termux нужны только инструменты для доставки команд (SSH) и публикации образов (если это делает CI).

Шаг 2. Установка GitLab Runner в Termux

Runner для GitLab обычно поставляется как отдельный бинарник. На Android нативно «как на сервере» он может не быть доступен в стандартных репозиториях, поэтому универсальный способ — скачать подходящий бинарник и настроить пользователя/сервис.

Если у вас есть ограничения по архитектуре, подбирайте соответствующий бинарник. Общая логика такая:

mkdir -p ~/gitlab-runner && cd ~/gitlab-runner

Далее скачайте GitLab Runner для Linux/ARM/ARM64 (под вашу платформу) из официального источника GitLab. В примерах ниже команда показана как шаблон; замените URL/имя файла согласно релизу.

curl -L -o gitlab-runner <СЮДА_URL_БИНАРНИКА>

chmod +x gitlab-runner

Проверьте, что бинарник запускается:

./gitlab-runner --version

Создайте конфигурационный файл регистрации (обычно он формируется командой register).

Шаг 3. Регистрация runner в GitLab

Регистрируем runner из Termux. Команда регистрации запускает интерактивный мастер, где нужно указать URL GitLab, токен, описание, теги и исполнителя.

Пример запуска:

./gitlab-runner register

В процессе заполните:

• GitLab instance URL — например, https://gitlab.example.com/.
• Registration token — из настроек GitLab (Project/Group → Settings → CI/CD → Runners).
• Description — например, termux-android-ci.
• Tags — например, termux, чтобы ограничить, какие job’ы будут выполняться на этом runner.
• Executor — для Termux чаще выбирают shell (runner будет исполнять скрипты в рабочей директории). В некоторых инфраструктурах используется docker‑executor, но для Termux это менее типично.

Результат регистрации — файл конфигурации, обычно config.toml. Разместите его там, где runner его ожидает, либо укажите путь через --config.

Пример запуска runner после регистрации:

./gitlab-runner run

На практике удобно запускать runner в фоне. В Android это может требовать дополнительных механизмов (например, запуска по активности/сессии). Для производственного использования чаще организуют стабильный хост, а Termux — как «гибкий» агент для небольших задач. Однако если вам нужен именно вариант с Termux, можно настроить контролируемый запуск и мониторинг.

Шаг 4. Настройка окружения для job’ов

Чтобы pipeline работал предсказуемо, задайте минимальный набор переменных и зависимостей в репозитории. В .gitlab-ci.yml можно выбрать базовые образы для сборки, но при executor=shell в Termux вы будете зависеть от установленных инструментов в Termux.

Рекомендации:

• Ставьте нужные утилиты заранее в Termux (curl, jq, ssh, git).
• В job’ах используйте before_script для подготовки (например, настройка SSH known_hosts).
• Передавайте секреты через CI/CD variables в GitLab (не храните пароли в репозитории).

Шаг 5. Подготовка удаленного хоста для развертывания контейнеров

Далее рассмотрим безопасный способ: Termux выполняет job, который:

1. собирает/проверяет проект;
2. публикует образ в registry (по желанию) или формирует артефакт;
3. подключается к хосту развертывания по SSH;
4. выполняет обновление контейнеров (docker compose / docker run / kubectl — в зависимости от вашей системы).

Для SSH доступно использовать пару ключей. В GitLab создайте переменные:

• DEPLOY_HOST — IP/hostname целевого хоста;
• DEPLOY_USER — пользователь на хосте;
• DEPLOY_SSH_KEY — приватный ключ;
• DEPLOY_PORT — порт (по умолчанию 22).

На хосте заранее подготовьте:

• Docker/Podman;
• папку проекта;
• файл docker-compose.yml или скрипт деплоя;

Шаг 6. VPN (только для локальной сети)

Если хост развертывания находится не в той же сети и прямой доступ по IP невозможен, можно создать локальную сеть через VPN (без попыток обхода блокировок): например, связать устройства в один приватный сегмент, чтобы Termux мог обращаться к хосту по SSH.

Далее в SSH укажите доступный адрес хоста из этой локальной сети.

Шаг 7. Пример .gitlab-ci.yml: проверка и деплой контейнеров

Ниже пример пайплайна с двумя стадиями: build и deploy. В данном примере контейнеры обновляются на удаленном хосте через SSH и docker compose. Подставьте свои команды сборки и имена сервисов.

stages:
  - build
  - deploy

variables:
  DEPLOY_PORT: "22"

before_script:
  - 'command -v ssh-agent >/dev/null || (apt-get update && apt-get install -y openssh-client) || true'
  - 'mkdir -p ~/.ssh'
  - 'chmod 700 ~/.ssh'
  - 'eval "$(ssh-agent -s)"'
  - 'echo "$DEPLOY_SSH_KEY" | tr -d "
" | ssh-add -'
  - 'chmod 600 ~/.ssh/* || true'

build:
  stage: build
  tags:
    - termux
  script:
    - git version
    - jq --version || true
    - echo "Сборка/проверки выполняются на Termux runner"
    - echo "Здесь добавьте вашу логику: сборка, тесты, генерация артефактов"
    - mkdir -p build-artifacts
    - echo "ok" > build-artifacts/status.txt
  artifacts:
    when: always
    paths:
      - build-artifacts/

deploy:
  stage: deploy
  tags:
    - termux
  needs: ["build"]
  only:
    - main
  script:
    - echo "Деплой на удаленный хост"
    - 'ssh -p "$DEPLOY_PORT" -o StrictHostKeyChecking=no "$DEPLOY_USER@$DEPLOY_HOST" "mkdir -p ~/apps/myapp"'
    - 'scp -P "$DEPLOY_PORT" build-artifacts/status.txt "$DEPLOY_USER@$DEPLOY_HOST:~/apps/myapp/status.txt"'
    - 'ssh -p "$DEPLOY_PORT" -o StrictHostKeyChecking=no "$DEPLOY_USER@$DEPLOY_HOST" "cd ~/apps/myapp && ./deploy.sh"'

На хосте создайте deploy.sh (или используйте docker compose напрямую). Пример скрипта деплоя:

#!/usr/bin/env bash
set -euo pipefail

# Логика обновления контейнеров.
# Здесь может быть pull образа, перезапуск compose и т.п.

# Пример:
# docker compose -f docker-compose.yml pull
# docker compose -f docker-compose.yml up -d --remove-orphans

echo "Контейнеры обновлены (шаблон deploy.sh)"

Важно: в реальной системе deploy.sh должен использовать ваши реальные команды (pull образов из registry, обновление тегов, миграции БД и т.д.). Триггер «main → deploy» часто делают через правила GitLab.

Шаг 8. Работа с образами контейнеров и registry

Если в pipeline вы хотите собирать Docker-образ и публиковать в registry, обычно используют один из подходов:

• Сборка образа выполняется на хосте (а Termux только доставляет конфигурацию/версию).
• Сборка выполняется в CI среде, а Termux лишь запускает job с необходимыми инструментами (что может быть сложно на Android).

На практике с Termux наиболее надежно сделать так: runner запускает тесты/валидации, а деплой выполняется на сервере, который уже умеет собирать/пулить образы.

Если все же требуется публикация из GitLab CI, используйте переменные GitLab для логина в registry и подставляйте креды через CI/CD Variables. Не храните токены в репозитории.

Шаг 9. Теги, ограничения и изоляция job’ов

Чтобы Termux runner выполнял только нужные задачи:

• в runner registration добавьте теги, например termux;
• в каждом job указывайте tags: с нужным значением;
• разделяйте тяжелые задачи (например, сборка больших проектов) на отдельные runner’ы.

Так вы предотвратите «случайный» прогон неподходящих job’ов на Android‑агенте.

Шаг 10. Надежность: кэш, таймауты и диагностика

Для улучшения стабильности:

• Используйте timeout на job’ах (чтобы не зависать при сетевых ошибках).
• Добавляйте понятные логи (echo и вывод версий инструментов).
• Включайте артефакты для диагностики (логи тестов, отчеты линтеров).
• При необходимости добавьте cache (зависит от типа проекта).

Пример добавления таймаута:

deploy:
  stage: deploy
  tags: ["termux"]
  timeout: 15m
  script:
    - echo "Start deploy"

Заключение

Termux можно использовать как кросс‑платформенный CI/CD‑агент для GitLab, если корректно зарегистрировать GitLab Runner, аккуратно подготовить окружение и выстроить безопасную схему деплоя контейнеров на целевой хост. Такой подход удобен для гибких задач, автоматизации проверок и оперативного обновления сервисов — при сохранении управляемости и предсказуемости инфраструктуры.

Если вы хотите быстро и надежно внедрить этот сценарий у себя (под ваш GitLab, ваши контейнеры и схему доступа), обратитесь в РыбинскЛАБ: мы поможем спроектировать пайплайн, настроить Runner и деплой, а также подготовить документацию и сопровождение.