Виділені сервери для GitLab™
GitLab Self-Managed і CI/CD-ранери на bare metal
Розгорніть GitLab Self-Managed на виділеному сервері з NVMe-накопичувачами, а CI/CD-завдання винесіть на окремі сервери-раннери в приватній VLAN. Ці самі сервери підходять для GitLab Runner і self-hosted раннерів GitHub Actions.
GITLAB – товарний знак GitLab Inc. у США та інших країнах і регіонах.
-
NVMe-накопичувачі для репозиторіїв -
Високочастотні CPU для CI-збірок -
Приватна VLAN на 10–25 Гбіт/с -
Root-доступ і IP-KVM
AMD Zen 5 до 5,7 ГГц
Безлімітний трафік
NVMe класу enterprise
Пам'ять DDR5 ECC
Апаратні вимоги GitLab і GitLab Runner
Базовий мінімум для одновузлового інстанса GitLab – 8 vCPU і 16 ГБ пам’яті. На виділеному сервері це 4–6-ядерний CPU з 8–12 потоками. Під навантаженням swap уповільнює GitLab, тому 32 ГБ залишають запас для фонових завдань і зростання.
Закладіть 40 ГБ на систему та PostgreSQL плюс повний обсяг усіх репозиторіїв. Gitaly – сервіс зберігання репозиторіїв – активно навантажує диски і вимагає SSD, а не мережевих файлових систем. Тому стандартна схема – два NVMe-накопичувачі в RAID 1.
Хмарні інстанси та диски з burst-режимом погано підходять для GitLab: коли квоту вичерпано, їхня швидкість падає. У виділеного сервера немає квот і сусідів на тому ж залізі. Провайдер ніколи не обмежує його ядра та NVMe-накопичувачі.
CI/CD-завдання краще запускати на окремому сервері, а не на інстансі GitLab. Тоді важка збірка не сповільнить Git, веб-інтерфейс і рев’ю коду. А код пайплайнів не виконуватиметься поруч із вашими репозиторіями.
Компіляторам, тестам і збірці образів важлива продуктивність одного ядра, тому висока частота прискорює кожне завдання. Кількість ядер визначає, скільки завдань виконується паралельно. Кожному завданню потрібна своя пам’ять, а шари Docker і кеші зберігаються на NVMe раннера.
Ранери забирають код, образи та артефакти з інстанса по приватній VLAN на швидкості до 25 Гбіт/с. Повний Docker-образ приходить за секунди, а не за хвилини. Публічний порт залишається вільним для команди: push у Git, merge requests і вебінтерфейс не чекають, поки відпрацює пайплайн.
Ціни на виділені сервери для GitLab і раннерів
Усі конфігурації
Орендуйте виділений сервер для GitLab
в INTROSERV
Як замовити виділений сервер
Виберіть конфігурацію, додайте NVMe-накопичувачі та ОС. Дочекайтеся готовності сервера та встановіть GitLab.
Читати документацію
Встановлення та захист одно-вузлового інстансу GitLab
Покрокова установка GitLab Self-Managed з офіційного Linux-пакета з налаштуванням HTTPS і першим входом.
Читати керівництвоСервери та інфраструктура для GitLab від одного провайдера
-
1
Встановіть GitLab на сервер інстанса
Встановіть GitLab Self-Managed з офіційного Linux-пакета на NVMe з вбудованими PostgreSQL і Redis. Потім налаштуйте HTTPS, вихідну пошту та container registry.
-
2
Підключіть сервери-ранери до VLAN
Замовте сервери для раннерів у тому ж дата-центрі та об’єднайте їх приватною VLAN на швидкості до 25 Гбіт/с. Завдання забирають код, образи й артефакти через VLAN, а не через публічний порт.
-
3
Зареєструйте ранери
Встановіть GitLab Runner з Docker executor і зареєструйте його на своєму інстансі. Для репозиторіїв на GitHub на тих самих серверах працюють self-hosted раннери GitHub Actions.
-
4
Налаштуйте бекапи через INTROSERV Backup Service
Робіть бекап усього сервера інстанса через INTROSERV Backup Service – це ПЗ NAKIVO та сховище в одному готовому сервісі. За потреби відновіть увесь сервер або окремий файл.
Ліцензування та підтримка GitLab
Ліцензування
Рекомендуємо встановлювати GitLab Enterprise Edition. Без ліцензії він працює на безкоштовному тарифі, а Premium або Ultimate можна ввімкнути пізніше кодом активації без перевстановлення. Community Edition – open source альтернатива під ліцензією MIT з тими ж безкоштовними функціями. Ліцензії та підписки придбаваються у GitLab Inc. або партнерів.
Підтримка
Підтримку самого GitLab надають форум і документація GitLab, а при платній підписці – GitLab Inc. INTROSERV відповідає за Linux-сервери, на яких працює GitLab: моніторинг, безпека, оновлення ОС та усунення інцидентів за тарифом адміністрування. Разові завдання – в межах погодинного системного адміністрування.
FAQ
-
Як швидко надається сервер?
Конфігурації з миттєвою видачею готові через 3–6 годин після оплати. Індивідуальні збірки – зазвичай протягом 24 годин. Термін видачі вказано біля кожної конфігурації в каталозі.
-
Чи можна спочатку протестувати сервер?
Так. Доступний платний тестовий період до 5 днів. Цього достатньо, щоб встановити GitLab, відправити репозиторій і запустити перший пайплайн.
-
Яку ОС обрати?
Дистрибутив Linux, який підтримує офіційний пакет GitLab, наприклад Ubuntu LTS або Debian. Пакет уже включає PostgreSQL, Redis і вебсервер, тому більше нічого встановлювати не потрібно.
-
Чи можна використовувати свій домен і HTTPS-сертифікат?
Так. Направте DNS-запис на сервер – пакет GitLab сам випустить і буде продовжувати сертифікат Let’s Encrypt. Замість нього можна встановити сертифікат іншого центру сертифікації.
-
Чи можна запустити GitLab Pages на тому ж сервері?
Так. Pages працює як окремий сервіс, і йому потрібен wildcard-запис DNS. Для власних доменів у Pages також потрібна друга IP-адреса – її можна додати до сервера.
-
Що буде, якщо NVMe-накопичувач вийде з ладу?
За наявності двох дисків у RAID 1 GitLab продовжить працювати на диску, що залишився. Ви відкриваєте тикет у службу підтримки, INTROSERV замінює диск у дата-центрі, і масив відновлюється.
-
Чи можна пізніше додати сервери для раннерів?
Так. Замовте ще один сервер у тому ж дата-центрі, додайте його до наявної VLAN і зареєструйте на інстансі. Пайплайни почнуть його використовувати, щойно він буде в мережі.
-
Чи можна пізніше розширити сховище?
На конфігураціях DC1, DC2 і DC3 – так: накопичувачі у вільні слоти додаються за тикетом, щомісячна вартість змінюється відповідно. Для інших конфігурацій краще одразу обрати дискову схему із запасом.
