Self-hosted GitLab CE: установка корпоративного git-сервера под ключ

Я, Семёнов Евгений Сергеевич, возглавляю компанию АйТи Фреш. За 15 лет в IT мы запустили уже около двадцати GitLab-инсталляций, и каждая была по-своему уникальна. Были как совсем небольшие, буквально для 6 разработчиков, так и серьёзные корпоративные системы для 300+ пользователей, где уже требовались LDAP и HA. Как правило, GitLab у наших клиентов работает либо на их собственных виртуалках прямо в офисе, либо же мы размещаем его на наших мощных серверах Dell Xeon Platinum 8280, которые стоят в дата-центре МТС Москва. Сегодня я покажу вам, как выполнить установку с нуля на Ubuntu 22.04.

Железо и ОС

На чём ставить? Выбирайте Ubuntu 22.04 LTS, или, как вариант, Rocky/RHEL 9. И обязательно про Swap: держите 4–8 ГБ, это пригодится на пиковых нагрузках, особенно во время бэкапов.

Установка Omnibus на Ubuntu 22.04

sudo apt update
sudo apt install -y curl openssh-server ca-certificates tzdata perl postfix

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

sudo EXTERNAL_URL="https://git.company.ru" apt install -y gitlab-ce

Первая инициализация занимает 5–10 минут. В /etc/gitlab/initial_root_password лежит временный пароль для root.

Базовый gitlab.rb

# /etc/gitlab/gitlab.rb

external_url 'https://git.company.ru'
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['admin@company.ru']

# SMTP для нотификаций
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "mail.company.ru"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "gitlab@company.ru"
gitlab_rails['smtp_password'] = "secret"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true

gitlab_rails['gitlab_email_from'] = 'gitlab@company.ru'
gitlab_rails['gitlab_email_reply_to'] = 'noreply@company.ru'

# Таймзона
gitlab_rails['time_zone'] = 'Europe/Moscow'

# Производительность
puma['worker_processes'] = 4
postgresql['shared_buffers'] = "4GB"
sidekiq['max_concurrency'] = 20

sudo gitlab-ctl reconfigure

LDAP интеграция с AD

gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = {
  'main' => {
    'label' => 'Active Directory',
    'host' => 'dc.corp.company.ru',
    'port' => 636,
    'uid' => 'sAMAccountName',
    'encryption' => 'simple_tls',
    'verify_certificates' => true,
    'bind_dn' => 'CN=gitlab_bind,OU=Services,DC=corp,DC=company,DC=ru',
    'password' => 'BindPassword',
    'active_directory' => true,
    'base' => 'OU=Users,DC=corp,DC=company,DC=ru',
    'user_filter' => '(memberOf=CN=Developers,OU=Groups,DC=corp,DC=company,DC=ru)',
    'group_base' => 'OU=Groups,DC=corp,DC=company,DC=ru'
  }
}

TLS: Let's Encrypt или свой PKI

Omnibus умеет сам выписывать Let's Encrypt — letsencrypt['enable'] = true. Для внутренней сети без доступа к интернету — используйте свой AD CS:

letsencrypt['enable'] = false
nginx['ssl_certificate'] = "/etc/gitlab/ssl/git.company.ru.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/git.company.ru.key"

Регистрация раннеров

Для CI/CD без раннера никуда. Вам потребуется минимум один. Самый быстрый вариант, по нашей практике? Разместить docker-executor на отдельной виртуалке.

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
sudo apt install -y gitlab-runner

sudo gitlab-runner register \
  --non-interactive \
  --url "https://git.company.ru/" \
  --token "glrt-xxxx" \
  --executor "docker" \
  --docker-image "alpine:latest" \
  --docker-privileged \
  --description "main-docker-runner"

Бэкапы

Главное правило: бэкап состоит из двух частей — дамп данных и конфиг. Без конфига дамп не восстановить.

# Бэкап данных (БД, repos, uploads, artifacts)
sudo gitlab-backup create STRATEGY=copy GZIP_RSYNCABLE="true"

# Бэкап конфига и секретов
sudo tar czf /var/opt/gitlab/backups/etc-gitlab-$(date +%F).tgz /etc/gitlab

В cron:

0 2 * * * /usr/bin/gitlab-backup create CRON=1 >> /var/log/gitlab-backup.log 2>&1
30 2 * * * tar czf /var/opt/gitlab/backups/etc-$(date +\%F).tgz /etc/gitlab

Никогда не храните бэкапы там же, где рабочая система! Они должны лежать на отдельном сервере. Подумайте об rsync, borg или restic. И вот вам главный совет: не просто делайте бэкапы, а тестируйте их восстановление, причём регулярно – минимум раз в квартал. Иначе в чём смысл?

Производительность

• Puma workers = ядра / 2, минимум 2.
• А вот что по PostgreSQL: для параметра shared_buffers выделите 25% от общей ОЗУ. Важный момент: не превышайте 8 ГБ, даже если ОЗУ очень много.
• Как быть с Sidekiq concurrency? Выставляйте его в пределах 10–25. Точное значение, конечно, будет зависеть от нагрузки на вашу систему.
• Где хранить Git-репозитории? Тут только один ответ: на отдельном SSD! Не забудьте про важные настройки: ReadAhead и noatime – они сильно помогут производительности.
• Если используете LFS, то для него – исключительно отдельный объектный сторадж. Подойдут решения вроде MinIO или S3.

Мониторинг

Omnibus включает Prometheus и Grafana внутри. Достаточно открыть https://git.company.ru/-/grafana/ — там готовые дашборды по Puma, Sidekiq, PostgreSQL. Для внешнего мониторинга экспортируйте :9090/metrics в корпоративный Prometheus.

Реальный кейс: миграция с Bitbucket Server

В 2024 году к нам обратился интересный клиент – крупное региональное медиа. Представляете, у них работало 64 разработчика, и все они 'сидели' на Bitbucket Server 7.x. И тут бац! Лицензия подорожала в 3 раза, плюс возникли серьёзные санкционные риски с Atlassian. Что делать? Основная задача для нас была чёткой: мигрировать абсолютно все их проекты и пайплайны на self-hosted GitLab CE.

За 6 рабочих дней мы развернули GitLab на виртуалке 16 vCPU / 32 ГБ (наш сервер Dell Xeon Platinum 8280, дата-центр МТС Москва), интегрировали с AD по LDAP, мигрировали 148 репозиториев через bbcloud → git bundle → gitlab. Переписали 32 пайплайна с Bitbucket Pipelines на GitLab CI. Стоимость — 240 000 руб. Экономия лицензий — около 1,8 млн руб./год.

Грабли

• Обновления ломаются при пропуске минорных версий. GitLab требует идти по Upgrade path. Читайте документацию.
• Забытый secret.yml в бэкапе. Восстановление не идёт. Всегда бэкапьте /etc/gitlab.
• Медленный git push. Часто виноват диск, а не GitLab. Проверяйте iostat и latency.
• Почта уходит с сервера в спам. Настройте SPF и DKIM через ваш почтовый сервер, не SMTP-сервер GitLab.
• Забыли про Container Registry. Поднимается отдельно в gitlab.rb, иначе разработчики будут жаловаться.

FAQ — Self-hosted GitLab

Сколько ресурсов нужно на GitLab для 50 разработчиков?

Минимум 8 vCPU, 16 ГБ ОЗУ, 500 ГБ SSD. Комфортно 16 vCPU / 32 ГБ. Для 200+ пользователей разносите на два сервера: application + отдельный PostgreSQL/Redis.

Omnibus или Docker?

Для single-сервера — Omnibus-пакет (один deb/rpm). Проще обновлять и обслуживать. Docker и Helm нужны для HA-развёртывания на нескольких нодах или в Kubernetes.

GitLab CE или EE?

CE бесплатен и покрывает 95% потребностей: репозитории, CI, issue, wiki, LDAP. EE нужен для corporate audit, epic management, advanced security сканирования. Для большинства МСП хватит CE.

Как делать бэкап GitLab?

gitlab-backup create для данных (БД, repos, uploads, artifacts). Отдельно копируйте /etc/gitlab (секреты, конфиг). Без секретов из /etc/gitlab бэкап не восстановится.

Можно ли интегрировать с Active Directory?

Да, через LDAP. В gitlab.rb настраиваются gitlab_rails['ldap_servers'] с bind_dn, user_filter, group_base. Пользователи логинятся доменной учёткой, группы AD маппятся в GitLab.