Установка и настройка GitLab

s

Требования к вычислительным ресурсам и среде хранения

Для инсталляции GitLab на физическую или виртуальную машину критична спецификация CPU и шаблон доступа к диску. Минимальная конфигурация (до 500 пользователей) подразумевает 4 ядра x86-64 с частотой не ниже 2.3 ГГц и 4 ГБ ОЗУ, но при активации CI/CD-раннеров и индексировании репозиториев нагрузка на память возрастает до 8–10 ГБ. Файловая система должна базироваться на XFS или ext4 с отключённым access time (noatime), иначе задержки на запись метаданных увеличивают тайминги Sidekiq-очередей до 300 мс.

В отличие от GitHub Enterprise, где используется собственная СУБД Aurora (AWS), GitLab полагается на PostgreSQL с PL/pgSQL-расширениями. Версия PostgreSQL 14+ обязательна, иначе функции LATERAL JOIN и параллельный seqscan не раскрывают производительность. Хранение репозиториев на NFS или SMB с RTT выше 2 мс вызывает блокировки блокировок (lock contention) при push-операциях — заводские бенчмарки показывают, что прямой SSD NVMe (4K random write latency < 0.1 мс) даёт прирост частоты коммитов на 47% против сетевого хранилища.

Различия в архитектуре развёртывания: Omnibus и облачные инсталляторы

Пакетный сборщик Omnibus инкапсулирует все зависимые компоненты (PostgreSQL, Redis, Puma, Gitaly) в единый бинарный артефакт. При установке через Omnibus на Ubuntu 22.04 LTS или RHEL 9 версия OpenSSL фиксирована на 3.0, что исключает конфликты TLS с внешними LDAP-провайдерами. Альтернативный метод — Docker-образ на базе Alpine — сокращает поверхность атаки (musl libc вместо glibc), но требует отдельного монтирования томов для объектов хранения (artifacts, uploads) и инициализации init-конфигурации через переменные окружения вместо стандартного gitlab.rb.

Для сравнения: GitLab CE использует интегрированный Puma с буферизацией unicorn-таймера, тогда как GitLab EE (заводская сборка) добавляет подсистему Geo для репликации экземпляров на уровне кластера PostgreSQL. В случае инсталляции в корпоративной среде с требованиями к соответствию ISO 27001 необходим аудит запрета создания репозиториев без подписи коммитов — эта опция включается через gitlab:rails:enable-gpg на этапе начальной настройки.

Пошаговая конфигурация: блоки почтового транспорта и Object Storage

  1. Система очередей: Sidekiq требует выделенных воркеров под импорт и индексирование. В конфигурационном файле gitlab.rb параметр sidekiq['queue_selector'] задаётся массивом ['default', 'mailers', 'repositories']. Если не задать отдельный пул для mailers, отправка почты через SMTP-брокер задерживается до 45 секунд при нагрузке на очередь по умолчанию.
  2. Object Storage: GitLab поддерживает S3-совместимые бакеты (MinIO, AWS S3) для хранения артефактов CI/CD, LFS-объектов и загруженных файлов. При настройке обязательно указывать object_store.enabled = true и path style access (для on-premise MinIO). Пропуск настройки endpoint приводит к ошибке 403 на PUT-запросах, так как SDK по умолчанию пытается использовать виртуальный хост-адрес.
  3. Протоколирование: По стандарту ISO 15408 GitLab должен писать логи аутентификации в syslog. Параметр logging['svlogd_prefix'] задаётся как 'gitlab-audit', ротация логов настраивается через logrotate с разрешением сжатия gzip уровнем 6 — это снижает занимаемый объём на 80% при сохранении скорости распаковки < 100 мкс.

Сравнение с альтернативами: метрики и качество кода

Качество сборки и стандарты поставки

Все релизы GitLab проходят автоматизированное регрессионное тестирование на стендах с 64-битными процессорами Intel Xeon Gold и AMD EPYC 9654. Проверки включают тест на атомарность push: при разрыве соединения на 45-й секунде репозиторий не должен оставаться в состоянии detached HEAD. Отчёт о сборке (build manifest) содержит дайджест SHA-256 для каждого deb/rpm-пакета — данная информация публикуется в официальном реестре. При развёртывании в среде с Kubernetes версия Helm-чарта 7.1.2 требует указания tolerations nodes-кластера с меткой gitlab:system, иначе поды Gitaly не назначаются на ноды с HDD-массивами.

Дополнительная настройка репликации через Patroni (вместо встроенного pg_rewind) увеличивает отказоустойчивость кластера с 99,5% до 99,95% при условии синхронной записи на три узля. Протокол синхронизации использует XLOG-пакеты размером 2 МБ — при превышении лимита latency выше 50 мс кластер автоматически переключается на асинхронный режим, что стандартизировано в процедуре PACELC.

Добавлено: 07.05.2026