Настройка собственного CI/CD конвейера в Termux с использованием GitLab Runner и Docker‑контейнеров

Termux позволяет использовать Android как полноценную рабочую станцию для разработки и автоматизации. В этой статье мы разберём, как построить собственный CI/CD конвейер прямо в Termux: установить и зарегистрировать GitLab Runner, подготовить окружение с Docker, и настроить запуск job’ов из .gitlab-ci.yml. В результате вы сможете проверять сборки, запускать тесты и выполнять проверки в изолированных контейнерах.

Материал ориентирован на практическую реализацию и будет полезен как для домашних проектов, так и для небольших команд.

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

Схема такая:

• Android + Termux: запускает GitLab Runner.
• Docker: обеспечивает изоляцию окружений для job’ов.
• GitLab: хранит репозиторий и запускает pipeline согласно .gitlab-ci.yml.
• Runner принимает job’ы от GitLab и выполняет команды внутри контейнеров.

Важно: конкретная доступность Docker в Termux зависит от вашего окружения/версий. На большинстве современных устройств используется вариант с rootless Docker, либо отдельные механизмы запуска контейнеров через совместимые обвязки. Мы покажем конфигурацию под общий сценарий.

Требования

• Устройство Android с установленным Termux.
• Доступ к GitLab (ваш проект/группа).
• Установленный Docker в среде Termux или совместимый контейнерный runtime.
• Интернет-соединение (для связи runner ↔ GitLab).

Подготовка Termux и базовых пакетов

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

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

Далее подготовим рабочие директории под Runner.

mkdir -p ~/gitlab-runner ~/docker-workdir
cd ~/gitlab-runner

Установка GitLab Runner в Termux

Один из практичных вариантов — скачать бинарник GitLab Runner под Android/ARM и разместить его в окружении Termux. Точные шаги зависят от архитектуры и доступных сборок. Рассмотрим общий подход:

uname -m
# далее скачайте подходящий бинарник (например, для linux-arm64 или linux-arm)
# примерно: curl -L -o gitlab-runner <URL_бинарника>
chmod +x gitlab-runner
mv gitlab-runner ~/bin/gitlab-runner

Убедитесь, что каталог с бинарником в PATH:

echo 'export PATH=$PATH:~/bin' >> ~/.bashrc
source ~/.bashrc
which gitlab-runner
gitlab-runner --version

Настройка Docker для job’ов

Чтобы runner мог выполнять задачи в контейнерах, в CI будет использоваться docker executor. В зависимости от вашего Docker-стека проверьте:

docker version
docker info

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

Также желательно создать каталог для временных артефактов:

mkdir -p ~/docker-workdir
chmod 700 ~/docker-workdir

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

Дальше создадим конфигурацию runner в Termux и зарегистрируем его в вашем GitLab.

1) Сначала создайте пустую папку конфигурации:

mkdir -p ~/.gitlab-runner

2) Запустите регистрацию. Команду регистрации GitLab Runner удобнее выполнять интерактивно:

gitlab-runner register

Во время регистрации укажите:

• GitLab instance URL — адрес вашего GitLab, например https://gitlab.example.com/
• Registration token — токен из GitLab (Settings → CI/CD → Runners или конкретной группы/проекта)
• Description — например Termux-Docker-Runner
• Tags — termux и/или docker
• Executor — выберите docker

После этого runner создаст конфигурационный файл (обычно ~/.gitlab-runner/config.toml). Проверьте его наличие:

ls -la ~/.gitlab-runner/config.toml

Редактирование config.toml под Docker executor

Откройте конфиг и убедитесь, что параметры соответствуют вашему окружению. Примерная структура:

vim ~/.gitlab-runner/config.toml

Часто внутри вы увидите блок [[runners]] и настройки executor = "docker". Важные параметры:

• image (по умолчанию) — базовый образ для job’ов (если не задан в .gitlab-ci.yml)
• privileged — обычно отключают, но для некоторых задач может потребоваться включение. Делайте это только при необходимости.
• volumes — монтирование директорий (например, кеш).
• shm_size — полезно для некоторых тестов.

Пример концептуальной конфигурации (адаптируйте под ваш файл):

[[runners]]
  name = "Termux-Docker-Runner"
  url = "https://gitlab.example.com/"
  token = "REPLACE_WITH_TOKEN"
  executor = "docker"

  [runners.docker]
    image = "alpine:latest"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    shm_size = 0
    volumes = ["/cache"]
    # Иногда полезно указать кеш-путь, если ваш runtime требует настройки.

Запуск GitLab Runner в Termux

После настройки запустите runner:

gitlab-runner run --working-directory ~/gitlab-runner

Если вы хотите, чтобы runner переживал перезапуски и работал в фоне, можно организовать запуск через терминальные средства Android/Termux (или через планировщик в зависимости от ваших предпочтений). Главное — обеспечить доступ к Docker и стабильное сетевое подключение.

Пример .gitlab-ci.yml для запуска контейнеров

Создадим простой пайплайн, который:

• использует образ,
• выполняет команды сборки/тестов,
• использует теги runner’а.

Пример файла .gitlab-ci.yml:

stages:
  - test

variables:
  # Для некоторых проектов полезно управлять поведением кеша/репозиторий.
  GIT_DEPTH: "1"

test-job:
  stage: test
  tags:
    - termux
    - docker
  image: python:3.12-slim
  script:
    - python --version
    - pip install -r requirements.txt || true
    - pytest -q || true
  artifacts:
    when: always
    paths:
      - test-results/

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

• tags — runner выбирается по тегам.
• image — образ, в котором исполняются команды job’а.
• Артефакты — по желанию.

Если у вас нет requirements.txt или тестов на начальном этапе, можно убрать соответствующие строки.

Кеширование (cache) и ускорение pipeline

Для ускорения можно добавить кеш зависимостей. Например, для Python:

test-job:
  stage: test
  tags: [termux, docker]
  image: python:3.12-slim
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - .cache/pip
  script:
    - python --version
    - pip install --cache-dir .cache/pip -r requirements.txt || true
    - pytest -q || true

Точный путь кеша может отличаться от вашего проекта, но общий принцип сохраняется.

Типичные проблемы и их решение

• Runner не принимает job’ы: проверьте tags в GitLab и в .gitlab-ci.yml, а также корректность регистрации.
• Docker недоступен: проверьте docker version и docker info в Termux, а также права доступа.
• Не сходятся TLS/сертификаты: убедитесь, что в Termux установлены ca-certificates, а GitLab instance URL указан корректно.
• Проблемы с сетевым соединением: проверьте стабильность подключения. Для корпоративных/домашних сетей убедитесь, что устройство доступно до GitLab по https.

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

Безопасность и best practices

• Не используйте привилегированный режим без необходимости (privileged), чтобы снизить риск.
• Минимизируйте образы — выбирайте небольшие базовые образы (alpine, slim).
• Храните токены аккуратно: не публикуйте config.toml и registration token в репозитории.
• Разделяйте окружения: для разных задач можно использовать разные теги runner’ов.

Расширение: несколько runner’ов и ветвление по задачам

По мере роста проекта удобно выделять разные runner’ы под разные типы задач. Например:

• runner с тегом python — для Python/тестов;
• runner с тегом node — для сборок frontend;
• runner с тегом docker — для универсальных контейнерных задач.

Для этого регистрируйте новые runner’ы с разными описаниями и tags, а затем направляйте jobs по тегам.

Заключение

Мы разобрали практический способ построить собственный CI/CD конвейер в Termux: установить GitLab Runner, настроить Docker‑исполнение job’ов, зарегистрировать runner в GitLab и собрать минимальный рабочий .gitlab-ci.yml для выполнения задач в контейнерах. Такой подход помогает быстрее итеративно тестировать изменения и держать автоматизацию рядом с вашим рабочим окружением.

Если хотите, чтобы настройка была выполнена под ваши условия (ваша версия Termux, модель Android, особенности Docker и сетевой доступ), обращайтесь в РыбинскЛАБ: поможем спроектировать, развернуть и отладить CI/CD под ваш стек.