Установка GitVerse на собственный сервер: рекомендации
Info
Инструкция по развертыванию локальной (on-premise) версии платформы GitVerse и переносу репозиториев из GitLab.
Что такое on-prem версия GitVerse
GitVerse — платформа для работы с исходным кодом от СберТеха. Локальная версия:
- устанавливается на серверах организации, в том числе в закрытых контурах без доступа к интернету;
- хранит исходный код и данные разработки внутри организации: git-репозитории, git LFS и артефакты;
- включает в поставку трекер задач, AI-чат и раннеры (CI/CD, Agentic Sessions);
- не зависит от внешних сервисов;
- доступна корпоративным клиентам, для которых предусмотрено бесплатное тестирование.
Кому подходит и как получить дистрибутив
Локальная версия рассчитана на крупный бизнес и корпоративных клиентов, которым нужно хранить код внутри собственного контура. Для личных проектов и небольших команд доступна облачная версия на gitverse.ru.
Порядок получения локальной версии:
- Для заключения договора напишите в поддержку на support@gitverse.ru или через форму связи на странице gitverse.ru/home/pricing в разделе OnPrem.
- После заключения договора дистрибутив размещается в личном кабинете клиента.
Системные требования
Референсные конфигурации рассчитаны по целевой нагрузке (RPS). Число пользователей указано справочно: если меньшее число пользователей создает нагрузку более высокой конфигурации, выбирайте ее.
Выбор конфигурации
Выберите одну строку таблицы. Значения указаны в универсальных ресурсах: vCPU, RAM и локальный диск.
| Конфигурация | Развертывание | RPS | vCPU | RAM, ГБ | Диск, ГБ |
|---|---|---|---|---|---|
| До 100 польз., без HA | docker compose* | 2 | 20 | 56 | 310 |
| До 100 польз., без HA | k8s | 2 | 21 | 62 | 340 |
| До 1000 польз., без HA | k8s | 20 | 23 | 66 | 340 |
| До 1000 польз., HA | k8s | 20 | 44 | 116 | 720 |
| До 5000 польз., без HA | k8s | 100 | 35 | 106 | 370 |
| До 5000 польз., HA | k8s | 100 | 88 | 252 | 840 |
* Вариант развертывания docker compose будет доступен в 2027 году.
- в расчет входят PostgreSQL, Redis, Kubernetes (или docker compose) и минимальный пул раннеров;
- в расчет не входят сервисы, которые клиент развертывает самостоятельно: IdP (Keycloak или другой) и корпоративный AI-прокси (AI Gateway: bifrost или wormhole);
- для всех конфигураций нужны SFS (shared filesystem, любое совместимое решение) не менее 100 ГБ и S3 не менее 200 ГБ. Это минимальные значения: фактический объем (git-репозитории на SFS, git LFS и артефакты на S3) оценивается отдельно по плановому росту данных;
- варианты с HA включают PostgreSQL в отказоустойчивой конфигурации (3 узла: 1 primary и 2 replica) и приложение в отказоустойчивой конфигурации. SFS и S3 должны быть отказоустойчивыми на уровне инфраструктуры;
- вариант k8s без HA с одной master-нодой не рекомендуется.
Как выбрать конфигурацию
- Есть метрики RPS. Ориентируйтесь на пиковый RPS (95-й перцентиль). Если пик превышает предел конфигурации более чем на 10–15%, берите следующую.
- Метрик нет. Выбирайте по числу пользователей с поправкой на автоматизацию: боты, интеграции, вебхуки и массовые CI-задачи создают нагрузку, не пропорциональную числу пользователей. Локальные и встроенные в GitVerse ИИ-агенты создают нагрузку, сравнимую примерно с 10 пользователями на каждого агента.
- HA или без HA. HA-конфигурации требуют примерно вдвое больше CPU и RAM. Используйте HA там, где простой недопустим. При ограниченных ресурсах рассматривайте вариант без HA с регулярным резервным копированием и быстрым восстановлением.
- Профиль нагрузки. Конфигурации рассчитаны на типичный профиль: около 80% API, 10% Web, 10% Git. При API более 90% или Web более 20% увеличьте ресурсы приложения и СУБД. При Git более 15% или крупных (моно)репозиториях увеличьте ресурсы хранилища.
- Состав данных. При проектировании учитывайте репозитории размером более 2 ГБ и более 10 ГБ, объем S3 и пиковый сетевой трафик (клоны, артефакты, реестр).
- Рост. Сравните текущий RPS с показателями 6–12 месяцев назад.
- Запас. Если сомневаетесь, берите следующую конфигурацию и уменьшайте по данным мониторинга. Отклонения в 5–10% RPS не требуют более высокой конфигурации. Устойчивая утилизация CPU и RAM ниже 70% означает достаточный запас. Перепроверьте конфигурацию через 7–14 дней эксплуатации.
Необходимое программное обеспечение
Перед развертыванием подготовьте программную среду согласно списку ниже:
- среда функционирования: Kubernetes (docker compose будет доступен в 2027 году);
- сУБД: PostgreSQL или Pangolin. В HA-конфигурации: нечетное число узлов (3);
- redis. В HA-конфигурации: 2 узла;
- файловое хранилище SFS и объектное хранилище S3;
- внешние сервисы, которые развертывает клиент: IdP (Keycloak или другой) и AI Gateway (bifrost или wormhole).
Ресурсы компонентов GitVerse в Kubernetes (запросы и лимиты на один под):
| Компонент (контейнер) | CPU, запрос / лимит | RAM, запрос / лимит | Реплик до 1000 польз. | Реплик до 5000 польз. |
|---|---|---|---|---|
GitVerse BackEnd (gitverse-backend) | 200m / 1000m | 256Mi / 1024Mi | 2 | 5 |
GitVerse FrontEnd (gitverse-frontend) | 100m / 1000m | 128Mi / 1024Mi | 2 | 5 |
Documentation (gitverse-docs) | 100m / 500m | 128Mi / 512Mi | 1 | 1 |
Cookie Router (gitverse-cookierouter) | 100m / 500m | 128Mi / 512Mi | 1 | 2 |
IAM Proxy (gitverse-iamproxy) | 100m / 1000m | 128Mi / 1024Mi | 1 | 2 |
gv-pcc | 100m / 250m | 128Mi / 256Mi | 1 | 2 |
pr-agent | 500m / 500m | 512Mi / 512Mi | 1 | 2 |
gv-ai-rag | 100m / 500m | 256Mi / 512Mi | 1 | 2 |
gv-ai-mcp | 100m / 500m | 256Mi / 512Mi | 1 | 2 |
gv-ai-agent | 100m / 500m | 256Mi / 512Mi | 1 | 2 |
gv-ai-agent-plugin | 100m / 500m | 256Mi / 512Mi | 1 | 2 |
AI Gateway (gv-ai-bifrost или gv-ai-wormhole) | 100m / 250m | 128Mi / 256Mi | 1 | 2 |
- в референсном расчете на каждый компонент закладывается минимум один под. Количество реплик справочное: его нужно проверить на нагрузочном тестировании или в эксплуатации;
- запрос (request) определяет гарантированные ресурсы контейнера, лимит (limit) ограничивает максимум. Превышение лимита памяти приводит к аварийному завершению контейнера (OOM), превышение лимита CPU приводит к его ограничению планировщиком;
- компоненты GitVerse stateless и масштабируются горизонтально: рассчитывайте их на устойчивую нагрузку, а пики отдавайте HPA;
- postgreSQL, Redis и файловые хранилища stateful: автоматическое масштабирование к ним неприменимо, рассчитывайте их на пиковую нагрузку и масштабируйте вертикально;
- в GitVerse чтение и запись PostgreSQL обслуживает одна реплика, остальные узлы кластера нужны только для отказоустойчивости (failover). Компоненты кворума в HA разворачиваются нечетным числом узлов.
Раннеры
Емкость пула раннеров определяется конкурентностью и длительностью задач, а не числом пользователей или RPS. В референсных конфигурациях заложен минимум: 4 раннера (суммарно 8 vCPU, 32 ГБ RAM, 120 ГБ диска). Этого достаточно для кэширования файловой системы раннеров и проверки работоспособности инсталляции, но не для тяжелых нагрузок CI/CD и ИИ-агентов.
Общие рекомендации
- крупные репозитории и монорепозитории повышают требования к раннерам непропорционально объему: клонирование, сборка и тесты требуют больше CPU и RAM;
- при активной нагрузке (сборки, тесты) CPU раннера утилизируется почти полностью. Занижение CPU-лимита только растягивает задачи и увеличивает требуемое число раннеров;
- при нагрузке с ожиданием (Agentic Sessions) длительность задачи включает ожидание ответов, поэтому закладывайте больше ядер, чем при активной нагрузке;
- создавайте отдельные пулы под разное допустимое время ожидания. В общем пуле короткие задачи (линтеры, юнит-тесты) ждут завершения длинных (сборка, Agentic Sessions);
- лимит памяти жесткий: превышение приводит к аварийному завершению задачи (OOM). Задавайте его с запасом для каждого пула.
Профили раннеров
Определите профиль по пиковому расходу памяти представительных задач (сборка, юнит-тесты, интеграционные тесты, линтеры) и заведите пул под каждый профиль.
| Профиль | vCPU | RAM, ГБ |
|---|---|---|
| small | 2 | 8 |
| medium | 4 | 16 |
| large | 8 | 32 |
| xlarge | 16 | 64 |
CI/CD
Расчет пула выполняется по модели очереди M/M/N (формула Эрланга C) отдельно для каждого профиля.
- Определите среднюю длительность задачи
Tи поток задач в часλна этот профиль. Считайтеλпо пиковому интервалу, а не по среднему за день, с поправкой на автоматизацию (боты, вебхуки, массовые merge request). - Задайте допустимое время ожидания в очереди, например 10–30 с.
- Найдите минимальное число раннеров
N, при котором среднее время ожидания не превышает допустимое. Нижняя граница емкости:a = λ × T. - Округлите
Nвверх и возьмите с запасом ×1,5–2 на суточные и недельные колебания.
Пример для 100 пользователей: 8 рабочих часов в день, T = 10 мин, допустимое ожидание 30 с, учитываются только задачи, инициированные пользователями.
| Задач на пользователя в день | Раннеров (small) с запасом ×2 |
|---|---|
| 1 | 10 |
| 2 | 16 |
| 5 | 30 |
| 10 | 52 |
Agentic Sessions
Сессии исполняются в CPU-раннерах, GPU не требуется. Емкость пула определяется пиковым числом одновременных сессий:
- сессия занимает запущенный раннер практически непрерывно. После ответа раннер не освобождается, а переходит в режим охлаждения (по умолчанию 15 минут), и при продолжении сессии тот же раннер продолжает работу;
- емкость пула определяется пиковым числом одновременных сессий. Модель очереди из раздела CI/CD здесь не применяется;
- пул под сессии считайте отдельно от пула CI/CD: сессия держит раннер часами и вытесняет короткие задачи.
Пример для 100 пользователей:
| Параметр | Консервативно | Нормально |
|---|---|---|
| Доля сотрудников, одновременно работающих с сессиями | 30% | 100% |
| Одновременных сессий на сотрудника | 2 | 3 |
| Средняя длительность сессии | ~1 час | ~1 час |
| Раннеров под сессии (100 × доля × сессии) | 60 | 300 |
Итоговый пример для 100 пользователей
Суммарная потребность в раннерах зависит от профиля нагрузки и доли автоматизаций.
| Функциональность | vCPU | RAM, ГБ | Консервативно, шт. | Нормально, шт. |
|---|---|---|---|---|
| CI/CD, включая системные и security jobs | 2 | 8 | 10 | 52 |
| Agentic Sessions | 2 | 8 | 60 | 300 |
- значения зависят от числа автоматизаций и автоматических проверок в разработке, а активное использование ИИ-агентов существенно увеличивает нагрузку. Значения нужно калибровать на целевой инсталляции;
- сайзинг LLM-инференса, обслуживающего Agentic Sessions, в требованиях не описан. Его планируют отдельно: провайдеры, модели, пропускная способность, число одновременных сессий;
- в 2027 году для GitVerse on-prem будет доступен UCL (universal compute layer): он динамически выделяет раннеры под потребность на гибридной инфраструктуре в рамках заданных политик.
Установка и первый вход
Развертывание выполняется в Kubernetes. Вариант docker compose будет доступен в 2027 году. Локальная версия работает в контурах без доступа к интернету, IdP и AI Gateway разворачиваются самостоятельно внутри контура.
После первого входа смените временный пароль, если он был выдан автоматически, и создайте отдельные учетные записи для администраторов.
Note
Вся информация по установке, первому входу и обновлению передается в документации, которая поставляется вместе с дистрибутивом.
Миграция репозиториев из GitLab
Для переноса репозиториев из GitLab в GitVerse используется GitVerse Migration Tool (консольная утилита gmt). Она получает список репозиториев GitLab и запускает перенос через публичный API GitVerse. Подходит для массовой миграции в личное пространство и в организацию. Переносится git-структура: файлы, история изменений, ветки и коммиты.
Кратко о порядке работы
-
Скачайте утилиту со страницы Releases и запустите бинарный файл
gmt. -
Создайте токен GitVerse с правами:
user— Read,organization— Read,repository— Read and Write. -
Создайте токен GitLab с правами
read_apiиread_repository. -
Проверьте, что GitVerse имеет сетевой доступ к GitLab: перенос выполняет сервис GitVerse, а не рабочая станция с утилитой.
-
Сформируйте список репозиториев, при необходимости отредактируйте его и запустите миграцию по файлу:
./gmt --config-out migration.json -k "$GITVERSE_TOKEN" -t "$GITLAB_TOKEN" \ --source-group=team/backend --include-subgroups ./gmt -c migration.json -k "$GITVERSE_TOKEN" -t "$GITLAB_TOKEN" -
Проверьте статус в файле (
status,errors), число веток и тегов, настройте видимость, соавторов и защиту веток.
Для собственных инстансов адреса API задаются параметрами -u (GitVerse) и -s (GitLab). Токены в файл со списком не записываются.
Note
Полная инструкция (параметры, типовые ошибки, чек-лист) и описание импорта отдельных репозиториев через веб-интерфейс: Использование GitVerse Migration Tool.
Что настроить после установки
После развертывания выполните базовую настройку корпоративной git-платформы:
- создание организаций, команд и разграничение прав доступа;
- настройка отправки уведомлений;
- настройка CI/CD и исполнителей задач (раннеров);
- настройка резервного копирования.
Обновление и обслуживание
Порядок обновления версий, резервного копирования и восстановления описан в документации, которая поставляется вместе с дистрибутивом. Для мониторинга нагрузки на раннеры используйте метрики из таблицы ниже.
Мониторинг раннеров
Дополнительно отслеживайте CI/CD workflow по стадиям, чтобы выявлять замедления на checkout, обращениях к кэшу и реестрах артефактов.
| Метрика | Назначение | Warning | Critical |
|---|---|---|---|
| Время ожидания задачи в очереди | Главный индикатор достаточности емкости | 10 с | 30 с |
| CPU (пик более 3 мин) | Предотвращение замедления сборок | 70% устойчиво | 85% устойчиво |
| Память (пиковое потребление) | Исключение ошибок из-за нехватки памяти | 80% от лимита | 90% от лимита |