Як Самостійно Розмістити GitLab CE на VPS

Це п’ятниця після обіду, запит на злиття твоєї команди чекає на перегляд, і твій ноутбук сповіщає знайомим повідомленням: з GitHub знову проблеми.

Можливо, дії зависли.

Можливо, `git push` видає помилку 500 вже третій раз цього місяця.

У твоєму командному чаті вже є вісім повідомлень.

Перший раз, коли це стається, ти смієшся з цього. Другий раз, хтось вставляє посилання на сторінку статусу GitHub, і ви всі йдете на каву. Третій раз, зазвичай саме перед вікном випуску, хтось нарешті вимовляє питання вголос: “Може нам просто запустити своє?”

Для більшості команд чесна відповідь — ні. GitLab.com Free зручно покриває потреби невеликих команд, а податок на операції з управління вашим власним сервером контролю версій не дорівнює нулю.

Це той вид обміну, який роблять лише зі справжньої причини.

Якщо у твоєї команди є одна з таких причин, як договір з клієнтом, який забороняє використання стороннього SaaS, межа відповідності, або рахунок за ліцензію на місця, який починає виглядати абсурдно, самостійне розміщення GitLab CE є найчистішим кроком, який ти можеш зробити. Він відкритого коду, працює на одному VPS і, після налаштування, обслуговування займає близько години на місяць.

У DreamHost ми розмістили безліч самокерованих серверів, і ми продовжуємо бачити певний шаблон: розробники, які досягають успіху з саморозміщеним GitLab, спочатку обирають правильний план, налаштовують Протокол безпечної оболонки (SSH) та підготовку Domain Name System (DNS) правильно, а потім стримують бажання продовжувати налаштовувати, коли це стабільно.

Чому Варто Розмістити GitLab На Власному Сервері, Замість Використання GitLab.com?

Ти самостійно розміщуєш GitLab, коли GitLab.com або GitHub.com не можуть задовольнити твої вимоги щодо конфіденційності, відповідності або контролю витрат. Для більшості інших команд кращим рішенням буде варіант розміщення.

Три реальні причини витримують перевірку:

1. Конфіденційність та суверенітет даних: Твій вихідний код зберігається на інфраструктурі, яку ти керуєш і оновлюєш за власним графіком. Немає доступу третіх сторін, немає спільної платформи, немає ризику витоку даних за межі твого власного сервера.
2. Відповідність вимогам: Регульовані галузі, такі як охорона здоров’я, фінанси та урядові структури, часто потребують контролю за резидентністю даних. Самостійно розміщений GitLab CE — це найпростіший спосіб зберегти код у контрольованій області. 
3. Контроль витрат на масштабування: GitLab.com стягує плату за кожного активного користувача. Згідно з сторінкою ціноутворення GitLab, Premium коштує $29 на користувача на місяць, тоді як ціни на Ultimate доступні лише за запитом. Команда з 50 осіб на Premium обходиться в $17,400 на рік до додавання доповнень. Самокерований VPS плюс година місячного обслуговування часто коштує менше.

Якщо ви команда з двох осіб без причин, пов’язаних з конфіденційністю або відповідністю, то правильним рішенням буде безкоштовний тариф GitLab. (Так, ми знаємо, що це звучить дивно від компанії, яка надає хостинг).

З самостійним хостингом ти обмінюєш щомісячну плату за SaaS на постійний оперативний час. Це варта обміна лише якщо у тебе є вагома причина для зміни.

Ось де ця опція має сенс, а де ні:

Сценарій	Найкращий варіант
Вимоги конфіденційності або відповідності	Самостійно розміщений GitLab CE
Команда більше ~30 активних користувачів	Самостійне розміщення часто дешевше
Код є вашою інтелектуальною власністю, і ви хочете зберігати його локально	Самостійно розміщений GitLab CE
Команда з 2-5 осіб, без потреб у відповідності	GitLab.com (безкоштовно)
Ви не хочете оновлювати сервер	GitLab.com

GitLab Community Edition безкоштовний за ліцензією відкритого коду у стилі MIT. Немає обмеження користувачів, немає базових функцій за замком, і немає запитів на покращення пакету. Вся платформа в твоєму розпорядженні.

Які Апаратні Вимоги До GitLab CE?

GitLab CE має чіткі апаратні пороги, і їх правильне налаштування робить різницю між швидким встановленням і тим, що буде постійно використовувати своп-пам’ять (дисковий простір, який використовує операційна система, коли заповнюється RAM).

Згідно з офіційними вимогами до встановлення GitLab, розмірність виражається в запитах за секунду, а не в фіксованих користувацьких рівнях. Опублікована базова лінія становить 8 vCPU та 16 ГБ RAM для до 1,000 користувачів (близько 20 запитів за секунду). Менші команди можуть працювати на меншому обладнанні, до офіційно задокументованого мінімуму в 2 ГБ RAM плюс 1 ГБ свопу для оцінки, хоча продуктивність падає нижче 4 ГБ.

Свіжий встановлений GitLab споживає близько 4-6 ГБ у режимі очікування. Як тільки починають виконуватися завдання CI/CD, використання пам’яті швидко зростає. Так що плануйте додатковий простір — або готуйтеся до уповільнення.

Що стосується сховища, офіційний базовий показник GitLab становить 40 GB плюс розмір репозиторію, але 50 GB є більш безпечною вихідною точкою на практиці. Репозиторії зростають, і накопичуються артефакти збірки. NVMe, швидший тип твердотільного сховища, робить помітну різницю в операціях Git та читанні кешу CI.

Ось як ці пороги відображаються на типи VPS хостингу DreamHost:

Сценарій Використання	Рекомендований RAM	Рівень VPS від DreamHost
Оцінка / особисте використання	4 GB RAM	Stack 4
Мала команда, легке використання	8 GB RAM	Stack 8
До ~1,000 користувачів (опублікована базова лінія GitLab)	16 GB RAM	Stack 16
Запуск CI/CD раннерів на тому ж сервері	+ 2-8 GB RAM до вашого рівня	Збільшення розміру (наприклад, Stack 16 → Stack 32)

Правильна відправна точка для більшості команд, які реалізують справжні CI/CD пайплайни, це Стек 16. Це здається надмірним, поки ти не побачиш, як розпочинається перша збірка, і одразу наростає навантаження на Sidekiq, Postgres та виконавець.

16 GB RAM забезпечують достатньо ресурсів для стеку сервісів GitLab (близько 4 до 6 GB в режимі очікування на стандартній інсталяції) та декілька CI робітників (1-2 GB кожен), які можуть працювати на повну потужність одночасно, не привертаючи уваги у чаті команди.

Як Підготувати Свій VPS До Встановлення GitLab?

Проведи 10 хвилин на підготовку — це окупиться відразу після перезавантаження. Просто слідуй цим крокам:

1. Підготуй VPS: Вибери Ubuntu 22.04 LTS або 24.04 LTS. Обидві підтримуються офіційними пакетами Omnibus від GitLab (універсальний інсталятор, що надається GitLab) і мають роки безкоштовних оновлень безпеки попереду.
   
2. Направ домен на IP сервера: Створи A запис (тип DNS запису, який відображає домен на IP адресу) і дай йому поширитися принаймні 15-30 хвилин перед встановленням. Без цього автоматичне налаштування SSL зазнає невдачі, оскільки орган сертифікації не матиме де провести валідацію.
   
3. Онови пакети: Підключись до VPS за допомогою `ssh root@your-server-ip` та виконай `sudo apt update && sudo apt upgrade -y`.
   
4. Встанови залежності: Виконай `sudo apt install -y curl openssh-server ca-certificates perl postfix`. Пакет `postfix` — це поштовий сервер, який обробляє вихідні електронні листи, так що GitLab може надсилати сповіщення про злиття запитів та скидання паролів.
   Коли інсталятор запитає про конфігурацію пошти, вибери Internet Site та використовуй свій домен. Це дозволить GitLab одразу надсилати пошту.
   Для продакшну: пропусти локальний postfix і налаштуй SMTP ретрансляцію у файлі gitlab.rb. IP VPS часто потрапляють у спам-блоклісти, і електронні листи з скиданням пароля, надіслані через локальний postfix, часто потрапляють у спам. SendGrid, Mailgun і вихідна ретрансляція DreamHost — все це працює — дивись документацію GitLab по налаштуванню SMTP.
   
5. Відкрий потрібні порти: Налаштуй файрвол за допомогою UFW (вбудованого інструменту файрвола Ubuntu) та дозволь порти 80, 443 та 22.

sudo ufw allow http
sudo ufw allow https
sudo ufw allow ssh
sudo ufw enable

Як Встановити GitLab CE На Ubuntu За Допомогою Omnibus Пакету?

Додайте репозиторій GitLab CE:

curl -sSL https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Потім встановіть GitLab CE, вказавши ваш домен як зовнішню URL-адресу:

sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

Встановлення `https://` тут повідомляє GitLab автоматично запитати сертифікат Let’s Encrypt під час установки, за умови, що порти 80 та 443 відкриті і DNS правильно налаштований. Якщо щось із цього не готове, установка завершується, але SSL не працює — і ти витрачаєш наступні тридцять хвилин на усунення неполадок, яких насправді немає.

Далі, чекай на крок переконфігурації.

GitLab запускає `gitlab-ctl reconfigure` (команду, яка застосовує будь-які зміни до конфігурації GitLab) автоматично наприкінці інсталяції. Це займає від п’яти до 10 хвилин. І так, крок переконфігурації дійсно триває так довго.

Отримай початковий пароль користувача Root:

sudo cat /etc/gitlab/initial_root_password

Цей файл створено автоматично і буде видалено через 24 години, тому запиши пароль і увійди. Відвідай свій домен у браузері, увійди як `root` і негайно зміни пароль.

Нарешті, перевірте інсталяцію.

На екрані привітання GitLab створи тестовий проект. Відправ commit на нього з твоєї локальної машини. Якщо відправлення пройде успішно і файл з’явиться в веб-інтерфейсі, установка здорова.

Якщо крок переконфігурації зависає, перевірте `tail -f /var/log/gitlab/reconfigure/*.log`. Саме там знаходиться фактична помилка.

Як Заблокувати Самостійно Розміщений Екземпляр GitLab?

GitLab поставляється з розумними налаштуваннями за замовчуванням, але вони налаштовані для відкритого спільнотного сервера, а не для приватного сервера твоєї команди. Проведи тут годину.

1. Вимкни відкриту реєстрацію. Відкрита реєстрація увімкнена за замовчуванням. У Адміністративній Зоні перейди до Налаштувань > Загальні > Обмеження реєстрації та вимкни прапорець «Реєстрація дозволена». Інакше будь-хто з URL зможе створити аккаунт.
2. Увімкни двофакторну автентифікацію. Перейди до Адміністративної Зони > Налаштування > Загальні > Обмеження входу та вимушено застосуй 2FA для всіх користувачів. Зменши період ласки зі стандартних 48 годин до 8 годин.
3. Обмеж створення проєктів. Встанови Створення Проєкту за Замовчуванням на Керівників або Нікого, залежно від того, наскільки закритою ти хочеш це зробити.
4. Перевір відновлення SSL. GitLab за замовчуванням автоматично відновлює сертифікати Let’s Encrypt. Щоб перевірити, виконай команду `sudo gitlab-ctl renew-le-certs` один раз і перевір результат.
5. Захисти SSH на самому VPS. Вимкни вхід за допомогою пароля root, дозволь лише аутентифікацію за допомогою SSH ключа, і (якщо можливо) перенеси SSH з порту 22. Самохостинговий Git сервер є настільки безпечним, наскільки безпечна платформа під ним.

Для детального вивчення GitLab опублікував Посібник з посилення безпеки, який охоплює аутентифікацію, шифрування та налаштування інстанції. Прочитай його один раз, застосуй те, що відповідає твоїй моделі загроз, і переходь далі.

Як Зробити Резервну Копію Та Відновити Самостійно Розміщений Екземпляр GitLab?

GitLab включає вбудований інструмент для резервного копіювання. Перший раз, коли ти його знадобишся, будеш радий, що налаштував його.

Створи резервну копію:

sudo gitlab-backup create

Це створює tarball у `/var/opt/gitlab/backups`. Заплануй його щодня через cron із терміном зберігання сім днів. Виконай sudo crontab -e та додай ці два рядки:

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
0 3 * * * find /var/opt/gitlab/backups -name "*.tar" -mtime +7 -delete

Прапор CRON=1 пригнічує вивід прогресу, щоб він не засмічував журнали Cron Job.

Професійна порада: резервна копія не включає `/etc/gitlab/gitlab-secrets.json` або `/etc/gitlab/gitlab.rb`.

Ці файли містять ключ шифрування бази даних, двофакторні насіння та змінні CI/CD. Конфігураційні секрети не входять до складу звичайного резервного копіювання та повинні зберігатися окремо. Відновлення даних без файлу секретів призводить до того, що рахунки з двофакторною автентифікацією перестають працювати, зашифровані змінні перетворюються на марнотратство, і ти проводиш довгий вечір, намагаючись зрозуміти чому.

Додай це до того ж Cron Job:

sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/

Резервна копія може бути відновлена лише до тієї ж версії та редакції (CE до CE, а не CE до EE) GitLab, на якій вона була створена.

Оновлюй обережно: не відновлюй стару резервну копію на свіжо встановлений GitLab без попередньої зміни версії встановлення, щоб вони відповідали одна одній.

Перевір процес відновлення хоча б раз. Резервна копія, яку ти ніколи не тестував, це просто файл.

Чи Дійсно Варто Розміщувати GitLab На Власному Сервері Для Твоєї Команди?

Самостійний хостинг GitLab є рішенням для контролю для більшості команд. Розрахунок вартості іноді виходить, але причина, через яку люди залишаються з самостійним хостингом, рідко є статтею витрат.

Ось чесна місячна вартість часу для встановлення невеликою командою:

• ~30 хвилин патчингу – оновлення apt, мінорні релізи GitLab
• ~15 хвилин перевірки резервного копіювання – не довіряй резервній копії, яку ти не відновив
• ~15 хвилин перевірки потужності – використання диску, запас RAM
• ~2x якщо CI/CD працює на машині – Зайнятий раннер може подвоїти навантаження

Це близько години на місяць у не дуже зайнятий тиждень, або двох у зайнятий.

Приблизно за 150 доларів за годину, 12 годин робочого часу обійдуться приблизно в 1800 доларів — це приблизно п’ять місць GitLab.com Premium.

Приклад з практики від Mad Devs демонструє, як їхня команда економить понад $10,000 на рік, використовуючи самостійно розміщений GitLab CE замість оплати за преміум-місця. Економія стає реальною лише тоді, коли команда настільки велика, що ліцензії на місця починають домінувати в бюджеті.

Зауважимо, самостійний хостинг є невірним вибором для:

• Команди з двох-трьох осіб без причин дотримання норм. GitLab.com Free підходить для тебе. Час виконання більший, ніж заощаджені витрати.
• Команди, де ніхто не вміє користуватися командним рядком. “Вміння користуватися” не означає рівень системного адміністратора. Це означає, що ти можеш читати помилки в `/var/log/gitlab` без паніки.
• Команди, для яких головна перешкода — наймання, а не інструментарій. Самостійне хостингування відволікає увагу від продукту. Якщо швидкість розробки продукту є обмеженням, хостинг є правильним рішенням.

Отже, коли самостійне хостинг має сенс? Нижче наведено кілька сценаріїв:

• Регульовані індустрії з чіткими вимогами до резидентності даних або ланцюга постачання
• Команди ЄС/Великої Британії з побоюваннями щодо суверенітету відносно коду, розміщеного в США
• Команди від 30+ осіб де ліцензії на місця домінують в бюджеті
• Клієнтські контракти, які забороняють використання стороннього SaaS для вихідного коду

Якщо твоя причина “GitHub стягує плату за місце,” ти, ймовірно, виграєш. Якщо твоя причина “Я хочу відчувати контроль,” ти можеш знайти оперативну реальність менш романтичною, ніж очікувалось.

Чи Варто Запускати GitLab CI/CD Runners На Тій Самій VPS?

Для оцінки, так. Для виробництва, ні.

CI runner на тому ж сервері забирає пам’ять та CPU у GitLab UI. Класичний симптом — “GitLab працює повільно о 9 ранку”, що зазвичай пов’язано з запуском першого ранкового пайплайну, який відбирає ресурси у веб-frontend. Кращим рішенням є окремий малий VPS (або DreamCompute інстанс) для runner, зареєстрований у інстансі GitLab через мережу.

Якщо тобі потрібно тримати запускачі на тому самому сервері, збільш потужність VPS до 16 GB.

Згідно з системними вимогами раннера GitLab, сам процес раннера є легким. Проте завдання, які він виконує, — ні, і вони ділять ресурси процесора та диска комп’ютера з усім іншим, що робить GitLab.

Готовий Зробити Перехід?

Повернення до п’ятничного вечірнього чату команди.

Якщо GitHub стає жовтим і твоя команда знову сміється з цього та йде за кавою, то це нормально.

А якщо збої GitHub почнуть відчуватися серйозно?

Можливо, це загрожує контракту з клієнтом? З’являється під час перевірки дотримання норм? Або рахунок за ліцензію на місця нарешті перетнув межу?

Самостійне хостинг GitLab CE починає ставати цілком розумним варіантом. Все, що потрібно, це VPS, домен, Omnibus інсталяція та година на зміцнення.

До наступного разу, коли статусна сторінка GitHub загориться, твій код продовжить безперешкодно виконуватися.

Часті Запитання Про Самостійне Розміщення GitLab

Чи є щось ще, що ти хочеш дізнатися про самостійне розміщення GitLab на VPS? Нижче наведено відповіді на деякі поширені запитання.

Чи є GitLab CE безкоштовним для самостійного хостингу?

Так, GitLab CE є безкоштовним для самостійного хостингу за ліцензією відкритого коду стилю MIT. Немає обмеження за кількістю користувачів та вартості за місце. Єдині витрати – це сам VPS та оперативний час для його обслуговування.

VPS Stack 4 від DreamHost — це розумний вибір для початку оцінювання. Виробничі команди зазвичай використовують Stack 8 або Stack 16.

Скільки RAM насправді потрібно GitLab CE?

Плануйте 16 ГБ RAM для до 1000 користувачів, що є базовим показником GitLab (близько 20 запитів за секунду). Менші команди можуть працювати на меншій кількості, до зазначеного мінімуму 2 ГБ плюс 1 ГБ свопу для оцінки. Так чи інакше, якщо ви використовуєте CI/CD пайплайни на тій же машині, плануйте 16 ГБ.

Чи можу я самостійно розмістити GitLab на VPS з 4 GB?

Так, ти можеш запустити GitLab CE на 4 ГБ, але воно буде працювати повільно під будь-яким реальним навантаженням. Документація GitLab зазначає резервну конфігурацію 2 ГБ + 1 ГБ своп для середовищ з обмеженою пам’яттю — цей шлях призначений для оцінки, а не для виробництва. Для команди, яка активно вносить код та виконує пайплайни, практичний мінімум становить 8 ГБ.

Скільки часу займає встановлення GitLab CE на VPS?

Близько 10-15 хвилин на встановлення пакету, плюс приблизно година на підготовку та посилення захисту, так що загалом близько 90 хвилин від початку до кінця. Встановлення саме по собі здебільшого полягає в очікуванні на етапі переконфігурації.

Процес посилення захисту, що включає вимкнення відкритої реєстрації, впровадження двофакторної автентифікації та обмеження створення проектів, займає решту часу і є обов’язковим для будь-якого виробничого екземпляру.

Чи варто самостійно хостити GitLab для команди з п’яти осіб?

Ймовірно, ні, якщо у тебе немає причин, пов’язаних з конфіденційністю або вимогами відповідності. GitLab.com Free надає до п’яти користувачів з необмеженою кількістю приватних проектів та 400 хвилинами CI/CD на місяць. Оперативний час самостійного хостингу переважає заощадження вартості за місце при такому розмірі команди.

Самостійний хостинг починає окупатися в чистих витратах приблизно з 30+ активних користувачів.

У чому різниця між GitLab CE та GitLab Community Edition?

GitLab CE та GitLab Community Edition — це один і той же продукт. CE — це стандартна абревіатура. Термін “Самостійно кероване” стосується місця, де ви його запускаєте (ваша інфраструктура), а не редакції.

GitLab Community Edition є відкритим кодом. GitLab Enterprise Edition (EE) додає платні функції на тій же кодовій базі.

Чим GitLab CE відрізняється від GitLab EE?

GitLab CE — це безкоштовне видання з відкритим кодом. GitLab EE використовує ту ж базу коду, плюс платні функції, які активуються, коли ти завантажуєш файл ліцензії.

Практична різниця полягає в наступному:

• CE ліцензований MIT і повністю функціональний. Контроль версій, об’єднання запитів, проблеми, базовий CI/CD, реєстр контейнерів, все що потрібно.
• EE додає корпоративні функції за ліцензією. Думай про епіки, передові рамки відповідності, аналітику цінностей потоків, кілька правил схвалення та передове сканування безпеки. Згідно з порівнянням функцій самостійного управління GitLab, різниця має значення здебільшого для організацій з формальними процесами управління змінами.
• Можеш встановити EE без ліцензії, і воно функціонує як CE до моменту ліцензування. Так більшість команд застраховується від майбутньої потреби у оновленні.
• Ти не можеш чисто змінити EE на CE. Плануй відповідно.

Для більшості команд, які самостійно розміщують хостинг, CE є достатнім. Якщо ваша причина — конфіденційність або вартість, функції EE рідко змінюють обрахунки.

Як я можу оновлювати свою самостійно розміщену інстанцію GitLab?

Виконай `sudo apt update && sudo apt upgrade gitlab-ce`, щоб застосувати патчі безпеки. Місячний цикл є практичним мінімумом для продакшн-інстанції. Завжди створюй резервну копію перед оновленням.

Оновлення до основної версії має здійснюватися послідовно — не можна пропускати основні версії. Перехід з 16.x до 18.x вимагає спочатку оновлення до 17.x, а потім до 18.x. Пропуск основної версії призведе до порушення міграції баз даних. Завжди перевіряй інструмент шляху оновлення GitLab перед оновленням та створюй резервну копію безпосередньо перед кожним кроком.

Яке місце DreamHost займає у самостійно розміщеному GitLab?

VPS Hosting DreamHost забезпечує сервер Linux з root-доступом, на який встановлюється GitLab CE. План Stack 16 (16 GB RAM) відповідає офіційним вимогам GitLab для до 1,000 користувачів, з запасом для активних CI/CD пайплайнів.