Быстрые сборки на выделенных ядрах и NVMe

Мыслите слотами под задачи: определите, сколько потоков нужно типичной задаче, и разделите на это сервер. Ориентировочно, из расчёта 8 потоков на задачу:

Нижняя граница диапазона оставляет несколько потоков для хоста, агента раннера и кэшей. Задачи с интенсивной компиляцией масштабируются по потокам; тесты же часто упираются в один поток или в ввод-вывод, поэтому, прежде чем покупать ядра, профилируйте самый медленный этап пайплайна. Используйте свободную RAM: сборка в каталоге tmpfs убирает дисковый ввод-вывод с критического пути для многих задач компиляции.

Отдавайте предпочтение эфемерным раннерам, которые запускают для каждой задачи свежий контейнер или microVM и удаляют его после завершения, например через actions-runner-controller в Kubernetes или Docker executor в GitLab Runner. Каждая задача получает чистое окружение, а кэши живут вне её песочницы.

На выделенном раннере главный выигрыш обычно в том, чтобы никогда не скачивать и не пересобирать одно и то же дважды:

• Образы контейнеров: зеркало реестра в режиме pull-through (Distribution или Harbor) в частной сети и кэш BuildKit на локальных NVMe.
• Зависимости: проксируйте загрузку пакетов npm, PyPI, Maven и модулей Go через локальный кэш.
• Компиляторы: ccache или sccache для C, C++ и Rust, а для монорепозиториев — удалённый кэш Bazel на NVMe.
• Git: держите на раннере зеркала или reference-клоны и используйте неглубокие (shallow) или частичные (partial) клоны.

На Pro 64 выделите небольшой зеркальный раздел под ОС, а остальной объём четырёх накопителей NVMe Gen5 объедините в RAID 0 под данные кэша — их всегда можно пересобрать. Трафик на каждом порту безлимитный, поэтому прогрев кэшей, загрузка артефактов и зеркалирование реестров ничего не стоят сверх тарифа. Общие кэши для раннеров в одной локации раздавайте по бесплатной частной VLAN.

Self-hosted раннер выполняет любой код, который ему передаёт пайплайн, поэтому относитесь к нему как к инфраструктуре, открытой для атак:

• Никакого недоверенного кода на постоянных раннерах: документация GitHub рекомендует self-hosted раннеры только для приватных репозиториев, потому что pull request из форка может выполнить на машине произвольный код. Для публичных проектов используйте эфемерные раннеры или оставляйте сборки форков на облачных (hosted) раннерах.
• Разделение уровней доверия: отдельные раннеры или хотя бы отдельные группы раннеров для задач деплоя, у которых есть доступ к учётным данным продакшена.
• Короткоживущие учётные данные: федерация OIDC или токены с ограниченными правами вместо долгоживущих секретов, хранящихся на хосте.
• Защищённый хост: вход только по SSH-ключам, файрвол с политикой запрета по умолчанию и автоматические обновления безопасности; основы описаны в нашем руководстве по защите сервера.

Делайте хосты раннеров воспроизводимыми. С REST API и провайдером Terraform раннер можно по расписанию переустанавливать из чистого образа, а консоль KVM вернёт вам доступ, если неудачное изменение заблокирует вход.