Как разворачивал GitLab

Мой опыт развертывания GitLab

В моей практике было несколько вариантов развертывания GitLab, от классических On-Premise установок до облачных развертываний в Kubernetes. Я подробно опишу наиболее типичный и надежный подход — развертывание GitLab Omnibus на выделенных виртуальных машинах в инфраструктуре компании.

Архитектура и планирование

Перед установкой я всегда провожу планирование, учитывая:

• Количество пользователей — от этого зависит выделение ресурсов (CPU, RAM, диск)
• Требования к отказоустойчивости — нужно ли разделять компоненты (база данных, Redis, файловое хранилище)
• Интеграции — какие инструменты CI/CD будут использоваться, нужны ли runners
• Бэкапы и мониторинг — стратегии резервного копирования и наблюдаемости

Для команды до 100 разработчиков типичная конфигурация:

• 4-8 vCPU
• 8-16 GB RAM
• 100+ GB SSD для системы
• Отдельный том для репозиториев (500GB-1TB)
• Отдельный сервер для GitLab Runners

Процесс установки Omnibus-пакета

Для Debian/Ubuntu установка выглядит следующим образом:

# 1. Установка зависимостей
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates

# 2. Настройка почтового сервера (если нужны уведомления)
sudo apt-get install -y postfix

# 3. Добавление репозитория GitLab
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

# detailed down the comment that is  optional  I  chose to  implement the next step
# 4. Установка GitLab CE (Community Edition)
sudo EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-ce

Ключевой параметр EXTERNAL_URL задает адрес, по которому будет доступен GitLab.

Базовая конфигурация

После установки необходимо отредактировать основной конфигурационный файл /etc/gitlab/gitlab.rb:

# Базовые настройки
external_url 'https://gitlab.company.com'

# Настройки почты
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.gmail.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "gitlab@company.com"
gitlab_rails['smtp_password'] = "password"
gitlab_rails['smtp_domain'] = "company.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true

# Настройки резервного копирования
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
gitlab_rails['backup_keep_time'] = 604800  # 7 дней

# Оптимизация производительности
puma['worker_processes'] = 4
sidekiq['concurrency'] = 20
postgresql['shared_buffers'] = "256MB"

После изменения конфигурации применяем изменения:

sudo gitlab-ctl reconfigure

Настройка HTTPS и SSL

Для защиты трафика настраиваю SSL-сертификаты:

# 1. Копируем сертификаты в папку GitLab
sudo mkdir -p /etc/gitlab/ssl
sudo chmod 700 /etc/gitlab/ssl
sudo cp gitlab.company.com.crt gitlab.company.com.key /etc/gitlab/ssl/

# 2. Указываем в конфигурации
echo "nginx['ssl_certificate'] = \"/etc/gitlab/ssl/gitlab.company.com.crt\"" | sudo tee -a /etc/gitlab/gitlab.rb
echo "nginx['ssl_certificate_key'] = \"/etc/gitlab/ssl/gitlab.company.com.key\"" | sudo tee -a /etc/gitlab/gitlab.rb

# 3. Переконфигурируем
sudo gitlab-ctl reconfigure

Настройка бэкапов

Регулярные бэкапы настраиваю через cron:

# Создаем задачу в crontab
sudo crontab -e

# Добавляем строку для ежедневного бэкапа в 2:00
0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1

Для восстановления из бэкапа:

# Останавливаем процессы
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq

# Восстанавливаем бэкап
sudo gitlab-backup restore BACKUP=timestamp_of_backup

# Перезапускаем и проверяем
sudo gitlab-ctl restart
sudo gitlab-rake gitlab:check SANITIZE=true

Мониторинг и обслуживание

Для мониторинга здоровья GitLab настраиваю:

• Встроенный мониторинг GitLab через Prometheus
• Интеграцию с внешними системами (Zabbix, Grafana)
• Регулярные проверки через встроенные rake.задачи

# Проверка целостности GitLab
sudo gitlab-rake gitlab:check

# Проверка производительности
sudo gitlab-rake gitlab:artifacts:check
sudo gitlab-rake gitlab:lfs:check

# Очистка кэша и временных файлов
sudo gitlab-rake cache:clear

Развертывание в Kubernetes (альтернативный подход)

Для более современных инфраструктур разворачивал GitLab через Helm-чарты:

# values.yaml для GitLab Helm chart
global:
  hosts:
    domain: company.com
  ingress:
    configureCertmanager: true
  
gitlab:
  gitlab-exporter:
    enabled: true
  
postgresql:
  image:
    tag: "12.6"

Установка:

helm repo add gitlab https://charts.gitlab.io/
helm install gitlab gitlab/gitlab -f values.yaml

Ключевые практики и рекомендации

Из своего опыта я выделяю следующие важные моменты:

1. Всегда начинайте с Omnibus — это самый простой и надежный способ для начального развертывания
2. Отделяйте хранилище репозиториев — используйте NFS, объектные хранилища или выделенные диски для данных
3. Настройте бэкапы до запуска в продакшн — проверьте процесс восстановления на тестовом окружении
4. Используйте внешнюю базу данных и Redis для повышения отказоустойчивости при росте нагрузки
5. Планируйте масштабирование — GitLab runners лучше выносить на отдельные серверы с самого начала
6. Настройте мониторинг ресурсов — особенно дискового пространства для репозиториев

Проблемы и их решение

В процессе эксплуатации сталкивался с типичными проблемами:

• Нехватка памяти — решается увеличением swap или добавлением RAM
• Медленная работа при большом количестве репозиториев — требуется оптимизация PostgreSQL и настройка индексов
• Проблемы с бэкапами больших репозиториев — использую инкрементальные бэкапы и архивирование

Развертывание GitLab — это процесс, требующий внимания к деталям на этапе планирования, но сам Omnibus-пакет значительно упрощает установку и последующее обслуживание. Главное — правильно оценить требования и спланировать архитектуру под будущий рост.