Установка self-hosted GitLab на VPS: SSL, бэкапы, обновления

Что мы настраиваем и зачем

В этом руководстве мы займемся установкой и настройкой GitLab — мощной платформы для управления жизненным циклом разработки программного обеспечения. GitLab предоставляет полный набор инструментов, включая управление Git-репозиториями, отслеживание задач, CI/CD (непрерывную интеграцию и непрерывную доставку), мониторинг, безопасность и многое другое. Наша цель — развернуть self-hosted версию GitLab на виртуальном приватном сервере (VPS), что даст вам полный контроль над вашими данными, безопасностью и конфигурацией.

В итоге вы получите полностью функциональный экземпляр GitLab, доступный по доменному имени через защищенное HTTPS-соединение. Он будет готов к использованию вашей командой для хостинга кода, управления проектами и автоматизации процессов разработки. Это идеальное решение для разработчиков, стартапов и небольших команд, которым требуется гибкость и приватность, недоступные в публичных облачных решениях.

Альтернативы и выбор self-hosted:

• Cloud-managed GitLab (GitLab.com): Это самый простой способ начать работу, так как GitLab берет на себя все заботы по инфраструктуре, обновлениям и бэкапам. Однако вы ограничены тарифными планами, не имеете полного контроля над данными (они хранятся на серверах GitLab), и кастомизация может быть ограничена. Для проектов с высокими требованиями к безопасности или специфическими регуляциями это может быть неприемлемо.
• Self-hosted GitLab на VPS: Этот вариант дает вам максимальный контроль. Вы сами выбираете сервер, операционную систему, настраиваете все компоненты и отвечаете за безопасность и обслуживание. Это требует технических знаний, но позволяет адаптировать GitLab под любые нужды, интегрировать его с внутренней инфраструктурой и обеспечивать полную приватность ваших данных. Это особенно актуально, если вы работаете с чувствительной информацией или хотите иметь полный контроль над своей цепочкой поставки ПО.

Выбор в пользу self-hosted GitLab на VPS обусловлен стремлением к суверенитету данных, возможностью глубокой интеграции с другими внутренними сервисами и оптимизацией затрат в долгосрочной перспективе по сравнению с постоянно растущими расходами на облачные сервисы при масштабировании.

Какой VPS-конфиг нужен под эту задачу

GitLab — достаточно ресурсоемкое приложение, особенно если вы планируете активно использовать CI/CD и размещать много репозиториев. Правильный выбор конфигурации VPS критичен для обеспечения стабильной и быстрой работы.

Минимальные требования для одного пользователя или небольшой команды (до 5 человек):

• Процессор (CPU): 2 ядра (vCPU) с частотой от 2.5 GHz.
• Оперативная память (RAM): 4 ГБ. GitLab очень любит оперативную память, и 4 ГБ — это абсолютный минимум, при котором система будет работать без постоянных свопов. Для комфортной работы рекомендуется 8 ГБ.
• Диск: 50 ГБ SSD. SSD-накопители значительно ускоряют операции ввода-вывода, что критично для баз данных и работы с Git-репозиториями. Если планируется много репозиториев или большие файлы, потребуется больше места.
• Сеть: 100 Мбит/с или 1 Гбит/с порт с неограниченным трафиком или достаточным объемом (от 1 ТБ/месяц).

Рекомендуемый VPS-план для команды до 15-20 человек с активным CI/CD:

• Процессор (CPU): 4 ядра (vCPU) с частотой от 2.8 GHz.
• Оперативная память (RAM): 8 ГБ или 16 ГБ. Это обеспечит стабильную работу всех компонентов GitLab, включая PostgreSQL, Redis и Gitaly, а также позволит запускать несколько CI/CD пайплайнов одновременно.
• Диск: 100-200 ГБ NVMe SSD. NVMe предоставляет еще более высокую скорость чтения/записи, что заметно ускорит работу с большими репозиториями и проектами.
• Сеть: 1 Гбит/с порт с неограниченным трафиком.

Для аренды VPS с указанными характеристиками, например, 4 vCPU, 8-16 ГБ RAM, 100-200 ГБ NVMe SSD, можно рассмотреть предложения провайдеров. Подходящий вариант можно найти здесь: VPS с указанными характеристиками.

Когда нужен dedicated, а не VPS?

Выделенный сервер (dedicated server) становится необходимым, если:

• Большая команда (более 50 пользователей): GitLab с большим количеством активных пользователей и CI/CD-задач может потреблять значительные ресурсы.
• Высокие требования к производительности: Для очень активных CI/CD пайплайнов, больших монорепозиториев или специфических рабочих нагрузок.
• Специфические требования к безопасности/изоляции: Если вам нужна полная изоляция от других клиентов провайдера, выделенный сервер предоставляет это.
• Необходимость в кастомном оборудовании: Для специфических задач (например, GPU для машинного обучения в CI/CD) может потребоваться прямое управление железом.

Если вы столкнулись с такими потребностями, рассмотрите возможность взять выделенный сервер.

Локация: на что влияет

Выбор географической локации VPS-сервера влияет на несколько ключевых аспектов:

• Задержка (Latency): Чем ближе сервер к вашей команде и конечным пользователям, тем ниже задержка. Это критично для комфортной работы с Git, быстрой загрузки веб-интерфейса и выполнения CI/CD задач.
• Законодательство: Расположение сервера определяет применимое законодательство о данных. Это важно для соответствия таким нормам, как GDPR, HIPAA или местным законам о хранении данных.
• Стоимость: Цены на VPS могут варьироваться в зависимости от региона.

Рекомендуется выбирать локацию, максимально близкую к основной части вашей команды разработчиков.

Подготовка сервера

Прежде чем приступить к установке GitLab, необходимо выполнить базовую настройку операционной системы. Мы будем использовать Ubuntu Server 24.04 LTS, так как это актуальная долгосрочная версия, поддерживаемая до 2029 года.

1. Подключение по SSH и создание нового пользователя

После получения данных для доступа к VPS (обычно это IP-адрес, логин root и пароль), подключитесь к серверу:

ssh root@ВАШ_IP_АДРЕС

Создайте нового пользователя с правами sudo для повседневной работы. Замените ваш_пользователь на желаемое имя:

# Добавление нового пользователя
adduser ваш_пользователь

# Добавление пользователя в группу sudo
usermod -aG sudo ваш_пользователь

Теперь выйдите из сессии root и войдите под новым пользователем:

exit
ssh ваш_пользователь@ВАШ_IP_АДРЕС

2. Настройка SSH-ключей (рекомендуется)

Для повышения безопасности рекомендуется использовать SSH-ключи вместо паролей. Если у вас еще нет ключей, сгенерируйте их на локальной машине:

# На вашей локальной машине
ssh-keygen -t rsa -b 4096 -C "ваша_почта@example.com"

Затем скопируйте публичный ключ на сервер:

# На вашей локальной машине
ssh-copy-id ваш_пользователь@ВАШ_IP_АДРЕС

После этого вы можете отключить авторизацию по паролю для root в файле /etc/ssh/sshd_config. Найдите строки:

# PermitRootLogin prohibit-password
# PasswordAuthentication yes

И измените их на:

PermitRootLogin no
PasswordAuthentication no

Перезапустите SSH-сервис:

# На сервере, под вашим_пользователем
sudo systemctl restart sshd

3. Обновление системы и установка базовых утилит

Убедитесь, что система актуальна и установлены необходимые пакеты:

# Обновление списка пакетов
sudo apt update

# Обновление всех установленных пакетов
sudo apt upgrade -y

# Установка необходимых утилит
sudo apt install -y curl wget gnupg2 ca-certificates apt-transport-https htop git unattended-upgrades

Unattended Upgrades: Этот пакет автоматически устанавливает критические обновления безопасности, что крайне важно для поддержания сервера в актуальном и защищенном состоянии.

4. Настройка файрвола (UFW)

Настроим базовый файрвол UFW (Uncomplicated Firewall) для защиты сервера. По умолчанию мы разрешим только SSH, HTTP, HTTPS:

# Разрешить SSH (по умолчанию порт 22)
sudo ufw allow ssh

# Разрешить HTTP (порт 80)
sudo ufw allow http

# Разрешить HTTPS (порт 443)
sudo ufw allow https

# Включить файрвол
sudo ufw enable

Подтвердите включение файрвола, нажав y. Проверить статус можно командой sudo ufw status.

5. Установка Fail2ban (защита от брутфорса)

Fail2ban сканирует логи и автоматически банит IP-адреса, которые показывают признаки вредоносной активности (например, многократные неудачные попытки входа по SSH).

# Установка Fail2ban
sudo apt install -y fail2ban

# Запуск и включение автозапуска Fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Создайте файл конфигурации для Fail2ban, чтобы он не перезаписывался при обновлениях:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Откройте /etc/fail2ban/jail.local и настройте, например, bantime (время бана) и findtime (период для обнаружения попыток) под свои нужды. Убедитесь, что секция [sshd] включена (enabled = true).

# Пример настройки в /etc/fail2ban/jail.local
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Перезапустите Fail2ban для применения изменений:

sudo systemctl restart fail2ban

Теперь ваш сервер готов к установке GitLab.

Установка ПО — пошагово

Мы будем устанавливать GitLab Community Edition (CE) с помощью Omnibus-пакета, который включает в себя все необходимые компоненты (NGINX, PostgreSQL, Redis и т.д.) и значительно упрощает процесс установки и обслуживания. Для 2026 года будем ориентироваться на GitLab версии 20.x, которая будет актуальной на тот момент.

Перед установкой убедитесь, что у вас есть доменное имя, указывающее на IP-адрес вашего VPS. Например, gitlab.yourdomain.com.

1. Установка зависимостей

Для добавления репозитория GitLab требуется несколько пакетов:

# Установка пакетов, необходимых для добавления репозитория GitLab
sudo apt update
sudo apt install -y apt-transport-https ca-certificates curl gnupg2

2. Добавление репозитория GitLab

Импортируем GPG-ключ GitLab и добавим официальный репозиторий Omnibus-пакетов:

# Добавление GPG-ключа GitLab
curl https://packages.gitlab.com/gpg.key | sudo gpg --dearmor > /usr/share/keyrings/gitlab-archive-keyring.gpg

# Добавление репозитория GitLab CE для Ubuntu 24.04 (Noble Numbat)
echo "deb [signed-by=/usr/share/keyrings/gitlab-archive-keyring.gpg] https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu noble main" | sudo tee /etc/apt/sources.list.d/gitlab-ce.list

Обновите список пакетов после добавления нового репозитория:

# Обновление списка пакетов
sudo apt update

3. Установка GitLab Community Edition

Теперь можно установить GitLab. В команде установки укажем внешний URL, который GitLab будет использовать для генерации ссылок и настройки NGINX. Замените gitlab.yourdomain.com на ваш домен.

# Установка GitLab CE с указанием внешнего URL
sudo EXTERNAL_URL="https://gitlab.yourdomain.com" apt install gitlab-ce

Эта команда установит последнюю стабильную версию GitLab CE, доступную в репозитории. Процесс может занять некоторое время, так как будет загружено и установлено множество компонентов.

4. Первоначальная настройка и переконфигурация

После установки GitLab автоматически запустит процесс переконфигурации, который настроит все компоненты. Если вы не указали EXTERNAL_URL во время установки или хотите изменить какие-либо настройки, вы можете сделать это в файле /etc/gitlab/gitlab.rb.

Если вам нужно переконфигурировать GitLab вручную (например, после изменения gitlab.rb):

# Запуск процесса переконфигурации GitLab
sudo gitlab-ctl reconfigure

Эта команда перечитает файл gitlab.rb и применит все изменения, а также убедится, что все службы GitLab запущены и настроены правильно.

5. Проверка статуса сервисов GitLab

Убедитесь, что все компоненты GitLab запущены и работают корректно:

# Проверка статуса всех сервисов GitLab
sudo gitlab-ctl status

Вы должны увидеть список сервисов (nginx, postgresql, redis, unicorn, sidekiq, gitaly и т.д.) со статусом run.

6. Установка пароля для root-пользователя GitLab

При первой установке GitLab генерирует временный пароль для пользователя root. Вы можете найти его в файле /etc/gitlab/initial_root_password, который существует только 24 часа после установки.

# Просмотр временного пароля root
sudo cat /etc/gitlab/initial_root_password

Рекомендуется сразу же установить новый, надежный пароль через веб-интерфейс или через консоль Rails:

# Запуск консоли GitLab Rails
sudo gitlab-rails console

# Внутри консоли Rails
user = User.where(id: 1).first
user.password = 'ВАШ_НОВЫЙ_НАДЕЖНЫЙ_ПАРОЛЬ'
user.password_confirmation = 'ВАШ_НОВЫЙ_НАДЕЖНЫЙ_ПАРОЛЬ'
user.save!

# Выход из консоли
exit

Теперь вы можете получить доступ к веб-интерфейсу GitLab по адресу https://gitlab.yourdomain.com, используя логин root и ваш новый пароль.

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

Основной файл конфигурации для 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 для вашей конкретной версии, так как могут быть специфические шаги между мажорными версиями.

Troubleshooting + 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-инстанса, чтобы своевременно реагировать на потенциальные проблемы и планировать масштабирование.