Serverless GitLab Runner в Yandex Cloud: как работает и зачем нужен

GitLab Runner (или просто раннер) — это специальный агент, который выполняет задачи в CI/CD — автоматическом конвейере, который берёт новый код, прогоняет тесты и развёртывает готовое приложение на серверах. Раннер как раз и выполняет всю эту работу: получает инструкции от GitLab, запускает нужный этап — сборку, тестирование или публикацию — и сообщает о результатах.

Есть два распространённых сценария использования раннеров:

• Shared runners — общие раннеры, которые предоставляет GitLab. Их можно подключить без дополнительной настройки. Для проектов на GitLab.com это быстрый старт.
• Self‑hosted, или self‑managed, runners — раннеры, которые настраивает сам пользователь в своей инфраструктуре. Подход применим как для собственных инсталляций GitLab (включая Yandex Managed Service for GitLab), так и для проектов на GitLab.com: можно зарегистрировать свои раннеры и подключить их к проекту, если shared‑вариант недоступен или недостаточен.

Проблема традиционных self‑hosted раннеров в том, что они часто простаивают в ожидании задач, но инфраструктура, на которой они запущены, требует постоянных затрат.

Раньше расходы старались снижать автоматизацией: по расписанию создавали функции в Yandex Cloud Functions, которые включали и выключали виртуальные машины. Такая схема добавляла операционных задач — приходилось писать и сопровождать дополнительный код и инфраструктуру оркестрации. Координацию обеспечивали триггеры, которые в остальное время ожидали сигнал.

Мы решили эту проблему, внедрив serverless‑подход. Сначала добавили поддержку бессерверных воркеров для SourceCraft, а затем реализовали бессерверную версию GitLab Runner с запуском по событию в Yandex Serverless Containers.

В статье расскажу о принципах её работы и особенностях, а также покажу, насколько это выгодно.

Как работают бессерверные раннеры в Yandex Cloud Containers

Когда в GitLab появляется задача (job), он отправляет в Yandex Cloud вебхук — специальный HTTP‑запрос, который работает как сигнал: в ответ Yandex Serverless Containers создаёт контейнер, внутри которого запускается эфемерный GitLab Runner: он поднимается на время выполнения одной задачи и автоматически удаляется после завершения.

Раннер существует ровно столько времени, сколько требуется для выполнения этой задачи. Он использует docker‑executor — режим работы, при котором для выполнения CI/CD‑задачи запускается отдельный изолированный Docker^®‑контейнер. Все шаги этой задачи (например, установка зависимостей, сборка, тесты) проходят последовательно внутри этого контейнера. Раннер запрашивает у GitLab инструкции, обрабатывает этапы и возвращает результаты. После завершения работы вся инфраструктура немедленно исчезает — никаких «дежурных» виртуальных машин или кластеров не остаётся.

Чтобы такая архитектура работала, Yandex Serverless Containers предоставляет несколько специальных возможностей:

• Эфемерное (временное) хранилище объёмом до 10 ГБ. Оно доступно только на время выполнения задачи. Там хранится код, пакеты зависимостей, скомпилированные файлы и промежуточные артефакты. Такого объёма обычно достаточно для стандартных CI/CD‑сценариев: сборки веб‑приложений (Node.js, Python^™, Go) и запуска тестов.
• Асинхронный запуск. Это позволяет не блокировать GitLab: система мгновенно отвечает «принято в работу», а сам контейнер запускается параллельно. GitLab не ждёт, пока задача завершится.
• Таймаут выполнения до одного часа. Это ограничение на максимальную длительность работы. Его хватает для большинства типичных сценариев: сборки фронтенд‑приложений, прогона тестов и развёртывания в Kubernetes. Так, согласно исследованию CircleCI, 80% всех сборок завершаются менее чем за 10 минут.

Поддерживается выполнение Docker‑команд внутри serverless‑контейнера. Это обеспечивает продвинутую изоляцию: например, сам пайплайн может запускать собственные контейнеры — скажем, для тестов с базой данных. Это исключает конфликты зависимостей и позволяет использовать разные версии инструментов в одной задаче.

Эти четыре функции — эфемерное хранилище, асинхронный запуск, длительный таймаут и запуск Docker‑клиента внутри контейнера — реализованы на уровне платформы Yandex Serverless Containers. Они подходят и для других задач с похожими требованиями: обработки очередей сообщений, конвертации медиафайлов или генерации отчётов по расписанию.

Особенности бессерверных раннеров

Бессерверные раннеры подходят для большинства CI/CD‑задач, но у них есть технические ограничения, которые влияют на планирование пайплайнов:

• Время выполнения задачи — максимум один час на запуск.
• Оперативная память — до 8 ГБ на один контейнер.
• Дисковое пространство — 10 ГБ на запуск.

Если задачам нужно больше времени или ресурсов, можно использовать контейнеры с длительным циклом работы или традиционные раннеры на виртуальных машинах. Допускается комбинировать разные типы раннеров в зависимости от требований конкретных этапов пайплайна.

Бессерверная архитектура также подразумевает несколько технических особенностей, которые влияют на настройку CI/CD:

• Отсутствие постоянного кеша. Контейнеры создаются с нуля для каждого запуска, поэтому кеш между выполнениями не сохраняется. Для оптимизации можно использовать Yandex Object Storage для хранения артефактов или подготовить Docker‑образ с уже установленными зависимостями.
• Загрузка образов при каждом запуске. Docker‑образы загружаются заново при каждом выполнении задачи. Для ускорения процесса можно использовать компактные базовые слои и размещать образы в Yandex Container Registry — это реестр, расположенный в той же инфраструктуре, что ускоряет доступ. Если критично время «холодного старта», можно собрать образ со всеми компонентами и использовать shell‑executor — режим, выполняющий команды прямо в ОС контейнера.
• Ограничение времени выполнения в один час. Для длительных задач сборки можно разделить пайплайн на несколько этапов и сохранять промежуточные артефакты во внешнее хранилище.
• Ограничение дискового пространства до 10 ГБ. Для работы с крупными монорепозиториями может потребоваться оптимизация использования диска или переход на традиционные раннеры.

Экономика и когда выбирать serverless

Отчёт CircleCI за 2025 год показывает, что медианное число CI/CD‑workflows на проект — 1,64 запуска в день. При этом 75% проектов запускают хотя бы один workflow ежедневно, а 25% — 2,7 и более. Отчёт за 2024 год указывает медианную длительность workflow на уровне 2,84 минуты.

Круглосуточно работающая виртуальная машина с раннером обходится примерно в 2 тыс. рублей в месяц. Если команда запускает сборки всего несколько раз в день (а это довольно частый сценарий), то традиционная виртуальная машина большую часть времени простаивает.

При бессерверном подходе оплата идёт только за фактическое время работы, а не за все 720 часов в месяц, которые активна виртуальная машина (включая сотни часов простоя). Это помогает не только сократить затраты, но и повысить гибкость CI/CD‑инфраструктуры.

Ниже — четыре типичных сценария использования раннеров, от редких сборок до круглосуточной работы.

Сценарии использования раннеров

Так мы перенесли главные преимущества бессерверных вычислений в CI/CD:

• Оплата только за работу. Счётчик учитывает время выполнения задач с точностью до секунды (с округлением до 100 мс), без минимальных платежей за простой. Первые 1 млн вызовов контейнеров в месяц бесплатные. Также не тарифицируются первые 10 ГБ×час RAM и 5 vCPU×час при обработке запросов.
• Быстрое масштабирование. Если нужно обработать десять коммитов одновременно, платформа поднимет десять раннеров. При первом запуске происходит инициализация контейнера, что обычно занимает от нескольких сотен миллисекунд до нескольких секунд. Для последующих запусков контейнер уже «прогрет», находится в памяти и отвечает мгновенно.
• Изоляция. Каждая задача выполняется в отдельном изолированном контейнере.
• Автоматическое управление. Не нужно обновлять и обслуживать инфраструктуру виртуальных машин.

Если сборки запускаются нерегулярно или нагрузка сильно меняется от недели к неделе, бессерверный подход выигрывает. Оплата идёт только за фактическое время, система автоматически справляется с пиками нагрузки. И не нужно обслуживать инфраструктуру.

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