Развёртывание полноценного CI/CD пайплайна (GitLab Runner, Jenkins) прямо на Android‑устройстве с помощью Termux

Android — это не просто «терминал на ладони». Если правильно подойти к инфраструктуре, то при помощи Termux можно развернуть полноценный CI/CD-процесс: запуск сборок, тестов, артефактов и даже публикации результатов. На практике это удобно для прототипов, обучения и локальной отладки пайплайнов.

В этой статье рассмотрим сценарий, при котором Android-устройство выступает узлом для:

GitLab CI — через GitLab Runner;
Jenkins — как отдельный сервис;
контейнеризации — через Docker (в пределах возможностей вашей конфигурации);
персистентного хранения — чтобы данные не терялись после перезапуска.

Важно: ниже описываются легитимные сценарии использования Termux в рамках локального развёртывания и учебных задач. Никаких способов обхода ограничений и «скрытых» техник не рассматриваем.

Архитектура решения: что именно мы разворачиваем

На Android через Termux вы поднимаете окружение, в котором размещаются:

GitLab Runner — выполняет job’ы из GitLab CI.
Jenkins — выполняет Pipeline/Jobs и управляет стадиями сборки.
Сборочные шаги — обычно внутри контейнеров, чтобы окружение было воспроизводимым.
Переменные окружения — токены, пути, параметры сборки.

Рекомендованный подход — запускать Runner и Jenkins в контейнерах. Тогда CI/CD выглядит более «похоже на сервер», а окружения сборки не нужно каждый раз настраивать вручную.

Требования и подготовка Termux

Перед началом проверьте:

Android 8+ (чем выше версия, тем меньше проблем с контейнеризацией);
достаточно места на накопителе (лучше 10–20 ГБ+ под образы/логи/артефакты);
стабильный Wi‑Fi (CI/CD тяжело переносит разрывы сети);
доступ к интернету для скачивания образов/зависимостей (локальная сеть допускается, но исходники/образы часто всё равно нужно откуда-то получить).

Обновим базовые пакеты Termux:

pkg update -y
pkg upgrade -y

Установим базовые утилиты:

pkg install -y wget curl git ca-certificates openssh rsync

Далее подготовим хранилище и рабочие каталоги. Например:

mkdir -p $HOME/ci/{gitlab-runner,jenkins,data}
mkdir -p $HOME/ci/workspace

Docker в Termux: контейнерная база для Runner и Jenkins

Технически «Docker на Android» зависит от конкретной среды (магистральные варианты: контейнерный движок через сторонние компоненты, интеграции и особенности устройства). На практике чаще всего используют один из двух подходов:

Собственный контейнерный рантайм, совместимый с Docker-образами;
Либо запуск сервисов Jenkins/Runner без контейнеров (менее удобно, но проще для некоторых устройств).

Ниже приведу «контейнерный» вариант как целевой. Если у вас Docker не устанавливается из коробки — напишите, и я предложу альтернативу под вашу модель/версию Android.

Предположим, что Docker-окружение доступно. Уточните, что команда docker работает. Быстрая проверка:

docker version
docker info

Настройка GitLab Runner на Android

Есть два типичных подхода:

Runner как отдельный сервис (в контейнере);
Runner напрямую в Termux (без контейнера), но тогда шаги сборки сложнее изолировать.

В этой статье выберем контейнерный подход: так проще обеспечивать воспроизводимость job’ов.

1) Регистрация GitLab Runner

Сначала вам нужно иметь GitLab (самохост или облако) и проект/группу, где будет выполняться CI.

На стороне GitLab:

перейдите в Settings → CI/CD;
раздел Runners (или Specific runners);
создайте runner и получите registration token.

На стороне Android/Termux поднимем контейнер GitLab Runner и зарегистрируем его.

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

mkdir -p $HOME/ci/gitlab-runner/config

Запустим контейнер runner (примерно так; точные параметры зависят от вашей среды и доступности docker.sock). Для локального запуска на Android обычно лучше использовать bind-mount конфигов.

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

Дальше выполним команду регистрации внутри контейнера. Вам потребуются: URL вашего GitLab и registration token.

docker exec -it gitlab-runner gitlab-runner register 
  --non-interactive 
  --url <GITLAB_URL> 
  --registration-token <REGISTRATION_TOKEN> 
  --executor docker 
  --docker-image alpine:latest 
  --description "Android-Termux Runner" 
  --tag-list "android,termux" 
  --run-untagged="false" 
  --locked="false"

Если вам нужен доступ к приватным репозиториям — добавьте корректные токены/ключи уже в переменные окружения GitLab и/или настройте секреты для контейнера.

2) Плейсхолдер для docker executor: выбираем стратегию запуска job’ов

Для полноценного CI/CD на практике важно:

чтобы job’ы стартовали в Docker-образах;
чтобы кэш зависимости работал (Maven/NPM/Pip и т.п.);
чтобы артефакты сохранялись в GitLab.

Минимальный фрагмент .gitlab-ci.yml:

stages:
  - build
  - test

build:
  stage: build
  tags:
    - android
    - termux
  image: alpine:3.20
  script:
    - echo "Build on Android CI"
    - uname -a
  artifacts:
    when: always
    paths:
      - build-output/

test:
  stage: test
  tags:
    - android
    - termux
  image: alpine:3.20
  script:
    - echo "Run tests"
    - true

Здесь tags гарантируют, что job будет уходить на ваш Android Runner.

3) Персистентность и устойчивость к перезапускам

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

не «чистили» хранилище;
Runner не завершался из‑за нехватки ресурсов;
устройство не уходило в агрессивный сон (если это критично — настройте поведение энергосбережения в Android).

Развёртывание Jenkins на Android через Termux

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

Шаг 1) Подготовка каталогов для Jenkins

Создадим директории под данные Jenkins:

mkdir -p $HOME/ci/jenkins/data
mkdir -p $HOME/ci/jenkins/plugins

Шаг 2) Запуск контейнера Jenkins

Обычно Jenkins слушает 8080. На Android через сетевые интерфейсы это зависит от среды, но базовый пример такой:

docker run -d --name jenkins 
  -p 8080:8080 
  -v $HOME/ci/jenkins/data:/var/jenkins_home 
  -v $HOME/ci/jenkins/plugins:/var/jenkins_home/plugins 
  jenkins/jenkins:lts

Проверьте, что сервис поднялся:

docker ps
docker logs -f jenkins --tail 100

Шаг 3) Первичная настройка Jenkins

Jenkins выдаст initial admin password. Получить его можно из контейнера:

docker exec -it jenkins cat /var/jenkins_home/secrets/initialAdminPassword

Далее откройте интерфейс Jenkins в браузере по адресу устройства (в локальной сети).

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

Шаг 4) Создаём Pipeline, который выполняет сборки

Пример Pipeline в Jenkins (Declarative). Он подходит для обучения и локальной инфраструктуры:

pipeline {
  agent any
  stages {
    stage('Checkout') {
      steps {
        echo 'Checkout repository'
        // В реальной задаче: checkout scm
      }
    }
    stage('Build') {
      steps {
        sh 'echo "Build on Android Jenkins"'
        sh 'uname -a'
      }
    }
    stage('Test') {
      steps {
        sh 'echo "Tests..."'
        sh 'true'
      }
    }
  }
  post {
    always {
      echo 'Pipeline finished'
    }
  }
}

Чтобы сделать pipeline «по-настоящему CI/CD», добавьте:

проверку зависимостей;
параллелизацию стадий (если устройство тянет);
публикацию артефактов (в Jenkins artifacts);
уведомления (email/Slack/и т.п. — при наличии внешних интеграций).

Согласование артефактов и кэшей: как сделать пайплайн рациональным

Android-устройство — ресурс ограниченный. Поэтому полноценность CI/CD лучше достигать не количеством процессов, а грамотной рационализацией:

Кэш зависимостей: используйте кеши в Jenkins (например, для Maven/NPM/Pip) или GitLab cache.
Лимиты ресурсов: ограничивайте ресурсы контейнеров (CPU/RAM), если они доступны в вашей конфигурации.
Артефакты: сохраняйте минимально необходимое (отчёты тестов, сборочные результаты).

Для GitLab используйте cache и artifacts, например:

build:
  stage: build
  tags: [android, termux]
  image: alpine:3.20
  script:
    - mkdir -p build-output
    - echo "artifact" > build-output/result.txt
  artifacts:
    paths:
      - build-output/
    expire_in: 7 days

Безопасность: ключи, токены, минимальные права

Разворачивая CI/CD даже локально, важно не хранить секреты в явном виде в репозитории. Рекомендации:

используйте переменные окружения/секреты GitLab;
для Jenkins — применяйте Credentials Plugin и храните секреты там;
ограничивайте доступ к docker.sock, если это возможно в вашей модели.

Для GitLab Runner токены регистрации — это отдельные секреты. После регистрации убедитесь, что конфиг доступен только вам (файловые права и корректные каталоги на устройстве).

Проверка работоспособности: что тестировать в первую очередь

Перед тем как считать пайплайн «полноценным», проверьте:

Runner успешно получает job’ы и корректно стартует executor;
job’ы не падают из-за нехватки ресурсов/времени;
артефакты и логи попадают туда, куда вы ожидаете;
после перезапуска контейнеров Runner и Jenkins настройки сохраняются;
сборки воспроизводимы (одинаковая команда приводит к предсказуемому результату).

Частые проблемы (и как подойти к диагностике)

1) Runner не выполняет job’ы — обычно причина в тегах или регистрации. Проверьте: соответствие tags в .gitlab-ci.yml и --tag-list при регистрации, а также факт, что Runner «online» в GitLab.

2) Jenkins не доступен по сети — проверьте проброс порта и сетевую доступность (в зависимости от окружения). Просмотрите логи контейнера.

3) Сборки нестабильны — добавьте логи (в обеих системах), увеличьте таймауты, и используйте воспроизводимые образы.

4) Нет персистентности — проверьте bind-mount каталогов с данными Jenkins и конфигов GitLab Runner.

Заключение

Развёртывание CI/CD на Android с помощью Termux — вполне реализуемая задача для обучения, прототипов и локальной разработки. При грамотной контейнеризации вы получаете инфраструктуру уровня «как на сервере»: GitLab Runner выполняет job’ы, Jenkins управляет пайплайнами, а артефакты и история сборок сохраняются благодаря персистентному хранилищу.

Если хотите сделать это под вашу модель устройства, версию Android и конкретный стек (Java/Maven, Node.js, Python, Go, Docker-in-Docker и т.д.), команда РыбинскЛАБ может помочь с подбором архитектуры, настройкой Runner/Jenkins и подготовкой шаблонов CI/CD под ваши проекты.