Настройка полноценного CI/CD пайплайна в Termux: GitLab Runner и Docker‑контейнеры для мобильных разработчиков

Мобильная разработка в Termux перестала быть «только для экспериментов». При наличии устойчивого подключения, Docker-окружения и корректно настроенного GitLab Runner можно собирать, тестировать и даже деплоить приложения по тем же принципам, что и на сервере — оставаясь в контуре разработки с телефона.

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

Архитектура решения

Рекомендуемая модель:

1. Termux — среда, где живёт Docker и GitLab Runner.
2. GitLab — репозиторий и определение пайплайнов в файле .gitlab-ci.yml.
3. GitLab Runner — агент, который получает задания и запускает их через Docker.
4. Docker‑контейнеры — среда сборки/тестов (изолированно, воспроизводимо).

Важно: такой CI/CD предназначен для ваших задач разработки и тестирования. Для промышленного деплоя применяйте отдельные безопасные контуры и проверенные инфраструктурные решения.

Подготовка Termux: зависимости и базовая настройка

Перед стартом обновите пакеты в Termux и установите утилиты:

pkg update -y && pkg upgrade -y
pkg install -y curl git nano ca-certificates proot-distro

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

Если вы уже используете рабочий Docker в Termux — переходите к разделу с установкой GitLab Runner.

Docker в Termux: подход для изолированных сборок

Чтобы CI был воспроизводимым, лучше, чтобы сборки выполнялись внутри контейнеров. На стороне Termux вам нужно иметь доступ к Docker API.

Практический чек-лист:

• Docker daemon доступен по socket’у (обычно что-то вроде /var/run/docker.sock или аналогичный путь в вашей реализации).
• Вы можете выполнять команды docker version и docker ps.
• Runner сможет создавать и запускать контейнеры.

Проверка:

docker version
docker ps

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

Установка GitLab Runner

Далее установим GitLab Runner в Termux. Проще всего — скачать бинарник, соответствующий архитектуре устройства.

Порядок действий:

1. Установить зависимости для загрузки/распаковки.
2. Скачать runner под вашу архитектуру.
3. Сделать бинарник исполняемым.

Примерно:

pkg install -y wget unzip tar

# Пример: скачивание (замените URL на актуальный под вашу версию)
# Важно: выбирайте версию GitLab Runner и правильную архитектуру.
wget -O gitlab-runner.zip "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-android-arm64.zip"
unzip gitlab-runner.zip -d $HOME/gitlab-runner
chmod +x $HOME/gitlab-runner/gitlab-runner
$HOME/gitlab-runner/gitlab-runner --version

Примечание: конкретные URL и названия архивов зависят от релиза и архитектуры. При настройке уточните архитектуру вашего устройства (arm64/v7) и берите актуальный дистрибутив.

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

Зарегистрируем runner в нужном проекте или группе GitLab. У вас будет registration token, который обычно доступен в интерфейсе GitLab: Settings > CI/CD > Runners.

Запуск регистрации (интерактивно):

export GITLAB_URL="https://gitlab.example.com"
export REGISTRATION_TOKEN="YOUR_TOKEN"

$HOME/gitlab-runner/gitlab-runner register 
  --non-interactive 
  --url "$GITLAB_URL/" 
  --registration-token "$REGISTRATION_TOKEN" 
  --executor docker 
  --docker-image "alpine:3.20" 
  --description "termux-runner" 
  --tag-list "termux,docker" 
  --run-untagged=false 
  --locked=false

В процессе регистрации runner создаёт конфигурацию, обычно в $HOME/.config/gitlab-runner/config.toml или близком по смыслу пути (зависит от сборки/окружения).

Проверьте конфигурацию и наличие раздела [[runners]]:

ls -la $HOME/.config/gitlab-runner
cat $HOME/.config/gitlab-runner/config.toml | sed -n '1,200p'

Параметры для Docker‑исполнителя

Чтобы runner мог запускать контейнеры, в config.toml важно корректно указать параметры Docker. Общие идеи:

• Указать корректный privileged (если требуется для вашей модели Docker в Termux).
• При необходимости настроить volume монтирования (например, кэш или артефакты).
• Проверить лимиты на CPU/RAM/диск.

Пример фрагмента (ориентир, не универсальный):

[[runners]]
  name = "termux-runner"
  url = "https://gitlab.example.com/"
  token = "..."
  executor = "docker"
  [runners.docker]
    image = "alpine:3.20"
    privileged = false
    disable_cache = false
    volumes = ["$HOME/.cache:/cache"]

Если у вас возникают ошибки доступа к Docker socket, скорее всего потребуется поправить параметры окружения runner (или способ поднятия Docker). Важнее добиться стабильного статуса runner.

Запуск GitLab Runner как процесса в Termux

Запустите runner и убедитесь, что он «появился» как активный в GitLab.

$HOME/gitlab-runner/gitlab-runner run

Лучше держать runner в отдельной сессии (например, через screen/tmux). Установите:

pkg install -y tmux

И запустите runner внутри:

tmux new -s gitlab-runner
$HOME/gitlab-runner/gitlab-runner run

Дальше вы можете выходить из tmux и оставлять процесс живым.

Структура CI: кэш, артефакты и репродуцируемость

Чтобы CI/CD работал предсказуемо:

• Используйте контейнеры с фиксированными версиями (теги образов, а не «latest»).
• Добавляйте кэш для ускорения (зависит от стека: npm/pip/gradle и т.п.).
• Артефакты храните как результат сборки (например, dist/, отчёты тестов).

Ниже — универсальные шаблоны под pipeline.

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

Пример для условного проекта (подходит как каркас):

stages:
  - build
  - test
  - package

variables:
  DOCKER_DRIVER: overlay2

default:
  tags:
    - termux
    - docker

build:
  stage: build
  image: node:20-alpine
  script:
    - node -v
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

test:
  stage: test
  image: node:20-alpine
  script:
    - npm ci
    - npm test -- --ci
  artifacts:
    when: always
    paths:
      - coverage/
    expire_in: 1 week

package:
  stage: package
  image: alpine:3.20
  script:
    - ls -la dist || true
    - echo "Packaging step"

Ключевые моменты:

• Используются tags, чтобы джобы брались именно вашим runner’ом.
• Каждая джоба имеет свой image (контейнерная среда).
• Артефакты сохраняют результаты сборки и тестов.

Пример: сборка Docker-образа приложения (Docker-in-Docker не всегда нужен)

Если ваш проект требует сборки контейнерного образа, есть два сценария:

• Сборка образа внутри джобы с доступом к docker daemon (если он доступен).
• Сборка без docker (многослойная сборка и упаковка артефактов) — зависит от задачи.

Если docker доступен из джобы, можно сделать так:

stages:
  - build

build-image:
  stage: build
  image: docker:27-cli
  services:
    - name: docker:27-dind
      command: ["--tls=false"]
  variables:
    DOCKER_TLS_CERTDIR: ""
    DOCKER_HOST: "tcp://docker:2375"
  tags:
    - termux
    - docker
  script:
    - docker version
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" .
    - echo "Login/push as per your registry settings"

Важно: Docker-in-Docker (dind) в мобильных средах может быть чувствителен к ресурсам. Если устройство ограничено по памяти/CPU, предпочтите более лёгкие схемы сборки или переносите Docker-sборку на более мощную инфраструктуру.

Практика: кэширование зависимостей

Кэш снижает время пайплайнов. Пример для npm (Node):

test:
  stage: test
  image: node:20-alpine
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm test -- --ci

Если хотите кэшировать более правильно, часто кэшируют .npm или используемые директории менеджера пакетов, но это зависит от вашего проекта.

Безопасность и устойчивость: на что обратить внимание

Несколько практических рекомендаций:

• Ограничьте джобы по tags, чтобы их не забрали другие runners.
• Храните токены в GitLab CI/CD Variables и не коммитьте их в репозиторий.
• Проверяйте объём свободной памяти и места: Docker и кэш могут быстро занять пространство.
• Следите за обновлениями: фиксируйте версии образов и runner при необходимости.

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

Отладка типовых проблем

Проблема 1: runner не появляется или остаётся в статусе ожидания.

• Проверьте регистрацию и config.toml.
• Убедитесь, что runner запущен: gitlab-runner run.
• Сопоставьте tags в .gitlab-ci.yml и в регистрации.

Проблема 2: джобы падают с ошибками docker access.

• Проверьте работу Docker из Termux: docker ps.
• Проверьте, что runner имеет доступ к Docker socket (зависит от реализации).
• Уточните, нужно ли включать privileged (внимательно, только при необходимости).

Проблема 3: медленные пайплайны.

• Добавьте кэш зависимостей.
• Фиксируйте версии образов и используйте минимальные base-images.
• Сократите лишние шаги в stages.

Реальные советы для мобильных разработчиков

• Делайте pipeline «лёгким»: линтеры и unit-тесты в телефоне, а тяжёлые интеграции — по расписанию на сервере.
• Используйте артефакты, чтобы не терять результаты: логи тестов, покрытия, сборки.
• Настраивайте отдельные stages для сборки и релиза, чтобы не гонять все шаги при каждом коммите.

Заключение

Настройка CI/CD в Termux с GitLab Runner и Docker‑контейнерами позволяет превратить мобильную разработку в полноценный производственный процесс на уровне привычного GitLab: сборка, тестирование, упаковка артефактов и управляемые джобы. Ключ к стабильности — корректный Docker в Termux, верная регистрация runner, согласование tags и продуманная структура пайплайна с кэшами и артефактами.

Хотите сделать это быстрее и без «танцев с конфигами»? Команда РыбинскЛАБ поможет с подбором архитектуры, настройкой GitLab Runner под вашу инфраструктуру и подготовкой шаблонов .gitlab-ci.yml под ваши технологии.