Где хранить код и как настроить CI/CD, если GitLab CE уже не хватает
Иногда возможностей бесплатного GitLab уже недостаточно, при этом платная версия по понятным причинам недоступна. Собственные форки требуют постоянной возни с обновлениями и закрытием CVE, а написание своей системы — больших затрат ресурсов.
У нас есть готовое решение для такого случая. На вебинаре 27 февраля мы расскажем о Deckhouse Code — единой платформе для непрерывной разработки и управления жизненным циклом ПО:
Покажем, как настроить правила слияния, CODEOWNERS, push rules и безопасно хранить секреты вне платформы.
Обсудим, как сократить нагрузку на команды за счёт managed-подхода.
Проведём живое демо от коммита в консоли до артефакта в registry.
Регистрируйтесь и подключайтесь, если вы отвечаете за CI/CD в корпоративной среде. Автор лучшего вопроса в чате вебинара получит персональное демо под свою задачу.
Восстанавливал работоспособность одной репы и столкнулся с забавной особенностью.
Compose файлы, которые там есть — предельно простые. Есть цепочка сервисов, которые запускаются друг за другом. Первым стартует БД, никаких проблем. Вторым — сервис с API для загрузки данных в БД. Опять никаких проблем. Третьим — контейнер с wrk для нагрузочного тестирования. И вот тут загвоздка. Контейнер зависал в бесконечном состоянии "Created".
Подебажил. Оказалось, что при сборке образа API никак не фиксировался HEALTHCHECK! Podman по-умолчанию использует именно OCI спеку контейнеров, а не Docker, и там нет поддержки HEALTHCHECK. Из-за этого не срабатывал condition: service_healthy в Compose-файле, подвешивая контейнер с wrk.
Чтобы решить эту проблему, нужно явно указать формат спеки как Docker при сборке Dockerfile/Containerfile. У Podman это выглядит так:
Запуск GitLab Runner в Yandex Cloud Serverless Containers
Я Павел Елисеев, старший разработчик в команде Serverless в Yandex Cloud. Мы реализовали сценарий использования сервиса — Serverless GitLab Runner. В посте покажу архитектуру и поделюсь кодом решения.
GitLab Runner — агент, выполняющий задачи (jobs) из CI/CD‑пайплайнов GitLab. Он получает инструкции от GitLab, запускает сборку, тесты или деплой в нужной среде и передаёт результат обратно.
Раннер работает в разных окружениях:
на общих серверах GitLab (shared runners);
на выделенных VM;
в K8s‑кластере.
В первом варианте репозитории должны размещаться на gitlab.com. В случае Managed GitLab или self‑hosted GitLab развёртывание выполняется самостоятельно.
Для shared‑раннеров free‑tier ограничен 400 мин./мес. Учёт идёт по формуле (duration × price-factor), так что число доступных минут зависит от используемого типа раннера. А за пределами лимита нужна привязка не российской банковской карты.
Serverless‑сценарии пытались реализовать на Cloud Functions, что требовало отдельной VM и сложной конфигурации. А мы хотели объединить плюсы serverless‑модели с CI‑задачами:
оплата за время
масштабирование за секунды
изоляция выполнения
отсутствие инфраструктурной рутины
Архитектура
GitLab Runner работает по модели pull: запускает процесс, устанавливающий long‑polling‑соединение с GitLab API, и ожидает появления задач.
Пришла задача — раннер выбирает executor:
shell — job выполняется в текущем окружении
docker — под job создаётся отдельный контейнер со всеми зависимостями
Эта модель плохо подходит для serverless‑окружения, где нельзя держать постоянно активный процесс.
Для перехода на push‑модель используем GitLab Webhooks — HTTP‑уведомления о событиях. С появлением задач GitLab отправляет вебхук в Serverless Container, который:
запускает раннер;
получает информацию о задаче;
выполняет её и возвращает результат в GitLab.
Так, выполнение задачи инициируется событием, а не постоянным опросом API.
Для упрощённого развёртывания есть лёгкий образ раннера с поддержкой docker-executor, размещённый в Container Registry. Раннер автоматически загружает и запускает контейнер, указанный в конфигурации job. Секреты для аутентификации в GitLab API хранятся в Lockbox.
GitLab требует от обработчика вебхуков быстрого ответа без ошибки. А выполнение задачи может занимать часы. Поэтому вебхуки обрабатываются асинхронно:
GitLab отправляет вебхук.
Платформа проверяет авторизацию и сразу отвечает 202 Accepted.
Обработка выполняется асинхронно в фоне.
Платформа решает, запускать ли новый экземпляр контейнера. Когда job завершается, контейнер остаётся активным какое‑то время, чтобы обработать вызовы без cold‑start.
GitLab не отправляет событие «создание job», поэтому раннер сперва проверяет, есть ли задачи со статусом pending.
Для docker‑executor требуется dockerd. Инициализация демона и подготовка окружения выполняются 1 раз при старте контейнера. Если job найдётся, запускается эфемерный раннер, исполняющий ровно 1 задачу.
Раннер загружает docker‑образ, выполняет команды, передаёт результат обратно через GitLab API.
Docker внутри Serverless Containers. Это не Docker‑in‑Docker: внутри serverless‑контейнера jobs исполняются без отдельного демона Docker, но с аналогичной логикой. Примеры есть в исходном коде.
Важные особенности serverless‑подхода
Эфемерность: кеш между вызовами отсутствует. Для хранения артефактов используйте Object Storage или свои базовые образы.
Загрузка образов: выполняется при каждом запуске. Рекомендуем использовать оптимизированные образы и близкий реестр (Cloud Registry), а при критичных требованиях к скорости старта — перейти на shell‑executor, собрав образ с установленным раннером и нужными зависимостями.
Ограничение времени: не более 1 часа. Для длинных задач разделите пайплайн на этапы с промежуточным сохранением результатов.
Ограничение по диску: до 10 ГБ.
Сценарий Serverless GitLab Runner позволяет выполнять CI/CD‑задачи GitLab, оплачивая лишь время выполнения job. Serverless Containers дают возможности для CI‑нагрузок: асинхронные вызовы, часовой таймаут, эфемерный диск и поддержку docker‑executor внутри контейнера.
Привет! Сегодня поделюсь с вами рассказом, почему Scala-макросы могут замедлять CI не только временем компиляции. Выход из такой ситуации мы нашли не сразу, но решение оказалось настолько удачным, что наша команда решила им поделиться со всем сообществом. А дело было так…
У нас есть монорепозиторий на 4 млн LOC Scala-кода, мы собираем его в Bazel с кешированием результатов сборки, чтобы разработчики не ждали компиляцию и тестирование кода, который они не трогали. Долгое время у нас болело, что чужие тесты иногда запускались на CI.
Стали разбираться и выяснили: не весь наш код компилируется идемпотентно. Повторная компиляция одного и того же Scala-кода для многих таргетов создаёт jar-архивы с разной хэш-суммой, но семантически одинаковым содержанием. И весь зависящий от них код собирается заново. В этом виноваты Scala-макросы: при повторной компиляции кода с макросом, генерирующим sealed-иерархию, порядок перечисления наследников в байткоде может отличаться от предыдущей компиляции. Такое поведение мы обнаружили в библиотеках chimney и play-json.
То есть компиляция кода с использованием макросов из этих библиотек работала не идемпотентно и ломала кеширование сборок. Аналогичное поведение мы нашли и в одном макросе для ZLayer.
