VPS под GitLab Runner: сколько ресурсов нужно CI и когда свой раннер дешевле

Когда есть смысл поднимать свой раннер

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

Второй мотив часто важнее первого. На своём раннере вы контролируете кэш зависимостей и слои Docker между запусками, а это обычно сокращает время сборки заметно сильнее, чем прирост от более быстрого процессора.

Третий сценарий — приватность: код и артефакты не покидают вашу инфраструктуру. Для части команд это решающий довод.

Сколько ресурсов закладывать

Отправная точка для одного раннера с одним-двумя параллельными джобами: 2 ядра, 4 ГБ оперативной памяти, диск от 40 ГБ. На этом комфортно собираются типовые веб-проекты и небольшие сервисы.

Для команды с регулярными пайплайнами и несколькими параллельными джобами — 4 ядра, 8 ГБ памяти, диск от 80 ГБ. Помните, что параллельные джобы делят ресурсы машины: четыре одновременные сборки на двух ядрах будут выполняться дольше, чем последовательно.

Настройка concurrent в конфигурации раннера должна соответствовать железу. Поставить восемь параллельных джобов на двухъядерной машине можно, но каждая сборка станет тормозить остальные, а на тяжёлых шагах вы упрётесь в память.

Диск заканчивается первым

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

Поэтому берите диск с запасом и обязательно настройте регулярную очистку неиспользуемых образов и томов. Тип диска тоже важен: сборка активно читает и пишет, и SSD или NVMe заметно быстрее HDD на этой нагрузке.

Отдельно заложите место под кэш, если пользуетесь им осознанно: кэш ускоряет пайплайны ровно до тех пор, пока для него есть место.

Где размещать раннер

Раннер общается с сервером GitLab, реестрами образов и репозиториями пакетов, поэтому важна не столько география, сколько стабильность и скорость канала.

Площадка в России удобна, если раннер должен ходить во внутреннюю сеть компании или деплоить на российские серверы — меньше задержка и проще с доступами. Европейская площадка бывает выгоднее, когда пайплайн активно тянет образы и пакеты из зарубежных реестров.

Если деплой идёт на ваши же серверы, разумно держать раннер рядом с ними: это сокращает время выкладки и упрощает сетевые правила.

Безопасность: раннер имеет доступ ко всему

Раннер выполняет код из репозитория и держит переменные окружения с секретами. Фактически это машина с доступом к вашим ключам деплоя, реестрам и, возможно, продакшену.

Отсюда два правила. Первое: не запускайте на одном раннере пайплайны из доверенных и недоверенных источников — например, сборки merge request от внешних участников. Второе: используйте Docker executor, чтобы каждая сборка шла в изолированном контейнере, а не напрямую в системе.

И держите раннер отдельно от продакшен-серверов: компрометация сборочной машины не должна автоматически означать компрометацию боевой.

Типичные ошибки

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

Не настроить очистку Docker-образов. Через несколько недель раннер встанет с ошибкой нехватки места, обычно в самый неудачный момент.

Экономить на памяти: сборки фронтенда и тесты с поднятой базой данных потребляют её заметно больше, чем кажется по размеру проекта.

Держать раннер на той же машине, что и продакшен, ради экономии.

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