VPS для CI/CD runner: GitHub Actions self-hosted runner

Для ефективної роботи GitHub Actions self-hosted runner оптимально використовувати VPS з 4 ГБ оперативної пам'яті, 2 vCPU та NVMe-диском — така конфігурація забезпечує стабільну збірку Docker-контейнерів та прискорює CI/CD процеси в 5–10 разів у порівнянні зі стандартними безкоштовними ранерами GitHub.

Чому github actions self hosted — це стандарт для професійної розробки

Використання хмарних ранерів GitHub зручне для невеликих Open Source проєктів, але професійна розробка швидко впирається в обмеження: повільні процесори, ліміти за часом збірки (2000 хвилин на місяць на безкоштовному тарифі) та відсутність контролю над оточенням. Перенесення процесів на власний ci cd vps вирішує ці проблеми, надаючи виділені ресурси, які не діляться з іншими користувачами.

Прискорення збірки та кешування

Головний фактор прискорення — локальне зберігання даних. У хмарі GitHub кожен запуск починається з «чистого аркуша»: залежності (node_modules, пакети Go, кеш Maven) завантажуються заново або відновлюються з мережевого кешу, що займає до 70% часу пайплайну. На self hosted runner vps кеш зберігається на фізичному диску. Наприклад, збірка важкого React-додатку, яка в хмарі займає 8 хвилин, на VPS з NVMe-диском скорочується до 45–60 секунд за рахунок миттєвого доступу до вже завантажених шарів Docker та залежностей.

Економічна ефективність при масштабуванні

Безкоштовні хвилини GitHub швидко закінчуються, а вартість додаткових хвилин у хмарі непропорційно висока. Оренда одного потужного VPS дозволяє запускати десятки та сотні білдів на день без додаткової оплати. Це особливо важливо для команд, які використовують self-hosted Sentry або інші інструменти моніторингу, що потребують частих деплоїв та інтеграційних тестів.

Вибір конфігурації ci cd vps для різних задач

Продуктивність actions runner безпосередньо залежить від виділених ресурсів. Для компіляції важких проєктів на C++ або Java потрібна висока частота процесора та обсяг RAM, тоді як для деплою статичних сайтів достатньо мінімальних ресурсів.

Порівняльна таблиця характеристик VPS для ранерів

Тип проєкту Рекомендований CPU RAM (GB) Disk (NVMe) Продуктивність (vs Cloud) Frontend (React/Vue/Next.js) 2 vCPU (3.0+ GHz) 4 GB 40 GB 5x швидше Backend (Go/Rust/Java) 4-8 vCPU 8-16 GB 80 GB 8x швидше Docker-heavy (Microservices) 4 vCPU 8 GB 100 GB 10x швидше Mobile (Android/iOS) 8 vCPU 16+ GB 200 GB Залежить від емуляції При виборі сервера важливо враховувати не тільки кількість ядер, але і їх архітектуру. Сучасні процесори з частотою вище 3 ГГц значно скорочують час виконання unit-тестів, які часто працюють в один потік.

Покрокова установка github actions self hosted на Ubuntu

Процес встановлення займає не більше 10 хвилин. Для початку роботи потрібен чистий VPS з ОС Ubuntu 22.04 або 24.04. Рекомендується створити окремого користувача для запуску ранера, щоб уникнути роботи від імені root з міркувань безпеки.

Підготовка системи та створення користувача

sudo useradd -m -s /bin/bash github-runner
sudo usermod -aG sudo github-runner
sudo apt update && sudo apt upgrade -y
# Установка необхідних залежностей
sudo apt install -y curl git jq build-essential libssl-dev libffi-dev python3

Реєстрація ранера в репозиторії

Перейдіть в налаштування вашого репозиторію на GitHub: Settings -> Actions -> Runners -> New self-hosted runner. Виберіть Linux та дотримуйтесь інструкцій для завантаження архіву. Приклад команд для завантаження (версія може змінюватися):

mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64-2.311.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.311.0/actions-runner-linux-x64-2.311.0.tar.gz
tar xzf ./actions-runner-linux-x64-2.311.0.tar.gz
./config.sh --url https://github.com/OWNER/REPO --token YOUR_TOKEN

Після виконання конфігурації скрипт запитає ім'я ранера та теги (labels). Теги критично важливі для управління: ви можете позначити сервер як `production`, `gpu` або `high-performance`, щоб направляти конкретні задачі на потрібні вузли.

Налаштування Docker-in-Docker та робота з контейнерами

Більшість сучасних CI/CD пайплайнів використовують Docker для збірки образів або запуску тестів в ізольованих середовищах. Щоб github actions self hosted міг взаємодіяти з Docker, необхідно правильно налаштувати права доступу та встановити Docker Engine на хост-машину.

Встановлення Docker для ранера

sudo apt install -y docker.io
sudo usermod -aG docker github-runner
# Перезавантаження для застосування прав
sudo systemctl restart docker

Використання Docker на self-hosted ранері дає перевагу у вигляді локального реєстру образів. Якщо ви часто перезбираєте одні й ті ж мікросервіси, шари Docker будуть братися з локального кешу `/var/lib/docker`, що практично обнуляє час на `docker pull`. Для управління секретами та доступами до приватних реєстрів зручно використовувати self-hosted Bitwarden, інтегрований в процес збірки.

Безпека: Docker Socket vs Rootless

За замовчуванням ранер використовує `/var/run/docker.sock`. Це дає процесам всередині контейнера права root на хостовій машині. Якщо ваш CI/CD запускає код із зовнішніх Pull Request'ів, це створює ризик безпеки. В таких випадках рекомендується використовувати `Docker Rootless mode` або запускати ранер в режимі `ephemeral` (одноразовий), який видаляє всі дані після завершення задачі.

Порівняння з gitlab runner: архітектурні відмінності на VPS

Хоча архітектура GitHub Actions та GitLab CI схожа, gitlab runner пропонує більш гнучкі можливості масштабування на одному сервері. В GitLab один бінарний файл може управляти безліччю паралельних потоків збірки (executors).

Переваги GitLab Runner для CI/CD

• Executors: Можливість вибору між Shell, Docker, VirtualBox або Kubernetes прямо в конфігу ранера.
• Auto-scaling: GitLab Runner може автоматично створювати додаткові VPS при рості навантаження та видаляти їх після.
• Інтеграція: Глибокий зв'язок з Container Registry та Kubernetes кластерами.

Для стабільної роботи GitLab Runner на VPS рекомендується виділяти мінімум 2 ГБ RAM на кожен паралельний потік збірки (concurrent job). Якщо ви плануєте складну автоматизацію робочих процесів, розгляньте також self-hosted n8n для зв'язування CI/CD із зовнішніми API та сповіщеннями.

Безпека та ізоляція self hosted runner vps

Головний ризик використання self hosted runner vps — виконання довільного коду. Якщо зловмисник надішле Pull Request зі шкідливим кодом у `.github/workflows/build.yml`, він може отримати доступ до файлової системи сервера та ваших секретів (API-ключів, паролів БД).

Стратегії захисту сервера

1. Окрема VM: Ніколи не запускайте раннер на сервері, де працює основний продакшн. Використовуйте окремий інстанс VPS.
2. Обмеження прав: Запуск процесу раннера від користувача без привілеїв sudo.
3. Мережеве екранування: Налаштуйте Firewall (UFW) так, щоб дозволити тільки вихідні з'єднання до GitHub і заборонити вхідні на всі порти, крім SSH.
4. Регулярне очищення: Використовуйте Cron-задачі на VPS для автоматичного очищення старих Docker-образів і тимчасових файлів збірки.

Для очищення системи від сміття Docker можна додати наступне завдання в crontab:

0 3 * * * /usr/bin/docker system prune -af --volumes

Це буде щодня о 3 годині ночі видаляти невикористовувані дані, запобігаючи переповненню диска.

Оптимізація продуктивності: як вичавити максимум із заліза

Для досягнення 10-кратного прискорення недостатньо просто встановити actions runner. Необхідно оптимізувати саму структуру пайплайна.

Використання RAM-диска для тимчасових файлів

Якщо ваш проєкт генерує тисячі дрібних файлів під час компіляції, використання RAM-диска (tmpfs) може значно прискорити процес. Виділіть частину оперативної пам'яті під `/tmp` або специфічну папку збірки.

Локальний кеш залежностей

Замість стандартного `actions/cache`, який завантажує архіви з мережі, налаштуйте інструменти на використання локальних шляхів на диску VPS. Для Node.js це може бути глобальний кеш npm:

npm config set cache /home/github-runner/.npm --global

Це виключає мережеві затримки та навантаження на канал зв'язку.

Моніторинг та обслуговування інфраструктури

Self-hosted рішення потребує нагляду. Основні метрики для відстеження: вільне місце на диску, використання RAM і навантаження на CPU (Load Average).

Автоматичне оновлення раннера

GitHub автоматично оновлює бінарні файли раннера, але системні залежності (git, docker, python) потрібно оновлювати вручну або через скрипти автоматизації. Рекомендується налаштувати сповіщення про падіння процесу раннера. Найпростіший спосіб — використовувати systemd unit, який автоматично перезапустить сервіс у разі збою.

[Unit]
Description=GitHub Action Runner
After=network.target

[Service]
Type=simple
User=github-runner
WorkingDirectory=/home/github-runner/actions-runner
ExecStart=/home/github-runner/actions-runner/run.sh
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Така конфігурація гарантує, що ваш ci cd vps буде доступний 24/7. Для зберігання документації по ваших CI/CD процесах і конфігураціях серверів відмінно підійде self-hosted Nextcloud, де команда може спільно редагувати файли та інструкції.

Висновки

Для стабільної роботи CI/CD на базі GitHub Actions self-hosted runner найкраще підходить VPS з 4-8 ГБ RAM і NVMe-накопичувачем, що дозволяє скоротити час збірки в рази та повністю контролювати безпеку даних. Використання власного сервера знімає ліміти на безкоштовні хвилини та дає можливість глибокої оптимізації кешування для прискорення розробки.