Хостинг GitLab Runner на машині, яка належить вам
Самокерований runner у Празі чи Ковільяні, якому належить увесь диск, тож кеш шарів Docker ще на місці на другому конвеєрі за день, а рахунок не змінюється, коли змінюється збірка.
Для кого це
Команда, що купує обчислювальні хвилини
Набір тестів виріс, тож конвеєр подовшав, тож рахунок піднявся - і єдиний важіль, який пропонує тариф, це купити ще більше точно таких самих хвилин.
Конвеєр, якому потрібна та сама машина двічі
Кожне завдання стартує з порожнього диска. Базовий образ завантажується знову, залежності тягнуться знову, а вивантаження кешу триває довше за крок, який він мав зекономити.
Репозиторій під вимогою резидентності
Код, артефакти й ключі розгортання проходять через runner, а "спільний парк машин десь там" - це відповідь, яку ваш аудитор раз за разом обводить червоним.
Що повертає вам самокерований runner
- Теплий кеш шарів Docker на локальному NVMe, тож другий конвеєр за день починається там, де закінчився перший, а не з порожнього диска.
- Будь-який executor на ваш смак - docker, shell, docker-autoscaler, instance або kubernetes - обраний для кожного runner, а не виданий тарифом.
- Власна паралельність, задана числом у config.toml, а не куплена як наступний щабель.
- Привілейований режим, коли вам справді потрібен Docker-in-Docker, чого жоден спільний парк машин вам ніколи не дасть.
- Статична вихідна IPv4 з AS204057, щоб ціль розгортання, дзеркало пакетів або фаєрвол бази даних міг дозволити runner за адресою.
- Те, що збірці справді потрібно на хості: старий набір інструментів, ліцензований SDK або набір тестових даних, який ніхто не хоче завантажувати щоразу.
Розмір за тим, що конвеєр робить насправді
GitLab не публікує апаратних вимог до самого runner, і це не недогляд: процес runner малий, а збірка - ні. Значення має завдання. Візьміть найважче завдання, яке виконуєте сьогодні, помножте на потрібну паралельність і не шкодуйте диска - його заповнюють кеш шарів і робочий каталог, а повний диск валить конвеєр так, що це схоже на зламаний тест. Одного фіксований місячний хост не робить: він не зникає у спокійний тиждень. Хвилини у провайдера нічого не коштують, коли ніхто не пушить, а це коштує так само. Воно окупається з моменту, коли конвеєр працює майже щодня.
Як встановити GitLab Runner на новому хості
Debian або Ubuntu, з чистого сервера, у порядку, який документує GitLab. Усе нижче - їхня послідовність, не наша.
-
Додайте офіційний репозиторій пакетів
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" -o script.deb.sh less script.deb.sh sudo bash script.deb.shGitLab постачає репозиторій як сценарій встановлення і просить прочитати його перед запуском - саме тому їхня власна інструкція спершу завантажує його, а не передає одразу в оболонку.
-
Встановіть runner
sudo apt install gitlab-runnerПакет створює системного користувача gitlab-runner, домашній каталог якого створюється порожнім, без файлів-шаблонів. Щоб зафіксувати версію, встановіть gitlab-runner і gitlab-runner-helper-images разом однієї версії - від 17.7.1 вони йдуть парою, і згадка лише одного завершується помилкою залежностей.
-
Встановіть Docker, якщо завдання виконуються в контейнерах
sudo apt install docker.io sudo systemctl enable --now dockerExecutor docker спілкується з локальним Docker Engine через API v1.25, тож демон має бути на самому хості runner. Пакета з дистрибутива достатньо для початку; власний репозиторій Docker містить новіші випуски, якщо якійсь збірці вони потрібні.
-
Зареєструйте runner
sudo gitlab-runner register \ --non-interactive \ --url "https://gitlab.com/" \ --token "$RUNNER_TOKEN" \ --executor "docker" \ --docker-image alpine:latest \ --docker-pull-policy "if-not-present" \ --description "docker-runner"Спершу створіть runner у GitLab, у Settings, потім CI/CD, потім Runners - він поверне токен автентифікації, що починається з glrt- і йде у --token. Теги завдань і параметр для завдань без тегів задайте в тій самій формі: з токенами автентифікації вони належать runner, а не команді register. Старіший шлях із --registration-token застарілий і запланований до видалення в GitLab 20.0.
-
Задайте паралельність і запустіть
sudo sed -i "s/^concurrent = .*/concurrent = 4/" /etc/gitlab-runner/config.toml sudo gitlab-runner restart sudo gitlab-runner statusconfig.toml лежить у /etc/gitlab-runner, коли runner працює від root. concurrent - це стеля для всіх runner, зареєстрованих на цьому хості, а не налаштування для кожного окремо, і кожен runner може мати під нею власний, нижчий ліміт.
-
Перевірте це одним завданням
stages: [test] smoke: stage: test tags: [docker-runner] script: - cat /etc/os-release - echo "built on $CI_RUNNER_DESCRIPTION"Закомітьте це як .gitlab-ci.yml, запуште, і завдання має потрапити на ваш хост за кілька секунд. Якщо воно лишається в черзі, теги не збігаються з тими, що ви задали в інтерфейсі, або runner прив'язаний до іншого проєкту.
Звірено з офіційною документацією 2026-08-15 — читати першоджерело
Чим ми не є
- Ми не GitLab. GitLab, GitLab CI/CD і GitLab Runner належать їм, і ніщо на цій сторінці ними не схвалене. Ми продаємо машину, на якій працює runner.
- Ця сторінка не про хостинг самого GitLab. Самокерований екземпляр GitLab - це більша машина й інша розмова; запитайте, і ми її підберемо, але тут оцінена не вона.
- Ми не пишемо ваш .gitlab-ci.yml. Конвеєр ваш; хост, мережа й адреса - наші.
- Runner не обслуговується за вас, якщо ви цього не попросите. Ви встановлюєте його самі або додаєте нашу послугу адміністрування, і ми тримаємо його оновленим, зареєстрованим і під наглядом.
- Ваша підписка GitLab лишається в GitLab. Самокерований runner не витрачає їхніх обчислювальних хвилин, у цьому й суть, але й ліцензій користувачів він не замінює.
Частини, які команди виявляють запізно
- Шлях із реєстраційним токеном іде у минуле. Runner, створений в інтерфейсі, повертає токен автентифікації glrt-, який gitlab-runner register приймає як --token, а --registration-token запланований до видалення в GitLab 20.0.
- Теги пішли разом із ним. З токеном автентифікації теги завдань, параметр без тегів і прив'язка належать об'єкту runner, створеному в інтерфейсі, тож прапорці, які колись задавали їх у командному рядку, більше нічого не вирішують.
- Зафіксувати версію означає зафіксувати два пакети. Від 17.7.1 явна версія gitlab-runner потребує ще й gitlab-runner-helper-images тієї ж версії, інакше apt відмовляє у встановленні.
- check_interval типово дорівнює 3 секундам. На хості з багатьма зареєстрованими runner це дуже багато опитувань; підніміть значення, перш ніж звинувачувати мережу.
- Docker-in-Docker потребує привілейованого режиму, що фактично дає завданню root на хості. Якщо конвеєр лише збирає образи, безкореневий збирач на кшталт Kaniko чи Buildah - дешевший обмін.
- Артефакти й кеші і далі мандрують до GitLab, доки ви не спрямуєте кеш у власний S3-сумісний бакет. На runner, який ви свідомо перенесли до ЄС, це зазвичай останній перехід, що лишився перенести.
Хвилини CI у провайдера проти власного runner
| Хвилини CI на боці провайдера | Раннер на DCXV | |
|---|---|---|
| За що ви платите | За кожну хвилину кожного завдання, доки існує проєкт | За фіксований місячний хост, хоч би що конвеєр робив того місяця |
| Збірка, що сповільнюється | Коштує більше кожного місяця, поки лишається повільною | Не коштує нічого більше - машина вже оплачена |
| Кеш шарів Docker | Холодний на кожному завданні, якщо ви самі його не вивантажите й не завантажите | Теплий на локальному NVMe, між завданнями і між днями |
| Паралельність | Щабель тарифу, який підвищують | Число, яке ви задаєте у власному файлі конфігурації |
| Куди потрапляє checkout | На спільний парк машин, часто в регіоні, який неможливо зафіксувати | На одну машину в Празі чи Ковільяні, за кіпрським договором |
| Вихідна адреса | Величезний спільний діапазон, який нічим не дозволити | Одна статична IPv4 з AS204057, ваша, щоб її дозволяти |
| Що може вмістити машина | Те, що випадково несе образ runner | Будь-який набір інструментів, ліцензію чи набір тестових даних, встановлений один раз |
Як це запускається на вашому хості
Скажіть, що робить конвеєр
Найважче завдання, яке ви виконуєте сьогодні, скільки їх має йти одночасно і чи збирає воно образи контейнерів. Цього досить, щоб підібрати хост без здогадок.
Ми передаємо машину
Прага чи Ковільян, доступ root і статична IPv4, менш ніж за десять хвилин. Принесіть власний образ, якщо runner уже всередині нього.
Виконайте покрокову інструкцію з цієї сторінки
Це послідовність від виробника, взята з його чинної документації, а не з допису в блозі, і на чистому хості вона займає кілька хвилин.
Зробіть знімок, а тоді додайте другий
Зробіть знімок, щойно перший конвеєр стане зеленим, щоб наступна машина була відновленням, а не побудовою з нуля. Пул росте додаванням хостів, а не роздуванням одного.
Чому обирають нас
- Сертифіковані об'єкти Tier III, SLA об'єкта 99.982%
- Власна мережа, AS204057, IPv4 та IPv6
- Підтримка 24/7/365 із середнім часом відповіді близько 10 хвилин
- Компанія на Кіпрі, юрисдикція ЄС, відповідність GDPR з 2007 року
FAQ
- Чим спільний runner відрізняється від самокерованого?
Спільний runner - це машина GitLab, і ви платите за хвилини, які вона витрачає на ваше завдання. Самокерований runner - це ваша машина: ви встановлюєте на неї gitlab-runner, реєструєте її для свого проєкту, групи чи екземпляра, і вона не витрачає обчислювальних хвилин узагалі. Простори імен на безкоштовному тарифі GitLab отримують 400 обчислювальних хвилин на місяць, і жвавий конвеєр проходить крізь них за дні
- Як встановити й зареєструвати GitLab Runner?
Додайте їхній репозиторій apt зі сценарію встановлення на packages.gitlab.com, встановіть пакет gitlab-runner, а тоді запустіть gitlab-runner register у неінтерактивному режимі з токеном автентифікації, який GitLab видає при створенні runner в інтерфейсі. Повна послідовність із точними командами є на цій сторінці, взята з їхньої документації, а не з допису в блозі
- Чи все ще реєструють runner реєстраційним токеном?
Ні, і саме ця зміна ламає більшість старих посібників. Спершу створіть runner в інтерфейсі GitLab, і він поверне токен автентифікації, що починається з glrt-, який gitlab-runner register приймає як --token. Старий шлях із --registration-token застарілий і запланований до видалення в GitLab 20.0. Теги завдань, параметр без тегів і прив'язка тепер належать об'єкту runner, створеному в інтерфейсі, а не команді register
- Якого розміру сервер потрібен GitLab Runner?
GitLab не публікує апаратних вимог до самого runner, бо процес runner малий, а ваша збірка - ні. Підбирайте за найважчим завданням, помноженим на потрібну паралельність. На практиці 4 vCPU, 8 ГБ і 120 ГБ NVMe тягнуть два-три завдання одночасно; 8 vCPU, 16 ГБ і 240 ГБ тягнуть від шести до восьми. Не шкодуйте диска - його заповнюють кеш шарів Docker і робочий каталог
- Чи потрібен Docker на хості runner?
Лише якщо ви користуєтеся executor docker, а так робить більшість. Він спілкується з локальним Docker Engine через API v1.25, тож демон має бути встановлений на самому хості runner. Executor shell не потребує Docker узагалі, а executor instance і docker-autoscaler створюють машини деінде
- Чи можуть кілька runner ділити один хост?
Так, і це звичайна форма. Реєструйте скільки завгодно на одній інсталяції; налаштування concurrent у /etc/gitlab-runner/config.toml є стелею для них усіх, і кожен runner може мати під нею власний, нижчий ліміт. Стежте за check_interval, типово 3 секунди, який перетворюється на дуже багато опитувань, щойно хост несе десяток runner
Якщо вам потрібна допомога або у вас виникли додаткові питання, будь ласка, звертайтеся до менеджерів або напишіть у службу підтримки за адресою support@dcxv.com
Готові розпочати?
Оплата щомісяця, без плати за підключення, без прив'язки