Termux в роли мобильного CI/CD‑сервера: настройка Jenkins, GitLab Runner и Docker‑контейнеров на смартфоне

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

Ниже — рабочая последовательность настройки под Android с опорой на локальную сеть и привычные DevOps‑инструменты. Мы не будем рассматривать обход блокировок и использование VPN «для обхода».

Требования

Смартфон на Android с установленным Termux.
Доступ к Wi‑Fi или мобильной сети и стабильность подключения (для корректной работы Git‑webhooks/регистраций).
Android с поддержкой контейнеров. На практике проще всего использовать Docker внутри Termux через совместимый способ/пакет или альтернативный контейнерный движок в рамках доступных на вашей платформе решений.
Желательно постоянная зарядка/повышение автономности, потому что сборки потребляют ресурсы.

Если вы используете устройство как CI, учитывайте ограничения по памяти и CPU: оптимизируйте образы и ограничивайте параллелизм.

Обновление базы и подготовка Termux

Начнем с обновления пакетов в Termux.

pkg update -y && pkg upgrade -y

Далее установим базовые инструменты: Git, curl, OpenSSH (для удаленного доступа), JDK (если потребуется для Jenkins), а также утилиты для работы с окружением.

pkg install -y git curl wget openssh nano procps net-tools

Jenkins требует Java. Поставим JDK.

pkg install -y openjdk-17

Проверьте версию Java:

java -version

Если TERMUX не видит Java по PATH, обычно помогает переопределение PATH в профиле. Но чаще все уже корректно.

Развертывание Docker‑контейнеров на смартфоне

Важный момент: наличие и способ запуска Docker в Termux может зависеть от версии Android, архитектуры и выбранного пути. В рамках статьи мы покажем базовую схему: подготовить окружение, проверить доступность демона, собрать тестовый образ и запустить контейнер.

Начните с проверки, доступен ли docker:

docker --version

Если команда не найдена, потребуется дополнительная установка/настройка контейнерного стека под ваше устройство. На практике это может быть не «просто apt‑install», а отдельная интеграция. Ваша задача — добиться рабочего состояния команды docker ps.

Когда Docker доступен, проверьте демон:

docker info

Запустим тестовый контейнер:

docker run --rm hello-world

Дальше подготовьте рабочую директорию под образы и volume для артефактов. Пример:

mkdir -p ~/ci/docker-volumes/{jenkins,gitlab-runner}

Договоритесь о том, как хранить артефакты: либо на файловой системе Termux в каталогах, либо в Docker volumes (для упрощения жизненного цикла контейнеров).

Сеть: доступ к CI с других устройств

Чтобы вы могли заходить в Jenkins и GitLab Runner должен видеть GitLab, настройте адресацию в локальной сети.

Определите IP смартфона в локальной сети:

ip addr

Или проще:

ip route | grep -Eo 'src [0-9.]+' | awk '{print $2}'

Предпочтительно использовать статический IP через роутер (DHCP reservation). Тогда URL Jenkins не будет меняться.

Откройте порты на смартфоне (в Android это зависит от сетевых ограничений, но в терминах Termux обычно достаточно корректной маршрутизации). Jenkins чаще всего слушает 8080, а HTTP‑агенты — в рамках настроек контейнеров.

Jenkins на Termux: запуск и привязка к каталогу

Существует два подхода: Jenkins как отдельный процесс Java в Termux или Jenkins как Docker‑контейнер. Для CI‑сценария практичнее контейнер: проще обновления и чистая фиксация окружения.

Вариант для Docker: создадим директорию для данных и запустим Jenkins контейнер. Ниже пример с пробросом портов. Замените <YOUR_IP_OR_HOST> только при необходимости (обычно проброс публикуется на локальный интерфейс, но конкретная реализация зависит от окружения).

mkdir -p ~/ci/jenkins_home

docker run -d --name jenkins-mobile 
-p 8080:8080 -p 50000:50000 
-v ~/ci/jenkins_home:/var/jenkins_home 
-e JAVA_OPTS="-Djenkins.install.runSetupWizard=false" 
jenkins/jenkins:lts

Проверьте, что контейнер живет:

docker ps

Откройте в браузере с компьютера или другого устройства:

http://<IP_смартфона>:8080

При первом запуске потребуется мастер‑ключ Jenkins. Его можно получить из лога контейнера:

docker logs jenkins-mobile | tail -n 50

После первичной настройки отключите анонимный доступ и настройте авторизацию.

Настройка Jenkins: агенты, креды и публикация артефактов

Для смартфон‑CI важно не раздувать окружение. Рекомендуемый подход:

Хранить Jenkins jobs с минимальными зависимостями.
Передавать сборки в контейнеры (если вы используете Docker на том же хосте).
Ограничивать параллельность.

Создайте креды для Git (HTTPS или SSH). В Jenkins: Manage Jenkins > Credentials. Добавьте ключ/токен.

Для публикации артефактов: используйте archiving (в Jenkinsfile) или копируйте в том/каталог на Docker host (Termux filesystem). Это обеспечит сохранность между перезапусками.

GitLab Runner: регистрация на смартфоне

GitLab Runner может работать как отдельный контейнер. Главная цель — чтобы runner мог выполнять job’ы через executor (например, docker).

Сначала создадим конфиг и структуру:

mkdir -p ~/ci/gitlab-runner/{config,certs}

Запустите GitLab Runner контейнер. Для получения токена регистрации потребуется ваш URL GitLab и registration token.

Запросите токен в GitLab: Settings > CI/CD > Runners > New project runner или Instance runners.

docker run -d --name gitlab-runner-mobile 
-v ~/ci/gitlab-runner/config:/etc/gitlab-runner 
-v /var/run/docker.sock:/var/run/docker.sock 
gitlab/gitlab-runner:alpine

Далее зайдите внутрь контейнера и выполните регистрацию. Примерные команды:

docker exec -it gitlab-runner-mobile sh

Внутри контейнера выполните:

gitlab-runner register

Понадобятся параметры:

CI coordinator URL — ваш GitLab URL, например https://gitlab.example.com/.
Registration token — токен из GitLab.
Description — например termux-mobile-runner.
Tags — теги, чтобы направлять job’ы на этот runner.
Executor — выберите docker (если вы используете Docker executor).

Если runner спрашивает параметры Docker, убедитесь, что он видит /var/run/docker.sock (мы примонтировали его выше). Для CI через контейнеры это ключевой шаг.

Пример .gitlab-ci.yml: сборка в Docker‑образе

Пример пайплайна, где job запускается на runner’е с нужными тегами и использует Docker‑образ как среду.

stages:
  - build

build:
  stage: build
  tags:
    - termux
  image: docker:27.0.3
  services:
    - name: docker:27.0.3-dind
      command: ["--mtu=1460"]
  script:
    - docker version
    - echo "Build step on mobile runner"

На мобильном устройстве следите за дист‑слоями и размером образов: кэшируйте зависимости и не используйте лишние сервисы без необходимости.

Локальная «цепочка» запуска: как увязать Jenkins и GitLab Runner

Практически удобный подход:

Jenkins может заниматься сборками там, где нужны более сложные сценарии или интеграции.
GitLab Runner исполняет jobs, определенные в .gitlab-ci.yml.

При необходимости вы можете:

Настроить Jenkins job, который триггерит GitLab pipeline (через API токены).
Или наоборот: GitLab pipeline может вызывать Jenkins endpoint для специфичных этапов.

Оба варианта требуют аккуратной настройки авторизации и защиты токенов.

Автозапуск контейнеров после перезагрузки

Termux и Android процессы могут завершаться. Для надежности используйте механизмы автозапуска уровня Android/Termux (в зависимости от устройства). На стороне командной части подготовьте сценарий старта.

Пример скрипта ~/ci/start-ci.sh (подготовьте его в Termux):

#!/data/data/com.termux/files/usr/bin/bash
set -e

# Jenkins
docker start jenkins-mobile 2>/dev/null || true

# GitLab Runner
docker start gitlab-runner-mobile 2>/dev/null || true

# Проверка
docker ps

Сделайте исполняемым:

chmod +x ~/ci/start-ci.sh

Далее настройте автозапуск через возможности Termux (например, в приложении Termux есть интеграции с tasker/службами) или системный «разрешенный запуск при старте».

Безопасность: базовые практики

Закройте Jenkins от интернета, оставив доступ только в локальной сети (в идеале — подсеть).
Отключите анонимного пользователя и используйте HTTPS там, где возможно на стороне GitLab/внешнего доступа.
Храните токены в Jenkins Credentials и в GitLab Runner конфиге с правами доступа.
Ограничивайте права контейнеров: не запускайте все с привилегиями, если они не нужны.

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

Устойчивость: ресурсы, логи, диагностика

На смартфоне CI важна наблюдаемость:

Логи Jenkins: docker logs jenkins-mobile -f.
Логи runner: docker logs gitlab-runner-mobile -f.
Проверьте состояние контейнеров: docker ps.
При проблемах с сетью — сравните IP/маршруты.

Память: если Jenkins или контейнеры падают из‑за OOM, уменьшайте объем parallel builds, ограничивайте используемые образы и настраивайте swap/ограничения в рамках возможностей Android.

Типовые проблемы и быстрые исправления

Jenkins не открывается с других устройств: проверьте IP смартфона, доступность порта 8080 и корректность сети.
Runner не выполняет job: в GitLab проверьте теги runner’а и статус (active), затем консоль runner контейнера.
Docker executor не работает: убедитесь, что runner имеет доступ к /var/run/docker.sock и Docker демон доступен.
Сборки слишком медленные: уменьшайте размер образов, избегайте лишних сервисов и используйте кеши.

Заключение

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

Если хотите быстро и без «ручного героизма» спроектировать такую систему под ваши задачи (архитектура, безопасность, тюнинг, пайплайны и контейнеры), обращайтесь в РыбинскЛАБ — поможем с внедрением и настройкой мобильного CI/CD.