GitLab CI-раннер на Ubuntu 24.04: пошаговая установка

MAATRIX

Общие раннеры GitLab быстро упираются в лимит бесплатных минут, а сборки идут на чужих машинах. Свой GitLab CI-раннер на Ubuntu 24.04 снимает эти ограничения: неограниченное время сборок, полный контроль над окружением, предсказуемая скорость. Свежий LTS даёт актуальные пакеты и долгую поддержку. Разберём установку и регистрацию раннера по шагам, чтобы пайплайны заработали на вашем сервере.

Зачем свой раннер и почему Ubuntu 24.04

GitLab CI выполняет пайплайны на раннерах — исполнителях, которые забирают задания, собирают проект и прогоняют тесты. Публичные раннеры удобны для старта, но имеют потолок бесплатных минут, а инфраструктуру вы не контролируете. Для приватного кода, тяжёлых сборок или частых пайплайнов это узкое место. Собственный раннер убирает лимит минут, даёт полный контроль над окружением и оставляет данные проекта на вашей инфраструктуре.

Ubuntu 24.04 — удачная база: свежие пакеты, актуальный Docker, долгая поддержка обновлениями безопасности. Раннер на такой системе работает стабильно и не требует ухищрений с устаревшими зависимостями. Тип исполнителя выбирают под задачу, но для большинства случаев оптимален Docker: каждая сборка идёт в чистом контейнере, результат воспроизводим и не зависит от мусора в системе.

Стоит развеять частое опасение, будто свой раннер требует постоянного присмотра. После первичной настройки он ведёт себя как обычный системный сервис: сам забирает задания, сам стартует после перезагрузки, сам сообщает о себе в GitLab. Всё внимание сводится к периодической очистке диска и обновлению пакета. Взамен вы получаете предсказуемую скорость сборок, не зависящую от очереди на общих раннерах в час пик, и полную свободу в окружении: любые версии инструментов, приватные реестры, свой кеш зависимостей. Для команды, которая собирает код чаще пары раз в день, свой раннер окупается и деньгами за минуты, и сэкономленным временем ожидания.

Требования к серверу зависят от того, что собираете. Для линтинга и тестов небольшого бэкенда хватает двух ядер и 2 ГБ памяти. Сборка фронтенда, компиляция или прогон Docker-образов прожорливее — там комфортнее четыре ядра, 4–8 ГБ и быстрый диск. У MAATRIX сервер под раннер оплачивается из России картой, по СБП, криптой или токеном MAAT, а конфигурацию можно нарастить, когда сборки станут тяжелее.

Шаг 1. Подготовка сервера

Обновите свежую систему и поставьте базовую защиту — вход по SSH-ключу и фаервол. Раннер получит доступ к вашему коду и, возможно, к секретам деплоя, поэтому сервер под ним должен быть защищён:

apt update && apt upgrade -y
ufw allow 22/tcp && ufw enable

Раннеру не нужны открытые входящие порты: он сам опрашивает GitLab и инициирует соединения. Поэтому фаервол можно держать закрытым на вход, оставив только SSH для управления. Убедитесь, что с сервера открывается адрес вашего GitLab, — исходящие соединения к нему обязаны проходить, иначе раннер не сможет забирать задания.

Шаг 2. Установка Docker

Docker-исполнитель даёт воспроизводимость: пайплайн стартует из заданного образа, и результат не зависит от того, что осталось на сервере после прошлых запусков. Поставьте Docker официальным скриптом:

curl -fsSL https://get.docker.com | sh
docker --version

Это избавляет от классической проблемы «на моей машине работает»: чистый контейнер под каждую сборку исключает влияние прошлых прогонов и накопившегося мусора. Альтернативный shell-исполнитель запускает команды прямо в системе — он проще, но грязнее и менее безопасен, потому что сборки видят друг друга и саму систему. Для большинства проектов выбирают именно Docker.

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

Сам раннер ставится из официального репозитория GitLab. Подключите его и установите пакет:

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | bash
apt install -y gitlab-runner
systemctl status gitlab-runner

После установки раннер работает как системный сервис и стартует автоматически. Пока это «пустой» раннер: он установлен, но ещё не связан ни с одним проектом. Связывание происходит на следующем шаге через регистрацию с токеном. Процесс раннера постоянно опрашивает GitLab на предмет новых заданий — это и есть причина, по которой ему не нужны открытые порты.

Шаг 4. Регистрация раннера

Чтобы раннер начал получать задания, зарегистрируйте его в проекте или группе GitLab. Токен берётся в настройках CI/CD проекта, в разделе с раннерами. Запустите регистрацию:

gitlab-runner register

Мастер спросит адрес GitLab, токен, описание, теги и тип исполнителя. Укажите docker и задайте образ по умолчанию, из которого будут стартовать сборки без явного указания. Теги — важная деталь: они направляют конкретные задания на конкретные раннеры. Тег вроде docker или build в задании подскажет GitLab, что его должен взять именно ваш раннер. После успешной регистрации раннер появится в настройках проекта как активный и онлайн.

Шаг 5. Первый пайплайн

Проверим раннер на деле. В корне репозитория создайте файл .gitlab-ci.yml с простой задачей, привязанной к тегу вашего раннера:

build:
  image: alpine:latest
  tags:
    - docker
  script:
    - echo "Раннер на Ubuntu 24.04 работает"
    - uname -a

Закоммитьте и запушьте файл. GitLab запустит пайплайн, ваш раннер заберёт задание, стартует контейнер из указанного образа и выполнит команды. В разделе пайплайнов вы увидите лог выполнения. Если задача прошла и в логе видны ваши строки — раннер, исполнитель и связь с GitLab настроены верно. Дальше пайплайн наполняют реальными шагами: установка зависимостей, тесты, сборка, деплой.

Шаг 6. Оптимизация и обслуживание

Когда раннер работает, настройте его под нагрузку. Число параллельных заданий подбирают по количеству ядер, чтобы не перегрузить сервер. Кеш зависимостей между сборками резко ускоряет пайплайны — пакеты не скачиваются каждый раз заново. Docker умеет кешировать слои образов, что тоже экономит время.

Следите за диском: сборки оставляют образы и временные файлы, которые со временем забивают место, и однажды пайплайны встанут из-за его нехватки. Настройте периодическую очистку неиспользуемых образов командой docker system prune -af по расписанию. Проверьте, что раннер стартует после перезагрузки — он ставится в автозапуск по умолчанию, но лишняя проверка через systemctl is-enabled gitlab-runner не помешает. Если сборки упираются в ресурсы и очередь растёт, это честный сигнал перейти на более мощный VPS. У MAATRIX нарастить конфигурацию можно в любой момент, оплатив из России удобным способом, — и свой раннер остаётся быстрым помощником команды.

Частые вопросы