Установка и настройка GitLab на собственном сервере

Быстрые ссылки

• Gitlab — ваш собственный размещённый GitHub
• Как установить GitLab

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

git

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

GitLab — ваш собственный размещённый GitHub

GitLab — это сервис на базе Git с веб‑панелью для управления проектами и просмотра кода. Подход схож с GitHub: репозитории, пул‑реквесты (merge requests), управление правами и CI/CD. Если вам нужна просто альтернатива GitHub без развёртывания, можно использовать их облачный SaaS.

Ключевое отличие: Community Edition GitLab — с открытым исходным кодом, её можно хостить на собственном сервере без ограничений по числу проектов или размеру репозиториев. Это удобно, если у вас есть большие бинарные файлы, превышающие 100 МБ лимит GitHub (вместе с тем стоит рассмотреть Git LFS).

Важно помнить: собственный инстанс требует сервера и дискового пространства. Рекомендуемые ресурсы для базовой работы — 4 ГБ ОЗУ; в наших тестах GitLab использовал около 2,8 ГБ при интенсивных операциях. При недостатке памяти возможны замедления при push/pull. Нагрузка на CPU при обычной работе обычно невысока (в примерах — порядка 10%).

Ещё один важный момент — Git сам по себе не является полноценным решением для бэкапов. Если ваша виртуальная машина или хост удалены, данные могут быть утеряны, если у вас нет отдельно организованных резервных копий. Git предоставляет историю кода, но системные данные, настройки и базы данных GitLab требуют отдельного бэкапа.

Когда стоит выбрать self‑hosted GitLab, а когда нет

• Подойдёт, если вы хотите полный контроль над данными, интеграцию с внутренними системами и свободу в настройках прав доступа.
• Не подходит, если вы не готовы поддерживать сервер, обновления и бэкапы — в этом случае облачный GitLab или GitHub проще.

Альтернативы:

• GitLab SaaS (облачный) — минимально администрирования.
• Gitea / Gogs — лёгкие, менее ресурсоёмкие, проще для небольших команд.
• GitHub Enterprise — коммерческий аналог для крупных организаций.

Как установить GitLab

Ниже приведён базовый пошаговый процесс развёртывания на Debian/Ubuntu‑подобных системах. Он основан на Omnibus‑пакете GitLab (удобный набор, включающий все компоненты).

1. Установите зависимости для HTTPS и SSH (возможно, они уже установлены):

sudo apt-get install -y curl openssh-server ca-certificates

2. Установите почтовую систему (опционально, но рекомендуется для нотификаций):

sudo apt-get install -y postfix

3. Добавьте репозиторий GitLab и установите пакет (пример для apt):

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

Если вы используете другой пакетный менеджер (yum, zypper и т. п.), используйте соответствующий скрипт с packages.gitlab.com.

4. Установите GitLab, указав внешний URL (рекомендуется поддомен, например git.example.com):

sudo EXTERNAL_URL="https://git.example.com" apt-get install gitlab-ee

GitLab настроит Let’s Encrypt и сам установит сертификат HTTPS, если вы указали HTTPS в EXTERNAL_URL и сервер доступен извне.

Установка займёт несколько минут. После завершения вы получите сообщение об успешной установке.

После этого вы можете закрыть SSH‑подключение и завершить настройку в браузере по указанному URL. На странице приветствия будет предложено задать мастер‑пароль для root:

Введите мастер‑пароль — это не ваша пользовательская учётная запись, её нужно создать отдельно.

Дальнейшие шаги в интерфейсе:

• Зарегистрируйте свою учётную запись (можно взять желаемый короткий логин). Сразу выйдите.
• Залогиньтесь под root (логин root и мастер‑пароль), затем на вкладке Пользователи (Users) повысьте вашу личную учётную запись до администратора и выйдите из root.

После этого вы получите полный доступ: создайте группу, проект и подключите локальный репозиторий. Не забудьте добавить SSH‑ключи в настройках аккаунта, чтобы не вводить пароль при каждом push.

Мини‑чеклист перед установкой

• Домен/поддомен для EXTERNAL_URL.
• Открытые порты: 80/443 (HTTP/HTTPS), 22 (SSH) при использовании встроенного SSH‑демона.
• Минимум 4 ГБ ОЗУ для стабильной работы, для больших команд — больше.
• Достаточный объём диска, план резервных копий.
• Почтовый сервер или внешняя SMTP‑учётная запись для нотификаций.

Базовая пост‑установочная настройка

• Смените мастер‑пароль root и создайте личную учётную запись с правами администратора.
• Включите двуфакторную аутентификацию для администраторов и ключевых пользователей.
• Добавьте SSH‑ключи разработчиков в их профилях.
• Отключите свободную регистрацию учётных записей, если инстанс приватный (Admin → Settings → Sign-up restrictions).
• Настройте бэкапы и протестируйте процедуру восстановления.

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

Резервные копии критичны. Omnibus GitLab включает механизм бэкапов, который сохраняет репозитории, базу данных и загруженные файлы.

Создать бэкап:

sudo gitlab-rake gitlab:backup:create

По умолчанию бэкапы сохраняются в /var/opt/gitlab/backups. Переносите их на отдельный сервер или в облачное хранилище и шифруйте при необходимости.

Восстановление (основные шаги):

1. Остановите возможности записи: заблокируйте доступы или остановите сервисы.
2. Убедитесь, что в /etc/gitlab/gitlab.rb корректно указан external_url и настройки окружения.
3. Остановите службы GitLab, если нужно:

sudo gitlab-ctl stop

4. Запустите восстановление выбранного бэкапа (замените BACKUP на имя файла/таймстамп):

sudo gitlab-rake gitlab:backup:restore BACKUP=TIMESTAMP

5. Пересоздайте конфигурацию и перезапустите сервисы:

sudo gitlab-ctl reconfigure
sudo gitlab-ctl start
sudo gitlab-ctl status

Важно: перед реальным восстановлением прогоните процедуру на тестовом сервере.

Инцидентный план: быстрое восстановление после удаления VM

1. Оцените ситуацию — есть ли бэкап с нужной датой?
2. Если есть — подготовьте новый VM с совместимой версией OS и GitLab Omnibus.
3. Скопируйте бэкап на новый сервер (scp/rsync), разместите в /var/opt/gitlab/backups.
4. Выполните восстановление, как описано выше.
5. Проверьте доступность веб‑интерфейса, корректность пользователей и репозиториев.
6. Сообщите команде о завершении и выполните дополнительные тесты push/pull.

Безопасность и жёсткая настройка

• Всегда используйте HTTPS. Проверьте сила сертификата и автоматическое обновление Let’s Encrypt.
• Ограничьте регистрацию и включите двухфакторную аутентификацию для всех администраторов.
• Настройте firewall (ufw/iptables) — оставьте открытыми минимально необходимые порты.
• Установите fail2ban или аналогичные защитные средства против перебора паролей.
• Храните бэкапы зашифрованными в отдельном хранилище.
• Регулярно применяйте обновления безопасности GitLab и операционной системы.

Приватность и соответствие требованиям (GDPR и др.)

Если у вас есть пользователи из ЕС или вы храните персональные данные, учитывайте требования к хранению и удалению данных:

• Определите политики хранения и удаления данных пользователей.
• Обеспечьте возможность удаления аккаунтов и связанных данных по запросу.
• Шифруйте бэкапы и контролируйте доступ к ним.
• Логируйте доступ и действия администраторов.

Юридические требования отличаются по странам; проконсультируйтесь с юристом при формировании политики.

Критерии приёмки

• Сайт доступен по HTTPS с корректным сертификатом.
• Создана админ‑учётная запись, ваша пользовательская учётная запись повысена до администратора.
• Приведен в порядок механизм бэкапов и тестовое восстановление прошло успешно.
• Разработчик смог добавить SSH‑ключ и выполнить push/pull в проект.

Роль‑ориентированные чеклисты

Администратор:

• Проверить EXTERNAL_URL, SSL, почту.
• Настроить ограничения регистрации и 2FA.
• Планировать бэкапы и тесты восстановления.

DevOps:

• Обеспечить мониторинг (диск, RAM, CPU), логирование и алерты.
• Настроить автоматические обновления и процедуры отката.
• Подготовить скрипты резервного копирования и ротации.

Разработчик:

• Добавить SSH‑ключ в профиль.
• Создать группу/проект, проверить доступы.
• Протестировать push/pull и CI (если используется).

Тесты и сценарии приёмки

• Доступность: GET https://EXTERNAL_URL → 200 OK и валидный сертификат.
• Аутентификация: вход в web UI под root и под пользователем.
• Git: локальный git push и git clone проекта через SSH и HTTPS.
• Бэкап/восстановление: создать бэкап и корректно восстановить тестовый репозиторий.

Когда развёртывание может не подойти

• Очень ограниченные ресурсы: на старых VPS с 1 ГБ ОЗУ GitLab будет крайне медленным.
• Отсутствие дисциплины по бэкапам и обновлениям — риск потери данных.
• Требование минимальных затрат на администрирование — в таком случае облачный сервис выгоднее.

Краткая методология принятия решения

1. Оцените требования к данным и ответственности за безопасность.
2. Если нужно полное владение данными и интеграции — выбирайте self‑hosted.
3. Если нужна простота и минимальное администрирование — облачный GitLab/GitHub/GitLab SaaS или легкие альтернативы (Gitea).

Словарь в одну строку

• EXTERNAL_URL — публичный адрес вашего GitLab‑инстанса.
• Omnibus — единый пакет GitLab, включающий все компоненты (NGINX, PostgreSQL, Redis и т. д.).
• gitlab-rake — инструмент для управления бэкапами и сервисными задачами GitLab.

Важно: перед любыми критическими операциями (восстановление, переход на новую версию) протестируйте шаги на копии инстанса.

Резюме

• GitLab — мощный инструмент для self‑hosted репозиториев; требует ресурсов и администрирования.
• Следуйте чеклистам: подготовьте домен, зависимости, почту и бэкапы.
• Защитите инстанс: HTTPS, 2FA, firewall, защищённые бэкапы.
• Регулярно тестируйте восстановление, чтобы минимизировать время простоя.

Важно: каждая инфраструктура уникальна. Начните с тестовой среды и поэтапно переносите рабочие нагрузки.