Как самостоятельно разместить GitLab CE на VPS

Пятница день, запрос на слияние от твоей команды ожидает проверки, и твой ноутбук издаёт знакомый звук: у GitHub снова проблемы.

Возможно, действия застряли.

Возможно, `git push` возвращает ошибку 500 в третий раз за этот месяц.

В твоём чате команды уже восемь сообщений.

В первый раз это происходит, ты смеешься. Во второй раз кто-то прикрепляет страницу статуса GitHub, и все идут за кофе. В третий раз, обычно непосредственно перед окном выпуска, кто-то наконец задаёт вопрос вслух: «Может, нам стоит запустить своё?»

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

Это тот вид сделки, который заключают только по настоящей причине.

Если у твоей команды есть одна из этих причин, например, договор с клиентом, который запрещает использование стороннего SaaS, требования соответствия или счет за лицензию, который начинает выглядеть абсурдно, самостоятельное размещение GitLab CE — это наиболее разумное решение. Это открытое ПО, работает на одном VPS и, после настройки, обслуживание занимает около часа в месяц.

В DreamHost мы размещали бесчисленное количество самоуправляемых серверов и наблюдали закономерность: разработчики, успешно использующие самостоятельно размещенный GitLab, изначально выбирают подходящий тариф, правильно настраивают Протокол безопасной оболочки (SSH) и систему доменных имен (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 на постоянное операционное время. Это стоит того, только если у тебя есть веская причина для перехода.

Вот где этот вариант имеет смысл и где нет:

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

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

Каковы Системные Требования для GitLab CE?

GitLab CE имеет чёткие пороговые значения аппаратных средств, и правильный выбор этих значений — это разница между быстрой установкой и установкой, которая тормозит из-за использования своп-памяти (дисковое пространство, которое операционная система использует, когда заполняется оперативная память).

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

Свежая установка GitLab потребляет примерно 4-6 ГБ в режиме ожидания. Как только начинают выполняться задания CI/CD, потребление памяти резко возрастает. Поэтому позаботься о запасе мощности — или будь готов к замедлению.

Что касается хранилища, официальный базовый уровень GitLab составляет 40 ГБ плюс размер репозитория, но 50 ГБ — более безопасная отправная точка на практике. Репозитории растут, а артефакты сборки накапливаются. NVMe, более быстрый тип твердотельного хранилища, заметно влияет на операции Git и чтение кэша CI.

Вот как эти пороги соответствуют уровням VPS хостинга DreamHost:

Пример Использования	Рекомендуемый Объем RAM	Уровень VPS DreamHost
Оценка / личное использование	4 GB RAM	Stack 4
Маленькая команда, легкое использование	8 GB RAM	Stack 8
До ~1000 пользователей (базовый уровень GitLab)	16 GB RAM	Stack 16
Запуск исполнителей CI/CD на том же сервере	+ 2-8 GB RAM сверх вашего уровня	Увеличить размер (например, с Stack 16 на Stack 32)

Правильная отправная точка для большинства команд, работающих с реальными CI/CD конвейерами, — это Stack 16. Это может показаться излишним, пока ты не увидишь, как запускается первая сборка, и одновременно увеличиваются нагрузки на Sidekiq, Postgres и исполнителя.

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

Как Подготовить Твой 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 все работают — см. документацию по настройке SMTP GitLab.
   
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) в конце установки. Это занимает от пяти до десяти минут. И да, этап переконфигурации действительно занимает столько времени.

Получи начальный пароль root:

sudo cat /etc/gitlab/initial_root_password

Этот файл создается автоматически и будет удален через 24 часа, поэтому запиши пароль и войди в систему. Посети свой домен в браузере, войди как `root` и сразу же смени пароль.

Наконец, проверь установку.

На начальном экране GitLab создай тестовый проект. Отправь коммит в него с твоего локального компьютера. Если отправка прошла успешно и файл появился в веб-интерфейсе, установка прошла нормально.

Если шаг переконфигурации зависает, проверь `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 спамом.

Совет профессионала: резервное копирование данных не включает `/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
• ~в 2 раза больше, если CI/CD работает на этом сервере – Загруженный раннер может удвоить нагрузку

Это около часа в месяц в спокойную неделю или два в загруженную.

Примерно за 150 долларов в час, 12 часов работы обходятся примерно в 1800 долларов — это примерно пять премиальных мест на GitLab.com.

Практическое исследование от Mad Devs рассказывает о том, как их команда экономит более 10 000 долларов в год, используя собственный GitLab CE вместо оплаты премиальных мест. Экономия становится заметной, только когда команда настолько велика, что лицензии на места начинают доминировать в бюджете.

Тем не менее, самостоятельный хостинг не подходит для:

• Команды из двух-трёх человек без особых требований к соблюдению стандартов. GitLab.com Free подходит вам. Время работы больше, чем экономия на затратах.
• Команды, в которых никто не чувствует себя уверенно в командной строке. «Уверенно» не означает уровень системного администратора. Это значит, что ты можешь читать ошибки в `/var/log/gitlab` без паники.
• Команды, для которых основная проблема — найм сотрудников, а не инструментарий. Самостоятельное хостинговое обслуживание отвлекает от продукта. Если скорость разработки продукта является ограничивающим фактором, то размещенный хостинг — правильное решение.

Итак, когда имеет смысл самостоятельный хостинг? Ниже приведены несколько сценариев:

• Регулируемые отрасли с явными требованиями к месту хранения данных или цепочке поставок
• Команды ЕС/Великобритании с опасениями суверенитета по поводу кода, размещённого в США
• Команды из 30+ человек, где стоимость лицензий занимает значительную часть бюджета
• Договоры с клиентами, запрещающие использование стороннего SaaS для исходного кода

Если твоя причина в том, что «GitHub взимает плату за место,» скорее всего, ты окажешься в выигрыше. Если твоя причина в том, что «Я хочу контролировать ситуацию,» ты можешь обнаружить, что операционная реальность менее романтична, чем ожидалось.

Стоит ли запускать GitLab CI/CD Runners на том же VPS?

Для оценки, да. Для производства, нет.

CI runner на том же сервере отнимает память и CPU у интерфейса GitLab. Классический симптом — «GitLab чувствуется медленным в 9 утра», что обычно связано с запуском утреннего первого конвейера, который лишает ресурсов веб-интерфейс. Более чистое решение — это отдельный небольшой VPS (или инстанс DreamCompute) для runner, зарегистрированный в экземпляре GitLab через сеть.

Если тебе нужно оставить запущенные процессы на том же сервере, увеличь объём VPS до 16 ГБ.

Согласно системным требованиям runner от GitLab, сам процесс runner достаточно лёгкий. Однако выполняемые им задачи нет, и они разделяют ресурсы процессора и диска с всем остальным, что делает GitLab.

Готов Сделать Переключение?

Возвращение к пятничному дневному обсуждению команды.

Если GitHub становится жёлтым, и твоя команда снова смеётся над этим и идёт за кофе, то это нормально.

Но что, если проблемы с доступностью GitHub начнут казаться серьёзными?

Возможно, это угрожает контракту с клиентом? Возникает во время проверки соответствия? Или счёт за лицензионные места наконец перешёл все границы?

Самостоятельный хостинг GitLab CE начинает быть вполне разумным вариантом. Всё, что нужно, это VPS, домен, установка Omnibus и час на укрепление безопасности.

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

Часто Задаваемые Вопросы О Самостоятельном Размещении GitLab

Есть ли что-то еще, что ты хочешь узнать о самостоятельном размещении GitLab на VPS? Ниже приведены ответы на некоторые часто задаваемые вопросы.

Бесплатен ли GitLab CE для самостоятельного хостинга?

Да, GitLab CE бесплатен для самостоятельного размещения по лицензии открытого исходного кода в стиле MIT. Ограничений по количеству пользователей и оплаты за каждое рабочее место нет. Единственные расходы — это сам VPS и время, затрачиваемое на его обслуживание.

Стек VPS DreamHost 4 — это разумная отправная точка для оценки. Производственные команды обычно работают на Стеке 8 или Стеке 16.

Сколько RAM на самом деле нужно GitLab CE?

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

Могу Ли Я Разместить GitLab На 4 GB VPS?

Да, ты можешь запустить 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 — стандартная аббревиатура. Термин «Self-Managed» относится к месту его использования (ваша инфраструктура), а не к конкретному изданию.

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 ГБ RAM) соответствует официальным требованиям GitLab для до 1000 пользователей, с запасом прочности для активных конвейеров CI/CD.