GitLab CE на Ubuntu 24.04: пошаговая установка

MAATRIX

Команда выросла из бесплатных лимитов GitHub, а гонять приватные репозитории и CI/CD через сторонний SaaS не хочется — данные, история коммитов и секреты пайплайнов должны оставаться на своей инфраструктуре. GitLab CE закрывает это одним пакетом: git-репозитории, issue-трекер, merge request'ы, CI/CD и реестр Docker-образов в одном self-hosted инстансе. Ниже — пошаговая установка на Ubuntu 24.04 через официальный Omnibus-пакет: от подготовки сервера до рабочего HTTPS, реестра контейнеров и первого раннера.

Шаг 1. Требования к серверу и подготовка Ubuntu 24.04

GitLab CE — тяжёлое приложение: под капотом Omnibus-пакета своя PostgreSQL, Redis, Puma, Sidekiq, Gitaly и встроенный Nginx. По официальным рекомендациям GitLab, минимум для инстанса — 4 ГБ RAM и 2 vCPU, но это порог, при котором сервисы просто стартуют и не падают по OOM; для команды из 5-10 человек с активным CI/CD комфортнее брать 8 ГБ RAM и 4 vCPU. Это ориентир из документации GitLab, а не гарантия — реальное потребление зависит от числа параллельных пайплайнов и размера репозиториев, проверяйте на своей нагрузке.

Возьмите чистый VPS с root-доступом. Локацию выбирайте по тому, откуда чаще заходит команда: для разработчиков в России ниже задержка у RU-площадки, для распределённой команды или интеграций с зарубежными сервисами — US или UK. У MAATRIX все три локации доступны с оплатой картой РФ, СБП или криптой, что удобно, если часть команды или подрядчиков — за рубежом.

Обновите систему и поставьте базовые зависимости:

apt update && apt upgrade -y
apt install -y curl openssh-server ca-certificates tzdata perl

openssh-server нужен обязательно — GitLab рассчитывает, что git по SSH будет ходить через порт 22 этого же сервера. Если на сервере уже стоит своя SSH-конфигурация, ничего менять не нужно, пакет только фиксирует зависимость.

Заранее заведите A-запись для домена, под которым будет жить GitLab (например, git.vashdomen.ru), — она понадобится и для установки, и для Let's Encrypt. Если домен ещё не привязан к серверу, порядок настройки DNS с нуля разобран в статье про настройку домена и DNS на Ubuntu 24.04.

Шаг 2. Подключение репозитория и установка GitLab CE

GitLab CE ставится не из штатных репозиториев Ubuntu, а из официального Omnibus-репозитория — так пакет тянет за собой все нужные версии PostgreSQL и Redis без конфликтов с системными:

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

Скрипт добавит репозиторий и обновит списки пакетов. Дальше — сама установка, с сразу заданным внешним URL (замените на свой домен):

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

Переменная EXTERNAL_URL не просто подставляется в конфиг — по ней GitLab при первой настройке сгенерирует самоподписанный SSL-сертификат и включит редирект на HTTPS, чтобы после установки не открылась голая HTTP-страница с предупреждением браузера. Установка занимает несколько минут: скачиваются десятки зависимостей и сразу запускается первичная конфигурация (gitlab-ctl reconfigure) — не прерывайте процесс, даже если он выглядит подвисшим на 5-10 минут.

Шаг 3. Первичная настройка через gitlab.rb

Весь конфиг Omnibus-инстанса — один файл /etc/gitlab/gitlab.rb. Любое изменение в нём применяется командой:

gitlab-ctl reconfigure

После первой установки зайдите на https://git.vashdomen.ru — GitLab попросит задать пароль root-пользователя (или предложит его по умолчанию на 24 часа). Начальный пароль, если вы его не переопределили, лежит в файле:

cat /etc/gitlab/initial_root_password

Файл самоуничтожается через 24 часа после установки — сохраните пароль или смените его в интерфейсе сразу.

Базовые правки в gitlab.rb, которые стоит сделать до продакшен-использования:

external_url "https://git.vashdomen.ru"

# лимит на размер репозитория (в байтах), 0 = без лимита
gitlab_rails['gitlab_default_projects_features_container_registry'] = true

# часовой пояс сервера
gitlab_rails['time_zone'] = 'Europe/Moscow'

# отключить публичную регистрацию — только приглашения
gitlab_rails['gitlab_signup_enabled'] = false

gitlab_signup_enabled = false критичен для self-hosted инстанса, смотрящего в интернет: без него любой желающий сможет сам зарегистрироваться на вашем GitLab. После правок — снова gitlab-ctl reconfigure.

Проверьте, что фаервол пропускает только нужные порты — 80/443 для веб-интерфейса и 22 для git по SSH, остальное лучше закрыть. Настройка UFW с нуля есть в отдельной статье про установку и настройку фаервола UFW на VPS.

Шаг 4. HTTPS через встроенный Let's Encrypt

Omnibus-пакет умеет сам получать и продлевать сертификат Let's Encrypt — отдельный Certbot ставить не нужно. Добавьте в gitlab.rb:

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

Затем:

gitlab-ctl reconfigure

GitLab сам создаст задачу продления в cron встроенного планировщика и обновит сертификат до истечения срока. Единственное условие — на момент выпуска сертификата домен уже должен указывать на IP этого сервера (порт 80 должен быть доступен снаружи для HTTP-01 challenge), иначе reconfigure завершится с ошибкой валидации Let's Encrypt.

Если вместо встроенного Nginx вы хотите вынести TLS-терминацию на отдельный реверс-прокси (например, когда на одном сервере крутится несколько сервисов), это тоже рабочий вариант, но тогда letsencrypt['enable'] нужно выключить и настраивать сертификат уже на внешнем прокси — логика та же, что в общей статье про Nginx как реверс-прокси на Ubuntu 24.04, с той разницей, что GitLab отдаёт трафик на порт 8080 (или 8443 для HTTPS) вместо своего Nginx.

Шаг 5. Container Registry и первый GitLab Runner

Встроенный Container Registry превращает GitLab в полноценный реестр образов рядом с CI/CD — удобно, когда пайплайн собирает образ и тут же его публикует без внешнего Docker Hub или отдельного private registry. Регистр живёт на отдельном поддомене, так что нужна ещё одна A-запись:

registry_external_url 'https://registry.git.vashdomen.ru'
gitlab_rails['registry_enabled'] = true

После gitlab-ctl reconfigure реестр поднимется автоматически, включая собственный сертификат Let's Encrypt для поддомена (если он включён на инстансе целиком). Проверить работу можно логином из-под любой машины с Docker:

docker login registry.git.vashdomen.ru

CI/CD-пайплайны без раннера не запустятся — сам GitLab только принимает задания и раздаёт их исполнителям. Устанавливается раннер отдельным пакетом на этом же сервере или на выделенной машине (что честнее с точки зрения изоляции нагрузки):

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

Мастер register попросит URL инстанса, токен регистрации (Settings → CI/CD → Runners в веб-интерфейсе) и executor — для большинства сценариев подходит docker, тогда каждая джоба выполняется в изолированном контейнере. Если Docker на сервере ещё не стоит, порядок установки с нуля есть в статье про установку Docker на Ubuntu 24.04. Более подробный разбор настройки самих пайплайнов, кеширования и переменных окружения — в статье про настройку GitLab CI/CD на VPS.

Шаг 6. Бэкапы и обслуживание инстанса

GitLab хранит не только базу, но и репозитории, вложения, LFS-объекты и артефакты CI — бэкапить нужно всё это разом, а не только PostgreSQL. Встроенная команда делает консистентный снапшот:

gitlab-backup create

Архив попадает в /var/opt/gitlab/backups/. Важный нюанс: сама команда не бэкапит /etc/gitlab/gitlab-secrets.json и /etc/gitlab/gitlab.rb — без секретов резервная копия базы бесполезна, ключи шифрования там же. Копируйте их отдельно и храните вместе с архивом бэкапа, а лучше — вне сервера:

cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /path/to/off-server-backup/

Автоматизировать создание бэкапа удобно через cron с ротацией старых архивов — параметр gitlab_rails['backup_keep_time'] в gitlab.rb (в секундах) задаёт, сколько хранить локальные копии до автоочистки.

С обновлениями GitLab CE строже, чем с большинством пакетов: мажорные версии нельзя перепрыгивать через одну — GitLab требует последовательного апгрейда по официальному upgrade path (он рассчитывается на сайте GitLab по вашей текущей и целевой версии). Пропуск шага может сломать миграции базы. Для рабочего инстанса всегда снимайте gitlab-backup create перед апгрейдом и проверяйте путь обновления, а не просто гоните apt upgrade.

Частые вопросы