Встановлення self-hosted

Конфігурація

Основний файл конфігурації для GitLab Omnibus — це /etc/gitlab/gitlab.rb. Після будь-яких змін у цьому файлі необхідно виконати sudo gitlab-ctl reconfigure для їх застосування.

1. Базова конфігурація GitLab (/etc/gitlab/gitlab.rb)

Відкрийте файл gitlab.rb для редагування:

sudo nano /etc/gitlab/gitlab.rb

Знайдіть та розкоментуйте/змініть наступні рядки:

# Зовнішній URL вашого GitLab-інстансу. Це має бути налаштовано під час встановлення, але переконайтеся.
external_url 'https://gitlab.yourdomain.com'

# Вимкнення вбудованого NGINX, якщо ви використовуєте зовнішній проксі (не наш випадок)
# nginx['enable'] = true # За замовчуванням увімкнено

# Налаштування електронної пошти для сповіщень (обов'язково для роботи)
# Замініть на дані вашого SMTP-сервера
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.your-email-provider.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "[email protected]"
gitlab_rails['smtp_password'] = "ВАШ_ПАРОЛЬ_ВІД_ПОШТИ"
gitlab_rails['smtp_domain'] = "yourdomain.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false # Встановіть у true, якщо ваш провайдер вимагає TLS

gitlab_rails['gitlab_email_from'] = '[email protected]'
gitlab_rails['gitlab_email_display_name'] = 'GitLab'

# Налаштування резервного копіювання (буде розглянуто докладніше в розділі бекапів)
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
gitlab_rails['backup_keep_time'] = 604800 # 7 днів у секундах

Після внесення змін збережіть файл та виконайте переконфігурацію:

sudo gitlab-ctl reconfigure

2. Налаштування TLS/HTTPS за допомогою Certbot (Let's Encrypt)

Для забезпечення безпечного з'єднання по HTTPS ми будемо використовувати Certbot для отримання безкоштовних SSL/TLS-сертифікатів від Let's Encrypt. GitLab Omnibus має вбудовану підтримку Let's Encrypt, що значно спрощує процес.

У файлі /etc/gitlab/gitlab.rb знайдіть наступні рядки та переконайтеся, що вони налаштовані:

# Увімкнення автоматичного керування сертифікатами Let's Encrypt
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ваша_почта@example.com'] # Обов'язково вкажіть ваш email
letsencrypt['auto_renew_hour'] = 12 # Година для щоденної спроби оновлення
letsencrypt['auto_renew_minute'] = 30 # Хвилина для щоденної спроби оновлення
letsencrypt['auto_renew_day_of_month'] = "/7" # Раз на 7 днів

# Увімкнення перенаправлення HTTP на HTTPS (рекомендується)
nginx['redirect_http_to_https'] = true

sudo gitlab-ctl reconfigure

Резервне копіювання та обслуговування

Резервне копіювання — це критично важлива частина будь-якої продакшн-системи. У GitLab є вбудовані механізми для створення резервних копій, які дозволяють зберегти всі дані: репозиторії Git, бази даних, завантажені файли, конфігурацію та секрети.

1. Що резервувати

GitLab Omnibus включає в себе все необхідне. Команда резервного копіювання GitLab за замовчуванням зберігає:

• Базу даних PostgreSQL
• Git-репозиторії
• Завантажені файли (аватари, вкладення)
• Конфігураційні файли (не всі, але основні)
• Секрети (ключі шифрування)

Важливо: файл /etc/gitlab/gitlab.rb та директорія /etc/gitlab/ssl/ (якщо ви використовуєте кастомні сертифікати) не включаються до стандартної резервної копії GitLab. Їх слід резервувати окремо.

2. Простий скрипт авторезервування

GitLab надає зручну команду для створення резервних копій. Ви можете налаштувати її запуск через cron.

Крок 1: Створення резервної копії вручну

# Створення повної резервної копії GitLab
sudo gitlab-rake gitlab:backup:create

Резервні копії за замовчуванням зберігаються в /var/opt/gitlab/backups/. Файли мають формат [TIMESTAMP]_gitlab_backup.tar.

Крок 2: Налаштування автоматичного резервного копіювання за допомогою Cron

Відкрийте таблицю cron для редагування:

sudo crontab -e

Додайте наступний рядок, щоб GitLab створював резервну копію щодня о 02:00 ночі:

# Щоденне резервне копіювання GitLab о 02:00
0 2    sudo gitlab-rake gitlab:backup:create CRON=1

Опція CRON=1 пригнічує інтерактивні запити та робить виведення більш лаконічним, що зручно для автоматизованих завдань.

Крок 3: Резервне копіювання конфігураційних файлів

Створіть окремий скрипт для резервного копіювання gitlab.rb та інших важливих файлів:

sudo mkdir -p /var/opt/gitlab/config_backups
sudo nano /usr/local/bin/gitlab_config_backup.sh

Додайте до файлу наступний вміст:

#!/bin/bash
TIMESTAMP=$(date +%F_%H-%M-%S)
BACKUP_DIR="/var/opt/gitlab/config_backups"
CONFIG_FILES="/etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /etc/gitlab/ssl" # Додайте інші важливі файли/папки

# Створення архіву з конфігураційними файлами
sudo tar -czf "$BACKUP_DIR/${TIMESTAMP}_gitlab_config.tar.gz" $CONFIG_FILES

# Видалення старих резервних копій (наприклад, старших за 7 днів)
find "$BACKUP_DIR" -type f -name ".tar.gz" -mtime +7 -delete

echo "GitLab configuration backup created: $BACKUP_DIR/${TIMESTAMP}_gitlab_config.tar.gz"

sudo chmod +x /usr/local/bin/gitlab_config_backup.sh

# Щоденне резервне копіювання конфігурації GitLab о 02:30
30 2    sudo /usr/local/bin/gitlab_config_backup.sh

3. Куди зберігати резервні копії

Зберігати резервні копії на тому ж сервері, що й основний інстанс GitLab, вкрай ризиковано. У разі втрати сервера ви втратите і резервні копії. Рекомендується використовувати зовнішнє сховище:

• Хмарне сховище, сумісне з S3: AWS S3, DigitalOcean Spaces, Backblaze B2. GitLab Omnibus підтримує пряме завантаження резервних копій до S3. Для цього відредагуйте /etc/gitlab/gitlab.rb:

  
  # Увімкнути завантаження резервних копій до S3
  gitlab_rails['backup_upload_connection'] = {
    'provider' => 'AWS',
    'region' => 'us-east-1', # Замініть на ваш регіон S3
    'aws_access_key_id' => 'ВАШ_AWS_ACCESS_KEY_ID',
    'aws_secret_access_key' => 'ВАШ_AWS_SECRET_ACCESS_KEY'
  }
  gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backups' # Назва вашого S3-бакету
              

  Після зміни виконайте sudo gitlab-ctl reconfigure.

• Окремий VPS: Ви можете налаштувати другий, невеликий VPS та використовувати rsync або scp для регулярного перенесення резервних копій з основного сервера на нього.
• NAS/локальний сервер: Якщо у вас є власне обладнання, можна налаштувати мережеве сховище.

Важливо: використовуйте окремі облікові дані (IAM-користувача) для S3 з мінімальними правами (лише запис до вказаного бакету).

4. Оновлення: rolling vs maintenance window

Регулярні оновлення GitLab критичні для безпеки та отримання нових функцій. GitLab випускає нові версії щомісяця (major.minor.patch).

• Rolling updates (не рекомендується для GitLab): Це підхід, при якому оновлення застосовуються відразу після їх виходу. Для GitLab це небезпечно, оскільки кожне оновлення може містити зміни в базі даних або конфігурації, що потребують уваги.
• Maintenance window: Рекомендований підхід. Плануйте регулярне вікно обслуговування (наприклад, раз на місяць) для оновлення GitLab. Це дозволяє підготуватися, зробити резервну копію та у разі проблем швидко відкотитися.

  
  # Зупинка GitLab перед оновленням
  sudo gitlab-ctl stop
  
  # Оновлення системи та GitLab
  sudo apt update
  sudo apt upgrade -y gitlab-ce
  
  # Запуск GitLab після оновлення
  sudo gitlab-ctl start
  
  # Переконфігурація (іноді потрібна після major-оновлень)
  sudo gitlab-ctl reconfigure
  
  # Перевірка стану
  sudo gitlab-ctl status
  sudo gitlab-rake gitlab:check
              

Завжди читайте офіційні інструкції з оновлення GitLab для вашої конкретної версії, оскільки можуть бути специфічні кроки між мажорними версіями.

Вирішення проблем + FAQ

Що робити, якщо GitLab не запускається після перезавантаження?

По-перше, перевірте логи. Основні логи GitLab знаходяться в /var/log/gitlab/. Почніть з gitlab-rails/production.log, nginx/gitlab_access.log, nginx/gitlab_error.log та gitlab-shell/gitlab-shell.log. Також виконайте sudo gitlab-ctl status, щоб побачити, які сервіси не запущені. Часто проблема пов'язана з нестачею пам'яті або неправильною конфігурацією в /etc/gitlab/gitlab.rb. Спробуйте виконати sudo gitlab-ctl reconfigure та sudo gitlab-ctl restart.

Не вдається отримати SSL-сертифікат від Let's Encrypt. У чому проблема?

Найбільш часті причини: 1) Неправильно налаштований DNS-запис для вашого домену — переконайтеся, що A-запис вказує на IP-адресу вашого VPS. 2) Порт 80 або 443 заблоковано файрволом (UFW або файрволом провайдера VPS). Переконайтеся, що sudo ufw status показує allow 80/tcp та allow 443/tcp. 3) Інший процес вже слухає порт 80 або 443. Перевірте sudo netstat -tulnp | grep -E ':(80|443)'. 4) Помилки в /etc/gitlab/gitlab.rb, наприклад, невірний external_url або не вказано contact_emails для Let's Encrypt.

Який VPS-конфіг мінімально підійде?

Для одного користувача або дуже невеликої команди (до 3-5 осіб) з мінімумом активностей та без інтенсивного CI/CD, мінімально прийнятний VPS повинен мати 2 ядра CPU, 4 ГБ RAM та 50 ГБ SSD. Однак, для більш комфортної та стабільної роботи, особливо якщо планується використовувати CI/CD, настійно рекомендується 4 ядра CPU, 8 ГБ RAM та 100 ГБ NVMe SSD. Менші параметри призведуть до постійних уповільнень та збоїв через нестачу ресурсів.

Що обрати — VPS чи dedicated для цього завдання?

Вибір між VPS та виділеним сервером залежить від масштабу вашої команди та інтенсивності використання GitLab. Для більшості невеликих та середніх команд (до 50-70 осіб) з помірним CI/CD, добре сконфігурований VPS (наприклад, 8-16 ГБ RAM, 8 vCPU, 200+ ГБ NVMe SSD) буде більш ніж достатнім та економічно вигідним. Виділений сервер стає кращим для дуже великих команд (сотні користувачів), високонавантажених CI/CD-пайплайнів, специфічних вимог до продуктивності вводу-виводу або повної фізичної ізоляції ресурсів. У будь-якому випадку, почніть з VPS та масштабуйтеся до dedicated, якщо виникнуть проблеми з продуктивністю.

Як змінити розмір максимального файлу для завантаження?

Максимальний розмір файлу для завантаження в GitLab за замовчуванням обмежений. Щоб змінити його, відредагуйте /etc/gitlab/gitlab.rb. Знайдіть або додайте наступні рядки:

# Збільшити ліміт завантаження NGINX до 2048MB (2GB)
nginx['client_max_body_size'] = '2048m'

# Збільшити ліміт Git (для великих LFS-файлів)
gitlab_rails['gitlab_shell_git_max_size'] = 2048000 # У KB, 2GB

Після збереження файлу виконайте sudo gitlab-ctl reconfigure.

Як оновити GitLab до нової версії?

Процес оновлення включає кілька кроків. Спочатку зробіть повну резервну копію GitLab. Потім зупиніть сервіси GitLab: sudo gitlab-ctl stop. Оновіть пакети системи та GitLab: sudo apt update && sudo apt upgrade -y gitlab-ce. Після оновлення запустіть GitLab: sudo gitlab-ctl start та виконайте переконфігурацію: sudo gitlab-ctl reconfigure. Завжди перевіряйте офіційну документацію GitLab щодо оновлення для вашої конкретної версії, оскільки між мажорними версіями можуть бути додаткові кроки.

Висновки та наступні кроки

Вітаємо! Ви успішно встановили та налаштували self-hosted GitLab на вашому VPS, забезпечивши його безпеку за допомогою SSL/TLS та впровадивши стратегію резервного копіювання. Тепер у вас є потужна та гнучка платформа для управління вашими проєктами розробки, контролю версій та автоматизації CI/CD процесів, повністю під вашим контролем.

Ось кілька кроків, куди можна рухатися далі:

• Налаштування GitLab CI/CD: Вивчіть можливості GitLab CI/CD для автоматизації збірки, тестування та розгортання ваших застосунків. Налаштуйте GitLab Runner на окремому сервері або в Docker-контейнері для ізоляції та масштабування CI/CD завдань.
• Інтеграція із зовнішніми сервісами: Підключіть GitLab до ваших існуючих інструментів, таких як системи відстеження завдань (Jira), зовнішні сховища артефактів або моніторингові системи.
• Моніторинг продуктивності: Впровадьте інструменти моніторингу (наприклад, Prometheus та Grafana) для відстеження стану та продуктивності вашого GitLab-інстансу, щоб своєчасно реагувати на потенційні проблеми та планувати масштабування.