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

Содержание

Общие сведения
Установка
Настройка баз данных (Redis и PostgreSQL)
Настройка GitLab
1. Общие параметры
2. Почтовый клиент
3. Связка с Keycloak
4. Заключительные действия
Настройка nginx
Настройка Apache
Настройка сервера SSH
Запуск софта
Обновление
Заметки

1. Общие сведения

Разработка программного обеспечения в больших командах является достаточно сложным процессом требующим постоянной синхронизации и прозрачности, причем подходы при проектировании и реализации сильно отличаются от сферы ПО (веб, системный софт, embedded и т.п.). Базовым инструментом в большинстве случаев остается система управления версиями Git. Вокруг Git за долгие годы создано множество проектов расширяющих базовый функционал. Исключением здесь не является ПО GitLab, которое используется в крупных проектах, потому что предоставляет удобный интерфейс для работы с Git, возможность гибкой настройки прав доступа к репозиториям, документирования (Wiki, Bug Tracking, планирование и т.п.), CI/CD и интеграции с другими популярными инструментами для разработки софта. Думаю много слов об этом не требуется, т.к. читатель уже наверное прекрасно знаком со всем базовым функционалом GitLab, прекрасно знает о преимуществах данной системе в сравнении с другими. И эти самые преимущества влекут высокие требования к железу, в частности оперативной памяти, особенно в сравнении с легковесными Gitea, Forgejo. Дополнительно отмечу, что цель написания статьи - это сохранить полученные знания об особенностях установки и настройки GitLab, которые к тому же могут оказаться полезны другим людям.

Все действия производились в чистой клетке на FreeBSD версии 15 (настроенной по статье, но без VNET), на момент написания статьи в портах был доступен GitLab версии 18.9. Для нормальной работы GitLab потребуются сервер PostgreSQL (единственная поддерживаемая СУБД), Redis (обязательная зависимость), Nginx (можно и Apache, но для Nginx есть конфиги от разработчиков со всеми необходимыми обработками).

2. Установка

Здесь все просто, воспользуемся стандартным менеджером пакетов и установим GitLab Community Edition:

pkg install gitlab-ce

У кого имеется лицензия, то Enterprise Edition устанавливается так:

pkg install gitlab-ee

3. Настройка базы данных (Redis и PostgreSQL)

Для нормальной работы Redis много настроек производить не требуется, он вполне может функционировать при стандартных. Задаем пару строк в конфигурационном файле /usr/local/etc/redis.conf:

unixsocket /var/run/redis/redis.sock
unixsocketperm 770

Чтобы GitLab мог получить доступ к Unix-сокету добавим пользователя git в группу redis:

pw groupmod redis -m git

Добавляем в /etc/rc.conf и запускаем:

echo 'redis_enable="YES"' >> /etc/rc.conf
service redis start

Про более тонкую настройку Redis на сайте есть отдельная статья.

Установка и настройка PostgreSQL подробно рассмотрена в этой статье (хоть и написана давно, но все еще актуальна), поэтому повторяться здесь я не вижу смысла. Важно, что версии сервера и клиента должны совпадать, иначе не будет работать команда gitlab:backup:restore. Для корректной работы GitLab разработчиком порта рекомендуется задать параметр max_connections в значение 200, а если PostgreSQL используется и для других целей, тогда это значение должно быть увеличено. Вообще это значение сильно зависит от того, сколько процессов GitLab работает одновременно (Puma, Sidekiq и т.п.), так что для более тонкой настройки следует почитать документацию на официальном сайте GitLab.

4. Настройка GitLab

Итак, с точки зрения разработчиков наша инсталляция является Self-Compiled (source), поэтому конфигурация сильно отличается от распространенных примеров. В частности, у нас отсутствует единый файл с конфигом gitlab.rb и утилита администрирования gitlab-ctl. Основным конфигурационным файлом является gitlab.yml, остальные параметры разбросаны по другим файлам. Читая документацию на официальном сайте всегда учитывайте этот факт, поскольку примеры конфигурации для такой инсталляции там приводятся отдельно.

После установки нам необходимо произвести первичную настройку Git и GitLab, создать пользователя в PostgreSQL и саму базу данных с определенными параметрами, а также скомпилировать ресурсы (JavaScript, CSS и т.п.).

4.1 Общие параметры

Редактируем основной конфигурационный файл /usr/local/www/gitlab/config/gitlab.yml. Поскольку файл большой, приводить его я буду частями, но так, чтобы можно было легко спозиционироваться.

## GitLab settings
gitlab:
  ## Параметры веб-сервера (Учтите: host указываетяс в формате FQDN, не включайте в строку http:// или https://)
  host: git.your-domain.ru
  port: 443 # Если будете работать по HTTPS, то ставьте 443, иначе оставляйте как есть
  https: true # Если будете работать по HTTPS, то ставьте true, иначе false

Если вы устанавливаете GitLab для тестов и просмотра функционала, то допустимо в поле host указать IP адрес. После этого необходимо указать GitLab адреса обратных прокси. Т.к. у меня обратным прокси выступает Apache, то помимо Nginx, который по факту тоже занимается перенаправлением запросов (при чтении прилагаемых разработчиками конфигов это будет видно), я добавил несколько IP адресов в данный параметр

## GitLab settings
gitlab:
  .....
  # Trusted Proxies
  # Добавьте в список IP адрес обратного прокси, иначе в логах и админке вы будете видеть только адрес этого прокси, не фактический пользователя.
  trusted_proxies:
    - 192.168.0.2/32
    - 192.168.0.14/32
    - 127.0.0.1/8

Для того, чтобы GitLab корректно выводил время необходимо задать временную зону:

## GitLab settings
gitlab:
  .....
  ## Date & Time settings
  # Тут я указал временную зону, используемую в системе. Текущую временную зону посмотреть
  # можно так 'ls -l /etc | grep localtime'. Доступные временные зоны в системе смотрим
  # здесь 'ls /usr/share/zoneinfo' либо получаем в выводе Rails запустив
  # команду 'TZInfo::Timezone.all_identifiers'.
  time_zone: '.../...'

Также у себя я включил точку входа для сбора статистики в формате пригодном для Prometheus. Однако фактически сбором статистических данных у меня занимается Zabbix (смотрите шаблон Gitlab by HTTP). Для работы статистики в GitLab необходимо задать параметр prometheus_multiproc_dir через переменные окружения, в разделе "Запуск софта" будет показано как это сделать.

## Prometheus settings
# Если GitLab установлен из исходников, тогда необходимо самостоятельно производить настройку Prometheus
# и большинство дополнительных параметров указывать в этом разделе. В случае инсталляции через пакеты Linux
# это делается проще - через файл gitlab.rb. За дополнительной информацией обращайтесь
# к https://docs.gitlab.com/ee/administration/monitoring/prometheus/
prometheus:
  enabled: true

Помимо основного конфигурационного файла обязательно отредактируйте файл /usr/local/www/gitlab/config/database.yml, в котором в разделах main и ci укажите параметры подключения к базе данных, задайте пользователя и пароль, с которыми будет осуществляться подключение к базе данных. Параметры в обоих разделах должны быть одинаковыми. В разделе "Заключительные действия" будут приведены команды создания БД, так что изменяйте файл с учетом того, что с этими данными будет работать GitLab.

Дополнительно можно изменить параметры веб-сервера GitLab в /usr/local/www/gitlab/config/puma.rb, указав там количество процессов и потоков в каждом из них. Эти параметры существенно влияют на отзывчивость GitLab, поэтому подбираются исходя из имеющихся ресурсов на сервере и количества пользователей. Каждый процесс занимает чуть больше гигабайта оперативной памяти. При этом следует учесть, что в Ruby on Rails многопоточная работа имеет свои особенности, когда нативный код обрабатывается последовательно, а распараллеливаются только системные вызовы и некоторое небольшое количество операций (хотя у многих скриптовых языков так, если интересно, тогда читайте про Ruby GIL). Таким образом завышенное количество потоков может привести не к улучшению отзывчивости, а наоборот к взаимным блокировкам. Таким образом существенное влияние на производительность оказывает увеличение количества процессов, когда операции выполняются действительно параллельно. Отмечу, что настроек по умолчанию будет достаточно для старта, при них GitLab будет отъедать около 5 Гб оперативной памяти и закрывать потребность около 100 человек (имейте ввиду, что это оценочно, т.к. используемый функционал GitLab у всех разный).

Ниже будут приведены настройки отдельных функций GitLab, без которых он может нормально работать. Если в них у вас нет необходимости тогда переходите сразу к разделу "Заключительные действия". Остальные параметры вроде настроек по умолчанию для репозиториев и т.п. производите по своему усмотрению. Каждый параметр достаточно подробно прокомментирован.

4.2 Почтовый клиент

Если отправка почтовых сообщений не нужна, тогда можете пропустить этот раздел. Для направления пользователям уведомлений, в т.ч. для восстановления пароля, GitLab использует электронную почту. Настройка этой функции производится в нескольких файлах: в основном конфигурационном файле указываются почтовый адрес, подписи заголовков и остальные реквизиты, а в файле /usr/local/www/gitlab/config/initializers/smtp_settings.rb указываются параметры подключения к серверу и реквизиты пользователя, под которыми GitLab будет авторизовываться на почтовом сервере. Если вы не планируете использовать данный функционал GitLab, тогда можете пропустить эту часть.

## GitLab settings
gitlab:
  .....
  ## Email settings
  # Uncomment and set to false if you need to disable email sending from GitLab (default: true)
  email_enabled: true
  # Email address used in the "From" field in mails sent by GitLab
  email_from: gitlab@git.your-domain.ru
  email_display_name: GitLab Your Display name
  email_reply_to: noreply@your-domain.ru

В файле /usr/local/www/gitlab/config/initializers/smtp_settings.rb я задал следующее:

if Rails.env.production?
  Rails.application.config.action_mailer.delivery_method = :smtp
  secrets = Gitlab::Email::SmtpConfig.secrets

  ActionMailer::Base.delivery_method = :smtp
  
  # Доступные параметры конфигурации нужно смотреть в документации Ruby on Rails на класс ActionMailer.
  ActionMailer::Base.smtp_settings = {
    address: "172.16.0.3",
    port: 465,
    user_name: "gitlab@git.your-domain.ru",
    password: "1234",
    domain: "git.your-domain.ru",
    authentication: :plain,
    enable_starttls_auto: false, # Если для подключения используется SSL/TLS, тогда должно быть выключено
    tls: true, # У меня используется TLS
    openssl_verify_mode: 'none' # управляет проверкой сертификатов удаленного сервера
  }
end

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

4.3 Связка с Keycloak

Если этот функционал Вам не нужен, то можно спокойно пропустить этот раздел. А так, помимо основного механизма авторизации (логин/пароль) для входа в GitLab у меня применяется OpenID, а в качестве провайдера выступает Keycloak. Настройку Keycloak я здесь приводить не буду, т.к. она является стандартной как и для любого другого клиента OpenID, а вот часть основного конфигурационного файла приведу. При этом имейте ввиду, что в Community Edition не работает сопоставление групп пользователей, поскольку данный функционал доступен только в Enterprise Edition.

## Параметра OmniAuth
omniauth:
  # Разрешить вход в GitLab через Google, GitHub, OpenID  и т.п.
  enabled: true

  # Укажите здесь провайдеров, через которые система будет автоматически выполнять вход без
  # отображения страницы входа GitLab (по умолчанию: показывать страницу входа GitLab)
  # auto_sign_in_with_provider: openid_connect

  # В списке задаются провайдеры, сведения из которых будут синхронизироваться при каждом
  # входе пользователя (по умолчанию: не задано). Задается в виде массива, например ["saml", "google_oauth2"],
  # либо true/false, чтобы разрешить всех провайдеров или ни одного.
  # Когда используется аутентификации через LDAP электронная почта пользователя синхронизируется всегда.
  sync_profile_from_provider: ['openid_connect']

  # Выберите, какую информацию синхронизировать от указанных выше провайдеров. (по умолчанию: email).
  # Параметр можно задать в виде массива аттрибутов. Доступные варианты: "name", "email" и "location".
  # Если параметр установлен в true, то синхронизируются все доступные аттрибуты.
  # Заданные здесь аттрибуты станут доступны только для чтения.
  # sync_profile_attributes: true

  # ВНИМАНИЕ!
  # Установка этого параметра позволит пользователям входить в GitLab, даже если у них еще нет учетной записи.
  # Провайдеры задаются в виде массива, например ["saml", "google_oauth2"] либо указывается true/false,
  # чтобы разрешить всех провайдеров или ни одного.
  # Учетные записи пользователей будут создаваться автоматически после успешной аутентификации.
  allow_single_sign_on: ["openid_connect"]

  # Блокировать автоматически созданных пользователей до тех пор, пока они не будут проверены администратором
  # (по умолчанию: true)
  block_auto_created_users: false

  # Искать новых пользователей на серверах LDAP. Если найдено совпадение (тот же uid), тогда автоматически
  # связывать учетную запись OmniAuth с учетной записью LDAP. (по умолчанию: false)
  auto_link_ldap_user: false

  # Разрешить пользователям с существующими учетными записями входить в систему и автоматически
  # связывать свою учетную запись через SAML, без необходимости предварительного ручного входа
  # и ручного добавления SAML (по умолчанию: false)
  auto_link_saml_user: false

  # ВНИМАНИЕ!
  # Здесь указывается лимит для размера SAML-сообщений в байтах (по умолчанию: 250000)
  # Слишком высокий лимит может привести к недоступности сервера из-за DDoS-атак.
  saml_message_max_byte_size: 250000

  # Разрешить пользователям с существующими учетными записями входить в систему и автоматически
  # связывать свою учетную запись с провадйером OmniAuth без необходимости предварительного ручного входа
  # и ручного добавления. Связь происходит по email адресу. Провайдеры задаются в виде массива,
  # например ["saml", "google_oauth2"] либо указывается true/false, чтобы разрешить всех провайдеров
  # или ни одного (по умолчанию: false)
  auto_link_user: ["saml", "google_oauth2", "openid_connect"]

  # Указанные здесь провайдеры OmniAuth будут рассматриваться системой как внешние, в результате
  # все пользователи, создавшие учетные записи через этих провайдеров, не смогут получить доступ
  # к внутренним (internal) проектам. Необходимо использовать полное имя провайдера,
  # например google_oauth2 для Google. Полные имена смотрите в документации на оф. сайте.
  # (по умолчанию: [])
  external_providers: ["google_oauth2"]

  # ВНИМАНИЕ!
  # При авторизации через указанных здесь провайдеров пользователи будут входить в систему
  # без двухфакторной аутентификации. Провайдеры задаются в виде массива, например
  # ["saml", "google_oauth2"] либо указывается true/false, чтобы разрешить всех провайдеров
  # или ни одного. Здесь следует указывать только тех провайдеров, которые авторизуют
  # пользователей через собственную двухфакторную аутентификацию. Этот параметр не имеет
  # влияния на SAML (по умолчанию: false).
  allow_bypass_two_factor: ["saml", "google_oauth2", "openid_connect"]


  ## Провайдеры аутентификации
  # Раскомментируйте следующие строки и задайте настройки провайдера, который хотите использовать.
  # Если вашего провайдера аутентификации нет в списке, тогда обращается к документации на оф. сайте
  # https://github.com/gitlabhq/gitlab-public-wiki/wiki/Custom-omniauth-provider-configurations
  # и настраиваем все самостоятельно. Параметры 'app_id' и 'app_secret' всегда передаются первыми,
  # после них следуют необязательные 'args', которые могут быть либо хешем, либо массивом.
  # Документация по этому вопросу доступна по адресу http://doc.gitlab.com/ce/integration/omniauth.html
  providers:
    - { name: 'openid_connect',
        label: 'Keycloack',
        icon: 'https://www.your-domain.ru/keycloak.ico',
        args: {
          name: 'openid_connect',
          scope: ['openid','profile','email','offline_access'],
          response_type: 'code',
          issuer: 'https://keycloak.addr.ru/realms/realmname',
          discovery: true,
          client_auth_method: 'query',
          uid_field: 'preferred_username',
          send_scope_to_token_endpoint: false,
          pkce: false,
          client_options: {
            identifier: 'your_identifer_from_keycloak',
            secret: 'secret_for_client_from_keycloak',
            redirect_uri: 'https://git.your-domain.ru/users/auth/openid_connect/callback'
            #gitlab: {
            #  groups_attribute: 'groups',
            #  required_groups: ['gitlab_user'],
            #  external_groups: ['Freelancer'],
            #  auditor_groups: ['Auditor'],
            #  admin_groups: ['Administrator']
            #}
          }
        }
      }

4.4 Заключительные действия

Итак, после редактирования конфигурационных файлов GitLab необходимо наполнить базу данных, скомпилировать ресурсы, а после настроить nginx и Apache для проксирования запросов, и добавить все сервисы в автозагрузку. Сначала зададим базовые настройки окружения, в котором будет работать GitLab (проще всего скопировать текст в скрипт и запустить, чтобы каждую команду не вводить отдельно):

## Глобальные параметры git
# Автоматическая обработка окончаний строк 'autocrlf' (необходимо для web editor)
su -l git -c "git config --global core.autocrlf input"

# Выключаем автоматическую очистку в репозиториях, т.к. этим процессом будет управлять GitLab
su -l git -c "git config --global gc.auto 0"

# Enable packfile bitmaps. При переупаковке репозитория Git создает битовые карты (bitmaps),
# которые значительно ускоряют операции клонирования и выборки (fetch).
# Указанное увеличивает производительность при передаче данных,
# особенно для больших репозиториев.
su -l git -c "git config --global repack.writeBitmaps true"

# Позволяет серверу сообщать клиентам о поддержке опций для команды push.
# Таким образом клиенты могут передавать дополнительные параметры при выполнении git push --push-option,
# что полезно для интеграции с CI/CD и другими сервисами GitLab.
su -l git -c "git config --global receive.advertisePushOptions true"

# В результате включения этой опции Git будет принудительно записывать на диск:
#   - objects — объекты Git (коммиты, деревья, blobs)
#   - derived-metadata — производные метаданные
#   - reference — ссылки (ветки, теги)
# Это снижает риск повреждения репозитория при внезапном отключении питания или сбое сервера,
# гарантируя, что критически важные данные физически сохранены на диске.
su -l git -c "git config --global core.fsync objects,derived-metadata,reference"

# Директория .ssh должна существовать для нормальной работы через SSH
su -l git -c "mkdir -p /usr/local/git/.ssh"

# Директория, в которой будут храниться репозитории, должна существать 
# и иметь корректные права доступа
su -l git -c "mkdir -p /usr/local/git/repositories"
chown git:git /usr/local/git/repositories
chmod 2770 /usr/local/git/repositories

Далее создаем пользователя и базу данных для GitLab с необходимыми правами и расширениями. Имя пользователя должно совпадать с тем, которое вы указали в /usr/local/www/gitlab/config/database.yml. В официальных руководствах предлагается вручную создать базу данных с необходимыми расширениями, однако в ходе инициализации GitLab удалит эту базу данных и создаст заново под себя (видимо с какой-то версии реализовали автоматическое создание БД, а документацию не обновили). Данный факт я проверил на версиях 18.8 и 18.9. Главное, чтобы перед инициализацией, пользователь, под которым будет работать GitLab, обладал правом создания баз данных:

psql -d template1 -U postgres -c "CREATE USER git CREATEDB PASSWORD 'password';"

# Команды ниже не требуются, оставил их на всякий случай
psql -d template1 -U postgres -c "CREATE DATABASE gitlabhq_production OWNER git;"
psql -U postgres -d gitlabhq_production -c "CREATE EXTENSION IF NOT EXISTS pg_trgm;"
psql -U postgres -d gitlabhq_production -c "CREATE EXTENSION IF NOT EXISTS btree_gist;"
psql -U postgres -d gitlabhq_production -c "CREATE EXTENSION IF NOT EXISTS plpgsql;"

Важно, что после завершения установки GitLab право на создание баз данных у этого пользователя надо отозвать. Итак, инициируем создание базы данных и ее наполнение, при этом в процессе выполнения на вопрос GitLab о создании БД нужно будет ответить положительно:

# GitLab потребуется запись в директорию для создания символической ссылки
chown git /usr/local/share/gitlab-shell

su -l git -c "cd /usr/local/www/gitlab && rake gitlab:setup RAILS_ENV=production"

# Восстаналиваем права на директорию
chown root /usr/local/share/gitlab-shell

Если все прошло без ошибок, тогда в выводе в консоли вы увидите "Administrator account created:", где будет сказано, что администратор создан и пароль надо будет установить при первом входе в веб-интерфейс. Возможно создать администратора с предустановленными паролем и почтовым адресом, передав команде инициализации дополнительные переменные GITLAB_ROOT_PASSWORD=yourpassword и GITLAB_ROOT_EMAIL=youremail.

Кроме того GitLab создаст файл /usr/local/www/gitlab/config/secrets.yml, в котором содержатся ключи шифрования для сессий и защищенных переменных. Сохраните резервную копию этого файла в надежном месте, но не храните ее вместе с резервными копиями базы данных. В противном случае защищаемые данные будут легко раскрыты, если одна из ваших резервных копий будет скомпрометирована.

Теперь пришло время к запуску одной из затратных процедур - компиляции ресурсов GitLab. Выполняем в консоли следующие команды:

su -l git -c "cd /usr/local/www/gitlab && yarn config set python /usr/local/bin/python3.11"
su -l git -c "cd /usr/local/www/gitlab && yarn install --production --pure-lockfile"
su -l git -c "cd /usr/local/www/gitlab && RAILS_ENV=production NODE_ENV=production USE_DB=false SKIP_STORAGE_VALIDATION=true bundle exec rake gitlab:assets:compile"

На версиях 18.8, 18.9 и вероятно последующих при исполнении команды gitlab:assets:compile потребуется порядка 12 Гб оперативной памяти. В случае аварийного завершения процесса компиляции из-за нехватки памяти добавляем swap (путем создания файла или просто отключаем ненужные в текущий момент сервисы), после чего убеждаемся, что все процессы, связанные с компиляцией завершились, и только после - запускаем компиляцию повторно.

5. Настройка nginx

Если nginx не установлен, тогда надо его установить, т.к. он будет проксировать запросы к GitLab. Исключать его из конфигурации я не стал, т.к. разработчики GitLab предоставляют конфигурационный файл только к этому веб-серверу (однако отмечу, что в сети можно найти настройки для Apache). К тому же, в моей конфигурации GitLab находится в клетке, а обслуживанием 443 порта на внешнем IP адресе занимается Apache, поэтому данный подход самый быстрый и простой. В основном конфигурационном файле /usr/local/etc/nginx/nginx.conf я убрал все секции server, т.к. кроме GitLab он ничего не обслуживает, и в конце (т.е. последней директивой в секции http) подключил файл /usr/local/www/gitlab/lib/support/nginx/gitlab. Если у вас nginx обслуживает внешние запросы и предполагается подключение по TLS, тогда подключать нужно файл gitlab-ssl. После этого необходимо отредактировать подключенный файл, задать там параметры listen, server_name и др.

6. Настройка Apache

У меня для GitLab директивы прокси заданы в виртуальном хосте, приведу часть конфига:

<VirtualHost 172.16.0.2:443>
  ServerName git.your-domain.ru

  ....

  LimitRequestBody 536870912
  ProxyPreserveHost On
  ProxyAddHeaders On
  ProxyRequests off
  AllowEncodedSlashes NoDecode
  ProxyPass "/.well-known/acme-challenge" !
  ProxyPass "/.well-known/pki-validation" !
  ProxyPass "/error/" !
  ProxyPass "/"  "http://ipaddr:80/" timeout=60 nocanon
  ProxyPassReverse "/"  "http://ipaddr:80/" timeout=60

  # Enable module mod_proxy_http for add headers:
  # X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Server
  RequestHeader set X-Real-IP "%{REMOTE_ADDR}s"
  RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}s"
  RequestHeader set X-Forwarded-Proto "https"
  RequestHeader set X-Forwarded-Ssl "on"
</VirtualHost>

В директивах ProxyPass и ProxyPassReverse замените IP адрес на тот, на котором работает сервер nginx.

7. Настройка сервера SSH

В составе GitLab имеется встроенный SSH сервер, однако я предпочитаю использовать системный. Вот основные параметры, которые следует задать для обеспечения безопасности сервера:

# Запрещаем логин под пользователем root
PermitRootLogin no

# Разрешаем аутентификацию с использованием публичных ключей
PubkeyAuthentication yes

# Запрещаем аутентификатю на основании доверенных хостов
HostbasedAuthentication no

# Отключаем аутентификацию по паролям 
PasswordAuthentication no
PermitEmptyPasswords no
KbdInteractiveAuthentication no

# Kerberos options
KerberosAuthentication no

# GSSAPI options
GSSAPIAuthentication no

# Явно отключаем избыточный функционал, который точно не потребуется для работы GitLab
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no

# Доступ по SSH нужен только для GitLab, поэтому разрешаем доступ
# одному пользователю в системе.
AllowUsers git

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

8. Запуск софта

Ну вот мы и дошли до этапа, когда можно посмотреть на результат проделанных действий. Добавляем все сервисы, которые подлежат автоматическому запуску, в /etc/rc.conf через sysrc или руками:

nginx_enable="YES"
gitlab_enable="YES"

Запускаем командами service gitlab start и service nginx start. После запуска GitLab, если все прошло успешно, тогда скрипт выведет сообщение "GitLab and all its components are up and running". В случае наличия каких-либо ошибок это наглядно будет видно в консоли, кроме этого GitLab пишет логи в директорию /usr/local/www/gitlab/log.

Дополнительно состояние GitLab можно проверить командой:

su -l git -c "cd /usr/local/www/gitlab && rake gitlab:check RAILS_ENV=production SANITIZE=true"

В выводе данной команды будет сообщено об ошибке systemd, но оно и ладно, т.к. на FreeBSD не используется. Переменная окружения SANITIZE используется для того, чтобы в выводе команды не печатались имена репозиториев. Если все запустилось без ошибок, тогда заходим в GitLab по IP адресу или доменному имени, которые вы указывали в настройках. В случае если у вас после установки пароля пользователю root не получается войти в GitLab и в логах имеется ошибка "ERROR no partition of relation “audit_events” found for row", тогда смотрите раздел "Заметки".

9. Обновление

Я опишу процесс обновления GitLab в рамках перехода на версию со свежим патчем (то есть последней цифрой в версии). Порядок обновления для остальных вариантов обновления долго излагать и статья получилась бы переполненной. К тому же данные варианты все равно требуют погружения во внесенные изменения и чтение инструкций на ресурсе разработчика порта GitLab. Последовательность обновления GitLab следующая:

1. Делаем резервную копию командой:

su -l git -c "cd /usr/local/www/gitlab && rake gitlab:backup:create RAILS_ENV=production"

2. Останавливаем все сервисы GitLab.

3. Обновляем пакеты:

pkg upgrade
pkg autoremove

4. Обновляем зависимости и ресурсы GitLab:

rm /usr/local/www/gitlab/Gemfile.lock
su -l git -c "cd /usr/local/www/gitlab && yarn config set python /usr/local/bin/python3.11"
su -l git -c "cd /usr/local/www/gitlab && rake db:migrate RAILS_ENV=production"
su -l git -c "cd /usr/local/www/gitlab && yarn install --production --pure-lockfile"
su -l git -c "cd /usr/local/www/gitlab && RAILS_ENV=production NODE_ENV=production USE_DB=false SKIP_STORAGE_VALIDATION=true bundle exec rake gitlab:assets:compile"
su -l git -c "cd /usr/local/www/gitlab && rake cache:clear RAILS_ENV=production"

Можно конечно сделать исполнение команд в скрипте, однако лучше контролировать процесс на каждом шаге. Не забываем, что при исполнении команды gitlab:assets:compile потребуется порядка 12 Гб оперативной памяти. В случае аварийного завершения процесса компиляции из-за нехватки памяти, добавляем swap, после чего убеждаемся, что все процессы, связанные с компиляцией завершились, и только после - запускаем компиляцию повторно.

5. Запускаем сервисы GitLab.

Кому хочется проверить состояние GitLab после обновление, можно запустить также через su команды rake gitlab:env:info RAILS_ENV=production и rake gitlab:check RAILS_ENV=production. Я считаю это избыточным в случае если в процессе обновление не возникало ошибок.

10. Заметки

После установки GitLab и установки пароля пользователю root я не смог зайти в веб-интерфейс. В логах постоянно фигурировали ошибки "ERROR no partition of relation “audit_events” found for row" и "ERROR no partition of relation “user_audit_events” found for row" (текст может немного отличаться в зависимости от версии PostgreSQL). Решил проблему созданием в БД руками отсутствующих разделов таблиц:

CREATE TABLE audit_events_p2026_02 PARTITION OF audit_events
FOR VALUES FROM ('2026-02-01') TO ('2026-03-01');
CREATE TABLE user_audit_events_p2026_02 PARTITION OF user_audit_events
FOR VALUES FROM ('2026-02-01') TO ('2026-03-01');

# Назначаем владельца созданных таблиц
ALTER TABLE audit_events_p2026_02 OWNER TO git;
ALTER TABLE user_audit_events_p2026_02 OWNER TO git;

# Проверка, что разделы созданы
SELECT * FROM pg_partition_tree('audit_events');
SELECT * FROM pg_partition_tree('user_audit_events');

Логично, что сегодняшняя дата на Вашем календаре должна укладываться в заданный запросе диапазон дат. В ходе изысканий в Интернете я находил сведения, что данная проблема может проявиться при некорректно настроенном времени на сервере, а имена разделом таблиц вроде как должны быть такими. Мне это помогло и проблем со входом в веб-интерфейс более не возникало.

Полезные ссылки

Инструкции установки и обновления разных версий GitLab

Официальное руководство по установке самосборной копии GitLab

Рекомендации по безопасности GitLab

Ваше имя

CAPTCHA

С помощью какой утилиты можно получить справку к консоле?

Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.

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

Последние статьи

Последние комментарии

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

Добавить комментарий

Последние статьи

Последние комментарии