Войти
Стабильно

Настройка GitLab за BusinessProxy App Gateway

Пошаговая настройка самостоятельного GitLab через BusinessProxy без прямой публикации сервера GitLab в интернет.

Шаги

Выполняйте по порядку.

  1. 01Выбрать один канонический доменРедиректы, cookies, статика и WebSocket GitLab должны работать через один и тот же публичный хост.
  2. 02Подготовить внутренний GitLabПубличный TLS завершает BusinessProxy, а GitLab внутри частной сети слушает обычный HTTP.
  3. 03Создать внутреннее приложение BusinessProxyОпубликуйте GitLab через коннектор и привяжите пользовательский домен, совпадающий с external_url GitLab.
  4. 04Проверить редиректы, статику и WebSocketКорректная настройка отдаёт страницу входа и загружает CSS, JavaScript и live-endpoints с того же публичного домена.
  5. 05Разобрать типовые ошибки502, зависшая статика, циклические редиректы и ошибки CSRF обычно указывают на несовпадение домена, схемы или TLS внутреннего сервера.

Справочник

Детали реализации для настройки и проверки.

Когда использовать эту инструкциюИспользуйте эту схему, когда GitLab развёрнут в частной сети и должен открываться только через управляемую сессию внутреннего приложения BusinessProxy. BusinessProxy контролирует, кто может открыть веб-интерфейс GitLab; пользователи, проекты, группы, права и доступ к репозиториям по-прежнему управляются внутри GitLab.
  • Не оставляйте внутренний GitLab напрямую доступным из интернета.
  • Используйте один постоянный пользовательский домен, например gitlab.example.com, а не временный системный alias.
  • Запустите коннектор BusinessProxy там, где он достигает HTTP-адрес GitLab.
1. Выберите канонический публичный доменGitLab чувствителен к публичному адресу. Редиректы, CSRF-проверки, cookies, пути к статике и WebSocket-адреса формируются из external_url. Выберите один домен, который пользователи будут открывать в браузере, и используйте его везде без расхождений.
  • Рекомендуемый вид: https://gitlab.example.com.
  • Не открывайте один GitLab через несколько публичных alias-адресов; cookies и редиректы могут стать непредсказуемыми.
  • Создайте DNS-запись, которую показывает мастер пользовательского домена BusinessProxy, и дождитесь активного сертификата.
2. Настройте GitLab для работы за reverse proxyЕсли публичный HTTPS завершает BusinessProxy, GitLab обычно должен получать обычный HTTP со стороны коннектора. В Omnibus GitLab настройте внешний адрес как HTTPS, но внутренний NGINX GitLab оставьте без TLS.
external_url 'https://gitlab.example.com'

nginx['listen_port'] = 80
nginx['listen_https'] = false
  • После изменения /etc/gitlab/gitlab.rb выполните sudo gitlab-ctl reconfigure.
  • Если вы намеренно оставляете HTTPS на внутреннем GitLab, используйте сертификат, которому доверяет хост коннектора, либо отключайте проверку TLS внутреннего сервера только для этого приложения и только понимая риск.
3. Проверьте GitLab с узла коннектораПеред публикацией приложения убедитесь, что узел коннектора достигает GitLab по тому внутреннему адресу, который будет указан как upstream. Так вы отделите проблемы GitLab и сети от проблем маршрутизации BusinessProxy.
curl -I http://gitlab.internal/users/sign_in
curl -I -H "Host: gitlab.example.com" http://gitlab.internal/users/sign_in
  • Ответ должен быть HTTP 200 или штатным редиректом GitLab, а не TLS-ошибкой или таймаутом подключения.
  • Если GitLab редиректит на другой хост, сначала исправьте external_url.
4. Создайте внутреннее приложение в BusinessProxyВ рабочей области создайте внутреннее приложение для GitLab. Выберите коннектор, который достигает сервер GitLab, укажите upstream на внутренний HTTP-адрес GitLab и привяжите пользовательский домен, совпадающий с external_url.
  • Публичный пользовательский домен: gitlab.example.com.
  • Upstream URL: http://gitlab.internal или другой внутренний HTTP-адрес, доступный коннектору.
  • Переписывание редиректов и cookie-доменов обычно должно оставаться включённым, если поддержка не попросила иначе.
  • Verify upstream TLS можно не использовать, если upstream — HTTP. Для HTTPS upstream этот переключатель управляет проверкой сертификата, но не исправляет генерацию URL внутри GitLab.
5. Откройте GitLab и проверьте браузерную сессиюЗапустите GitLab из BusinessProxy или откройте пользовательский домен после создания действующей сессии приложения. Страница входа должна загрузиться как HTML 200, а CSS, JavaScript, изображения и WebSocket-запросы должны идти через тот же публичный домен GitLab.
  • Ожидаемый URL в браузере: https://gitlab.example.com/users/sign_in.
  • В DevTools Network статические файлы не должны бесконечно висеть в состоянии pending.
  • Если GitLab открывается, но затем редиректит на другой хост, исправьте external_url и повторно примените конфигурацию GitLab.
Типовой симптом: 502 от BusinessProxy502 означает, что BusinessProxy не получил рабочий ответ от GitLab upstream через коннектор. Если upstream использует HTTPS, частая причина — проверка сертификата. Если upstream использует HTTP, проверьте готовность коннектора, DNS, TCP-доступность и настроенный upstream URL.
  • Сначала используйте диагностику внутреннего приложения; она проверяет путь от коннектора до upstream.
  • Отключение Verify upstream TLS помогает только при недоверенном сертификате upstream. Оно не исправляет неправильный external_url или циклический редирект.
Типовой симптом: страница 200, но статика висит pendingКогда /users/sign_in отдаёт 200, но CSS или JavaScript не догружаются, GitLab обычно формирует URL статики, редиректы или заголовки под другой публичный адрес или схему. Проверьте external_url, listen_https, пользовательский домен и обработку Host.
  • external_url должен быть https://gitlab.example.com, а не внутренний хост и не временный системный alias BusinessProxy.
  • Если TLS завершает BusinessProxy, nginx listen_https обычно должен быть false.
  • После изменения публичного URL GitLab очистите кэш браузера или состояние service worker.
Типовой симптом: не работает вход или CSRFВход и CSRF-защита GitLab зависят от схемы, хоста и cookies. Если форма загружается, но вход неожиданно не проходит, проверьте, что браузер остаётся на каноническом домене и cookies выставляются именно для него.
  • Не смешивайте gitlab.example.com и системный alias *.business-proxy.com в одной браузерной сессии.
  • После изменения external_url выйдите и удалите старые cookies GitLab для предыдущего хоста.
Операционные замечанияBusinessProxy защищает путь веб-доступа к GitLab, но не заменяет администрирование GitLab. Жизненный цикл пользователей GitLab, права на проекты, политику SSH clone, runners и резервные копии ведите штатными средствами GitLab.
  • При первом включении проверьте вход через веб, просмотр проектов, репозиториев, merge requests, artifacts и WebSocket/live-поведение интерфейса.
  • Если пользователям нужен Git over SSH, проектируйте это отдельно. Эта инструкция описывает веб-интерфейс GitLab.
  • Оставьте прямой административный путь восстановления в ограниченной частной сети для обслуживания.
Запустить GitLab Runner с исполнителем Docker