GitLab Self-Hosted под ключ: установка, администрирование и обновление

GitLab Self-Hosted: установка, администрирование и обновление под ключ

Хранить код на GitLab.com удобно ровно до момента, когда юридический или compliance-отдел требует разместить репозитории внутри периметра. Или когда счёт за 500 пользователей превышает бюджет. Self-hosted GitLab даёт полный контроль, но нагружает команду операционной ответственностью: производительность, безопасность, апгрейды. И если апгрейд провалится — сервис встанет на часы. Мы решаем эту задачу под ключ: от выбора схемы развёртывания до регулярных обновлений без даунтайма.

За 5 лет работы мы развернули GitLab более чем для 50 проектов — от стартапов с 10 разработчиками до enterprise с тысячами пользователей. Каждый случай требовал индивидуального подхода к инфраструктуре, бэкапам и процессу обновлений. Ниже — конкретные схемы, конфиги и подводные камни, с которыми мы сталкивались.

Как выбрать способ установки?

Три официальных способа развернуть GitLab — Omnibus, Helm chart и Docker Compose — и каждый подходит под свою нагрузку.

Omnibus (gitlab-ee deb/rpm) — самый простой вариант для одного сервера. Всё в одном: Nginx, PostgreSQL, Redis, Sidekiq, Workhorse, Gitaly. Конфигурация в /etc/gitlab/gitlab.rb. Идеален для команд до 500 человек на одном мощном хосте. Мы рекомендуем Omnibus для 90% клиентов: он в 10 раз проще в администрировании, чем Helm.

Helm chart (gitlab/gitlab) — для Kubernetes. Каждый компонент разворачивается как отдельный Deployment: webservice, sidekiq, gitaly, kas, registry. Горизонтальное масштабирование достигается за счёт сложности: минимальные ресурсы для production — 16 CPU / 32 ГБ RAM только под GitLab. Выбирайте Helm, если ваш стандарт — Kubernetes, и вы готовы инвестировать в его администрирование.

Docker Compose — только для dev-сред и тестов. В production не используем. Пример тюнинга gitlab.rb под high load:

# Производительность Puma
puma['worker_processes'] = 4
puma['min_threads'] = 1
puma['max_threads'] = 4

# PostgreSQL
postgresql['shared_buffers'] = "2048MB"
postgresql['work_mem'] = "32MB"
postgresql['max_connections'] = 200

# Gitaly
gitaly['configuration'] = {
  concurrency: [
    {
      rpc: "/gitaly.SmartHTTPService/PostUploadPack",
      max_per_repo: 20
    },
  ]
}

Hardening: как защитить инстанс от атак?

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

• Отключить публичную регистрацию (gitlab_rails['gitlab_signup_enabled'] = false) — иначе инстанс становится добычей спам-ботов за несколько часов.
• Настроить SMTP для нотификаций — без этого 2FA по email не заработает.
• Включить HTTPS: в gitlab.rb letsencrypt['enable'] = true, external_url 'https://git.company.com'.
• Ограничить rate limit: gitlab_rails['rate_limit_requests_per_period'].
• Настроить LDAP/SAML для интеграции с корпоративным IdP.

Отдельно — вынос Gitaly на отдельный сервер с быстрыми NVMe. Это снижает задержки при клонировании и push на 30% и уменьшает нагрузку на основной сервер.

Почему апгрейды ломаются (и как этого избежать)

GitLab требует последовательного обновления через промежуточные версии. Прыжок с 15.x на 17.x напрямую невозможен. Каждое мажорное обновление содержит breaking changes. Характерный случай: апгрейд с 16.x на 17.0 ломал инсталляции с кастомными настройками PostgreSQL из-за незавершённых фоновых миграций. Ошибка: PG::UndefinedTable: ERROR: relation "ci_runners" does not exist. Решение — перед апгрейдом дождаться завершения всех миграций командой gitlab-rake gitlab:background_migrations:finalize.

Наш процесс апгрейда (мы делаем его заказчикам раз в квартал):

1. Проверить незавершённые фоновые миграции.
2. Сделать полный бэкап: gitlab-backup create SKIP=artifacts (артефакты отдельно в object storage).
3. Последовательно апгрейдить по матрице совместимости GitLab.
4. После каждого шага запускать gitlab-ctl status и gitlab-rake gitlab:check.

Мы гарантируем отсутствие даунтайма: все операции проводятся в rolling-режиме или с минимальным окном обслуживания.

Резервное копирование и восстановление

По умолчанию gitlab-backup кладёт архив локально — на тот же диск, что и данные. Это не бэкап, а иллюзия. Настраиваем Object Storage:

gitlab_rails['backup_upload_connection'] = { 'provider' => 'AWS', 'region' => 'eu-central-1', 'aws_access_key_id' => ENV['AWS_ACCESS_KEY_ID'], 'aws_secret_access_key' => ENV['AWS_SECRET_ACCESS_KEY'] }
gitlab_rails['backup_upload_remote_directory'] = 'my-gitlab-backups'
gitlab_rails['backup_keep_time'] = 604800 # 7 дней

Cron: 0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1. Восстановление тестируем каждый квартал — это обязательная процедура.

Сроки и процесс работы

Полный цикл «с нуля до production» занимает 3-5 дней. Стоимость рассчитывается индивидуально после аудита ваших требований.

Что входит в работу

Мы работаем с GitLab постоянно: 5+ лет, 50+ проектов. Оценим ваш проект за 1 день. Напишите нам для консультации — разберём вашу ситуацию и предложим решение.