GitLab CE — полноценная платформа для хранения репозиториев, код-ревью и CI/CD, которую можно развернуть на своём сервере. Community Edition бесплатна и покрывает задачи небольшой команды: merge request, issues, реестр контейнеров, пайплайны и резервное копирование. Разберём установку на Ubuntu, выпуск TLS-сертификата, подключение раннера, бэкапы и обслуживание без простоя.

Что даёт свой GitLab

Облачный хостинг репозиториев удобен, пока не появляются требования к месту хранения кода и к доступу из внутренней сети. Собственный сервер даёт полный контроль над данными, интеграцию с локальным LDAP и собственные политики доступа. Плата за это — администрирование: обновления, диск, память и мониторинг лежат на вас.

Community Edition отличается от Enterprise Edition набором функций, а не ядром. Репозитории, CI, реестр образов и базовые права есть в бесплатной версии. Платные возможности вроде расширенной аналитики и части функций безопасности в CE недоступны, но для большинства задач хватает бесплатного набора.

  • Неограниченное число приватных репозиториев.
  • Merge request, protected branches, code owners.
  • Встроенный CI/CD на основе .gitlab-ci.yml.
  • Container Registry и GitLab Pages.
  • Резервное копирование через gitlab-backup.

Требования к серверу

Официально минимальный порог — 4 ГБ памяти, но на такой машине GitLab с включённым мониторингом будет постоянно уходить в swap. Для команды до десяти человек разумный старт — 4 ядра, 8 ГБ RAM и SSD. Диск считается просто: репозитории, артефакты пайплайнов и образы реестра растут быстро, поэтому 50 ГБ — это нижняя граница, а не запас.

Отдельно проверьте, что включён swap и настроен часовой пояс. Ещё до установки стоит зарезервировать DNS-имя: external_url потом менять тяжело, он попадает в ссылки, хуки и конфигурацию раннеров.

Установка Omnibus-пакета

Пакет Omnibus приносит свой PostgreSQL, Redis, Nginx и Puma, поэтому конфликтов с системными версиями меньше. Сначала ставим зависимости и подключаем репозиторий проекта.

sudo apt update
sudo apt install -y curl openssh-server ca-certificates tzdata perl
curl -fsSL https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

Установка занимает несколько минут: создаются пользователи, база и каталоги. Начальный пароль администратора лежит в /etc/gitlab/initial_root_password и удаляется через сутки — после первого входа его нужно сменить.

Первичная настройка и TLS

Все параметры собраны в /etc/gitlab/gitlab.rb. После правки файла обязательно выполняется gitlab-ctl reconfigure — он пересобирает конфигурацию всех сервисов. Ручное редактирование файлов внутри /var/opt/gitlab бессмысленно: их перезапишут.

sudo nano /etc/gitlab/gitlab.rb
sudo gitlab-ctl reconfigure
sudo gitlab-ctl status
sudo gitlab-ctl tail nginx

Для публичного домена проще всего встроенный Let’s Encrypt: достаточно указать external_url "https://gitlab.example.com", включить letsencrypt['enable'] = true и задать контактный адрес. Сертификат продлевается автоматически. Для внутреннего контура используйте собственный сертификат и пропишите пути в nginx['ssl_certificate'] и nginx['ssl_certificate_key'].

Почта и уведомления

Без SMTP не работают приглашения, сброс пароля и письма о пайплайнах. Настройки задаются в том же файле и применяются через reconfigure.

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.example.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "gitlab@example.com"
gitlab_rails['smtp_password'] = "пароль-приложения"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['gitlab_email_from'] = "gitlab@example.com"

Проверка отправки выполняется из консоли: gitlab-rails console, затем Notify.test_email('you@example.com', 'Test', 'Body').deliver_now. Если письмо не уходит, смотрите gitlab-ctl tail sidekiq — очередь писем обрабатывает именно он.

Раннер и первый пайплайн

CI выполняет отдельный агент — GitLab Runner. Его ставят на тот же сервер или на отдельную машину, чтобы сборка не отнимала ресурсы у веб-части. Токен регистрации в современных версиях выдаётся в интерфейсе проекта: Settings → CI/CD → Runners → New project runner.

curl -fsSL https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
sudo apt install -y gitlab-runner
sudo gitlab-runner register --url https://gitlab.example.com --token glrt-xxxx
sudo gitlab-runner verify

Файл .gitlab-ci.yml лежит в корне репозитория и описывает стадии. Кеш зависимостей и артефакты с отчётом тестов сильно ускоряют повторные запуски.

stages: [test, deploy]

default:
  image: python:3.12-slim
  cache:
    key: "$CI_COMMIT_REF_SLUG"
    paths: [.cache/pip]

test:
  stage: test
  script:
    - pip install -r requirements.txt
    - pytest -q
  artifacts:
    when: always
    reports:
      junit: report.xml

deploy:
  stage: deploy
  script: [./deploy.sh]
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

Секреты не хранят в репозитории: для них есть переменные CI/CD, которые маскируются в логах. Раннер с защитой стоит назначать только на защищённые ветки, иначе любой участник сможет выполнить произвольный код на сервере сборки.

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

Штатная команда создаёт архив базы и репозиториев, но не включает конфигурацию и секреты. Поэтому бэкап всегда состоит из двух частей, и хранить их нужно отдельно от сервера.

sudo gitlab-backup create
sudo tar -czf /var/opt/gitlab/backups/etc-gitlab-$(date +%F).tar.gz /etc/gitlab
sudo ls -lh /var/opt/gitlab/backups/
sudo gitlab-backup restore BACKUP=1750000000_2026_11_06

Восстановление делают на сервере той же версии GitLab: сначала останавливают Puma и Sidekiq, затем распаковывают конфиг, запускают restore и выполняют reconfigure. Проверять бэкап нужно до аварии — раз в квартал на тестовой машине, иначе архив превращается в лотерею.

Обновление без сюрпризов

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

Порядок действий: обновить пакет, выполнить reconfigure, проверить статус сервисов и прогнать встроенную проверку gitlab-rake gitlab:check SANITIZE=true. Если что-то пошло не так, остановитесь и разберите журнал, а не ставьте следующую версию поверх.

Диагностика и экономия ресурсов

Первый инструмент — gitlab-ctl status: он показывает, какие сервисы запущены и не перезапускались ли они. Дальше смотрим журналы по компонентам и общий gitlab-ctl tail. Если сервер маленький, уменьшите число процессов Puma и параллелизм Sidekiq, а встроенный Prometheus отключите, если мониторите систему снаружи.

  • puma['worker_processes'] = 2 для машин с 4 ГБ.
  • sidekiq['concurrency'] = 10 вместо значения по умолчанию.
  • prometheus_monitoring['enable'] = false при внешнем мониторинге.
  • Лимит хранения бэкапов через backup_keep_time.

Итог

GitLab CE — это не просто веб-интерфейс над Git, а полноценный контур разработки: репозитории, ревью, CI, реестр образов и бэкапы в одном пакете. Ключ к стабильности — правильный размер сервера, неизменяемый external_url, регулярные проверенные бэкапы и дисциплина обновлений. Начните с малого, включите мониторинг диска и памяти, и сервер спокойно прослужит команде несколько лет.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте