We detected you are likely not from a Russian-speaking region. Would you like to switch to the international version of the site?

  Назад к списку статей
Termux

Инфраструктура CI/CD на мобильном устройстве: GitLab‑Runner в Termux, артефакт‑хранилище и динамический деплой

06 июн 2026 в 19:30 Усачёв Денис Евгеньевич

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

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

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

Рассмотрим типовую схему:

  • Termux — устройство, на котором работает GitLab Runner (с Docker либо без него — по ситуации).
  • Артефакт‑хранилище — куда сохраняются собранные пакеты/билды (варианты: MinIO/S3-compatible в локальной сети, локальная файловая «витрина» через HTTP, либо GitLab Package Registry — если вам подходит).
  • Динамический деплой — создание/обновление окружения под конкретный job/branch (например, через docker-compose на локальной машине, Kubernetes в лаборатории или через запуск скриптов развёртывания на тестовом сервере).

Так вы получаете поток: push → пайплайн GitLab → сборка на Termux → публикация артефактов → развёртывание тестовой среды.

Предварительные требования

  • Android-устройство (или другое устройство, поддерживающее Termux).
  • Доступ к сети в рамках вашей инфраструктуры.
  • Учётная запись в GitLab и проект с включённым CI.
  • Для артефакт‑хранилища: либо локальный S3-compatible сервис (например, MinIO), либо иной совместимый вариант.
  • Для динамического деплоя: целевая тестовая площадка (сервер/VM или локальная среда), куда будут развёртываться сервисы.

Подготовка Termux

Начнём с базовой подготовки пакетов. Обновите систему, установите зависимости и утилиты сборки.

pkg update && pkg upgrade -y
pkg install -y git curl wget tar unzip jq openssh rsync proot-distro clang make

Для GitLab Runner обычно понадобится bash и ca-certificates. Их часто хватает из базовых пакетов, но на всякий случай можно добавить:

pkg install -y bash ca-certificates

Далее — настройка переменных среды и удобного пути.

mkdir -p ~/ci/workspace ~/ci/artifacts ~/ci/logs
export CI_HOME=~/ci
cd ~

GitLab Runner в Termux

Есть два подхода:

  1. Runner как бинарник (предпочтительно, если вы можете собрать/достать подходящую сборку под архитектуру устройства).
  2. Runner в контейнере (например, через Docker/Podman, если они доступны в вашей среде).

На практике чаще используют первый вариант: скачивают бинарник Runner и регистрируют его в GitLab.

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

Устройство может иметь архитектуру ARM. Под неё нужно получить бинарник GitLab Runner. Проверьте архитектуру:

uname -m

Дальше — скачайте релиз GitLab Runner, подходящий для вашей архитектуры. Пример ниже показывает общий принцип (подставьте верную ссылку из релизов GitLab Runner).

cd ~/ci
# Пример: скачивание конкретной версии (уточните URL под вашу архитектуру)
curl -L -o gitlab-runner "https://gitlab-runner-downloads.example.com/vX.Y.Z/binaries/gitlab-runner-android-arm64"
chmod +x gitlab-runner
./gitlab-runner --version

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

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

В GitLab откройте: Settings → CI/CD → Runners. Создайте Runner (или получите Registration Token) и выберите тип (обычно shell или custom).

В Termux зарегистрируйте Runner:

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

# Запуск регистрации
~/ci/gitlab-runner register

Дальше GitLab предложит ввести параметры:

  • GitLab URL (ваш домен GitLab).
  • Token (registration token).
  • Description (например, termux-runner-01).
  • Tags (например, termux, mobile, shell).
  • Executor (часто shell).

Если выбран shell, то Runner будет выполнять job-команды прямо в Termux. Это просто и удобно для тестовых задач.

Шаг 3. Запуск Runner

После регистрации запустите Runner в фоне. В зависимости от ваших возможностей используйте screen/tmux или запуск через nohup.

nohup ~/ci/gitlab-runner run --working-directory ~/ci/workspace --config ~/ci/gitlab-runner/config.toml > ~/ci/logs/runner.log 2>&1 &

Проверьте логи:

tail -n 100 ~/ci/logs/runner.log

Настройка пайплайна: сборка и подготовка артефактов

Допустим, у вас есть приложение, которое собирается в артефакт (например, .jar, .apk, .zip) и публикуется в хранилище. В GitLab обычно это оформляют через stages, artifacts или через публикацию в внешнее хранилище.

Если вы хотите отдельное артефакт‑хранилище (S3-compatible), то лучше публиковать туда явно, чтобы затем использовать для деплоя и откатов.

Пример .gitlab-ci.yml: сборка + публикация артефакта

Ниже — концептуальный пример. Подставьте свои команды сборки и адреса хранилища.

stages:
  - build
  - publish
  - deploy

variables:
  ARTIFACT_NAME: "app-${CI_COMMIT_REF_SLUG}-${CI_PIPELINE_IID}.zip"
  ARTIFACT_PATH: "dist/${ARTIFACT_NAME}"

build_job:
  stage: build
  tags:
    - termux
    - shell
  script:
    - echo "Сборка проекта на Termux..."
    - mkdir -p dist
    - # Пример: ваша команда сборки
    - # ./build.sh
    - echo "dummy content" > "dist/app-${CI_COMMIT_REF_SLUG}-${CI_PIPELINE_IID}.zip"
    - ls -lah dist
  artifacts:
    when: on_success
    expire_in: 7 days
    paths:
      - dist/.zip

publish_job:
  stage: publish
  tags:
    - termux
    - shell
  script:
    - echo "Публикация артефакта в хранилище..."
    - test -f "${ARTIFACT_PATH}"
    - # Замените на вашу S3-compatible публикацию. Вариант через curl/HTTP или s3cmd/awscli.
    - curl -f -X PUT "http://MINIO_LOCAL:9000/artifacts/${CI_COMMIT_REF_SLUG}/${ARTIFACT_NAME}" 
        -H "X-Auth-Token: ${ARTIFACT_TOKEN}" 
        --upload-file "${ARTIFACT_PATH}"
  dependencies:
    - build_job

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

  • tags позволяют направлять job именно на ваш Termux Runner.
  • artifacts в GitLab дают временное хранение для удобства.
  • publish_job выгружает артефакт в внешнее хранилище для деплоя и контроля версий.

Артефакт‑хранилище: практические варианты

Вариантов несколько. Выбор зависит от того, где вы хотите хранить артефакты и как обеспечить адресность для деплоя.

Вариант A: локальный S3-compatible (например, MinIO)

Это удобно тем, что API стандартное, легко интегрировать с CI, а данные можно держать в локальной сети.

Если вы используете S3-compatible, держите в секрете токены/ключи в GitLab CI/CD Variables (masked, protected — по необходимости).

Вариант B: HTTP-доступная «витрина» артефактов

Если у вас нет готового S3, можно поднять простой сервер, который принимает PUT-загрузки и отдаёт файлы по URL. Тогда depoy будет скачивать артефакт по ссылке.

Вариант C: GitLab Package/Registry

Этот вариант проще организационно, если вам хватает встроенного подхода GitLab. Однако для «динамического деплоя» с явными ссылками внешнего вида часто удобнее использовать единое артефакт‑хранилище в локальной инфраструктуре.

Динамический деплой: как делать по месту

Под «динамическим деплоем» обычно понимают развёртывание окружений на основе ветки/переименования, инкремента или переменных pipeline.

Рассмотрим схему, где есть целевой сервер/машина (например, dev-host в вашей лаборатории) и на ней запускается docker-compose или аналогичный механизм. Терминология «динамический» означает, что имя контейнера/стека или переменные конфигурации создаются из параметров CI.

Пример: deploy_job с скачиванием артефакта

В этом примере deploy выполняется на том же Runner (Termux). Если ваш деплой должен происходить на отдельном сервере, то deploy-команда может быть SSH-командой на сервер.

deploy_job:
  stage: deploy
  tags:
    - termux
    - shell
  script:
    - echo "Деплой в тестовое окружение..."
    - export ENV_NAME="test-${CI_COMMIT_REF_SLUG}"
    - export DEPLOY_URL="http://MINIO_LOCAL:9000/artifacts/${CI_COMMIT_REF_SLUG}/${ARTIFACT_NAME}"
    - echo "Окружение: ${ENV_NAME}"
    - echo "Артефакт: ${DEPLOY_URL}"

    - mkdir -p ~/ci/deploy
    - cd ~/ci/deploy
    - curl -f -L "${DEPLOY_URL}" -o "${ARTIFACT_NAME}"

    - # Пример: загрузка и запуск через ваш скрипт деплоя
    - # ./deploy.sh --env "${ENV_NAME}" --artifact "${ARTIFACT_NAME}"
    - echo "Выполнить развёртывание для ${ENV_NAME} из ${ARTIFACT_NAME}"
  rules:
    - if: '$CI_COMMIT_BRANCH'
      when: manual

Добавьте правила rules, чтобы деплой запускался вручную или только для определённых веток (master/main, develop или тэгов).

Деплой на удалённую тестовую машину (рекомендуемый практический подход)

Часто Termux не должен «сам» разворачивать весь стек, а только инициировать деплой на сервере. Тогда используйте SSH на вашу тестовую машину в локальной сети.

Сценарий:

  1. Runner скачивает артефакт или сразу передаёт URL.
  2. Runner выполняет SSH-команды на сервере.
  3. Сервер скачивает артефакт из хранилища и перезапускает сервис.

Пример с SSH (концептуальный):

deploy_job_remote:
  stage: deploy
  tags:
    - termux
    - shell
  script:
    - export ENV_NAME="test-${CI_COMMIT_REF_SLUG}"
    - export ARTIFACT_URL="http://MINIO_LOCAL:9000/artifacts/${CI_COMMIT_REF_SLUG}/${ARTIFACT_NAME}"

    - echo "Инициируем удалённый деплой для ${ENV_NAME}"
    - ssh -o StrictHostKeyChecking=no "${DEPLOY_USER}@DEPLOY_HOST" "bash -lc 'REMOTE_ENV_NAME="${ENV_NAME}" REMOTE_ARTIFACT_URL="${ARTIFACT_URL}" /opt/deploy/deploy.sh'"
  rules:
    - if: '$CI_COMMIT_BRANCH'
      when: manual

В GitLab задайте переменные DEPLOY_USER, DEPLOY_HOST и при необходимости ключи/пароли. Пароли лучше не хранить в открытом виде: используйте SSH-ключи и GitLab CI/CD variables.

Если нужен VPN: только для создания локальной сети

В случаях, когда вы хотите подключить мобильное устройство к тестовой сети «как к локальной», можно использовать VPN для создания локальной сети (например, site-to-site или device-to-site), чтобы Runner видел хранилище артефактов и деплой-хост. Не используйте VPN для обхода блокировок — это предмет отдельной политики и рисков.

Секреты и безопасность

  • Держите токены артефакт‑хранилища в CI/CD Variables в GitLab.
  • Используйте masked и protected где это уместно.
  • Ограничивайте доступ к arтефакт‑хранилищу (в идеале — только из вашей сети).
  • Логи Runner и job-вывод не должны содержать ключи.

Надёжность: повторяемость и чистота окружения

Чтобы пайплайны не «засоряли» устройство, используйте:

  • Очистку временных каталогов после job.
  • Проверку доступности хранилища и деплой-хоста (health checks).
  • Отдельные директории под pipeline (через CI_PIPELINE_IID).

Пример очистки:

after_script:
  - echo "Чистка рабочего каталога..."
  - rm -rf ~/ci/deploy/

Заключение

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

Если хотите, мы в РыбинскЛАБ поможем спроектировать вашу схему CI/CD, подобрать артефакт‑хранилище и написать деплой-скрипты под вашу инфраструктуру (включая интеграцию Termux/GitLab Runner и настройку переменных/секретов).

* Текст статьи подготовлен и структурирован с использованием технологий искусственного интеллекта. Проверен и доработан перед публикацией.

Нужна помощь с настройкой Termux, Linux и серверов?

Я оказываю ИТ-услуги: настройка серверов, автоматизация, безопасность, помощь с Linux и инфраструктурой. Материалы сайта — только в ознакомительных и образовательных целях.

Связаться со мной
Поддержать проект