Git-сервер на своём сервере: когда нужен и сколько ресурсов

Код обычно живёт в облачном сервисе, и это удобно ровно до момента, когда появляются причины держать его у себя: требования заказчика, закрытый контур, лимиты на приватные репозитории или просто нежелание зависеть от доступности чужого сервиса. Хорошая новость в том, что своя система управления репозиториями давно не требует мощного сервера.

Разберём, когда это оправдано, чем лёгкие решения отличаются от тяжёлых по ресурсам, что обязательно настроить и почему резервное копирование здесь устроено не так, как кажется.

Когда это оправдано

Код не должен покидать контур. Требование заказчика или внутренняя политика. Обсуждению обычно не подлежит.

Нужны свои правила доступа. Кто и что видит, определяете вы, а не тарифная сетка сервиса.

Лимиты мешают. Число приватных репозиториев, объём хранилища, минуты сборки - всё это в облаке считается и стоит.

Нужна независимость. Сервис может стать недоступен по причинам, которые вы не контролируете, а работа команды встанет.

Честная оговорка: если ничего из этого не про вас, облачный сервис почти наверняка удобнее. Он не требует обслуживания, у него лучше доступность и богаче экосистема.

Лёгкое или тяжёлое решение

Разница между вариантами огромная, и выбор определяет, какой сервер вам нужен.

Лёгкие системы. Написаны компактно, запускаются одним процессом, используют простую базу. Дают то, за чем приходит большинство: репозитории, ветки, запросы на слияние, задачи, вики, права доступа. Работают на самом скромном сервере.

Тяжёлые платформы. Полноценный набор: встроенная сборка, реестр контейнеров, управление окружениями, отчёты по безопасности. Это уже не Git-сервер, а платформа разработки, и требования у неё соответствующие.

Практическое правило: если вам нужно хранить код и проводить ревью - берите лёгкое. Тяжёлую платформу ставят, когда нужен именно её набор возможностей целиком, а не одна функция из списка.

Сколько ресурсов нужно

Два фактора, которые определяют нагрузку сильнее числа людей.

Сборка. Если на том же сервере выполняются задачи сборки и тестов, именно они станут основной нагрузкой, а не сам Git. Их часто выносят на отдельную машину, которую поднимают под задачу и гасят после.

История репозиториев. Проекты с длинной историей и большими бинарными файлами занимают в разы больше, чем кажется по размеру рабочей копии.

Диск должен быть быстрым: операции с репозиториями - это много мелких файлов, см. NVMe, SSD или HDD.

Что настроить обязательно

Доступ по SSH-ключам. Основной способ работы с репозиториями. Ключи разработчиков добавляются в их профили, см. как подключиться к серверу по SSH.

HTTPS для веб-интерфейса. Через него ходят пароли, токены и сам код, см. SSL-сертификат на VPS.

Закрытая регистрация. Иначе учётную запись на вашем сервере заведёт кто угодно. Пользователей добавляет администратор.

Отдельный пользователь для сервиса. Git-сервер не должен работать от root, см. что такое root-доступ.

Обновления. Веб-приложение с доступом к исходному коду обновляют в первую очередь, см. обновление сервера.

Про бэкапы: не только репозитории

Здесь легко ошибиться, потому что кажется, будто Git сам себе резервная копия.

Репозитории действительно продублированы на машинах разработчиков. Потеряв сервер, код вы, скорее всего, восстановите из чьей-нибудь локальной копии.

Но всё остальное существует в одном экземпляре: задачи, обсуждения, запросы на слияние с комментариями ревью, вики, настройки прав, токены доступа. Это живёт только в базе сервера, и локальные копии кода здесь не помогают.

Поэтому бэкап включает три вещи: сами репозитории, базу данных и каталог с вложениями. И хранится он, как всегда, вне сервера, см. резервное копирование VPS.

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

Сборка и автоматизация

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

Три вещи, которые стоит решить заранее:

• Где выполнять сборку. На том же сервере проще, но нагрузка от сборок непредсказуема. Отдельная машина под это избавляет от сюрпризов.
• Где хранить секреты. Токены и ключи выкатки хранятся в настройках проекта, а не в коде, см. как выложить приложение на сервер.
• Сколько хранить артефакты. Собранные пакеты и образы занимают место быстрее всего остального.

Частые ошибки

Ставят тяжёлую платформу ради хранения кода. Восемь гигабайт памяти под задачу, которая решается одним-двумя.

Бэкапят только репозитории. Задачи, ревью и вики теряются, а именно они невосстановимы.

Оставляют открытую регистрацию. Посторонние учётные записи на сервере с исходным кодом.

Запускают сборки на том же сервере без ограничений. Тяжёлая сборка забирает ресурсы, и веб-интерфейс перестаёт отвечать.

Не следят за местом. Артефакты сборок и большие бинарные файлы заполняют диск незаметно.

Работают без HTTPS. По каналу ходят токены доступа к вашему коду.

Частые вопросы

Когда нужен свой Git-сервер? Когда код не должен покидать контур, нужны свои правила доступа, мешают лимиты облачного сервиса или важна независимость от его доступности.

Сколько ресурсов нужно? Лёгкой системе на команду до десяти человек хватает 1-2 ГБ памяти. Тяжёлой платформе нужно от 8 ГБ, особенно если на ней же выполняются сборки.

Что выбрать: лёгкое решение или полноценную платформу? Для хранения кода и ревью достаточно лёгкого. Платформу берут, когда нужен её набор возможностей целиком, включая сборку и реестры.

Нужен ли бэкап, если код есть у разработчиков? Да. Репозитории продублированы локально, а задачи, обсуждения, ревью и вики существуют только на сервере и невосстановимы.

Что входит в резервную копию? Репозитории, база данных и каталог вложений. Хранить вне сервера и периодически проверять восстановлением.

Можно ли запускать сборку на том же сервере? Можно, но нагрузка от сборок непредсказуема. При регулярных сборках их выносят на отдельную машину.

Как разработчики подключаются к репозиториям? Обычно по SSH-ключам, которые добавляются в профили пользователей. Веб-интерфейс работает по HTTPS.

Нужен сервер под репозитории команды? VPS на NVMe от 459 руб в месяц - лёгкой системе хватает младшего тарифа, ресурсы наращиваются за минуты. Полный root-доступ, площадки в Москве, Казани и Амстердаме.