Сбой пересборки Discourse на этапе инициализации: тайм-аут Git HTTPS, ищем чистое решение на основе SSH

Поддержка
1

Здравствуйте,

Я запускаю стандартную установку Discourse с самостоятельным размещением на Ubuntu, используя официальный набор discourse_docker.

Окружение

  • Ubuntu Server
  • Docker
  • Официальный discourse_docker
  • Установка в одном контейнере (app.yml)
  • Пересборка выполняется с помощью:
cd /var/discourse
./launcher rebuild app

Проблема

Процесс пересборки завершается неудачей на этапе начальной загрузки (bootstrap), когда Discourse пытается обновить исходный код приложения из GitHub.

Ошибка возникает при выполнении:

git fetch --tags --prune-tags --prune --force origin

и сопровождается сообщением:

fatal: unable to access 'https://github.com/discourse/discourse.git/': SSL connection timeout

после чего следует:

FAILED
bootstrap failed with exit code 128

Важные выводы

GitHub доступен через HTTPS

На хосте:

curl -I https://github.com

работает корректно.

Также:

curl -I https://raw.githubusercontent.com

работает корректно.

Git по HTTPS ненадежен в моей среде

Внутри окружения Discourse:

git ls-remote https://github.com/discourse/discourse.git

завершается ошибкой:

SSL connection timeout

Согласно моим исследованиям, это, вероятно, вызвано проблемами с подключением моего интернет-провайдера к GitHub по протоколу HTTPS. В данный момент я не пытаюсь решить саму проблему с сетью. Вместо этого я ищу способ выполнять пересборку Discourse через SSH, так как подключение к GitHub по SSH в моей среде работает корректно.

Аутентификация через SSH на GitHub работает

Я сгенерировал новый SSH-ключ, добавил его в GitHub и проверил аутентификацию:

ssh -T git@github.com

возвращает:

Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.

Также:

git ls-remote git@github.com:discourse/discourse.git

успешно выполняется на хосте.

URL-адреса репозитория

На хосте я изменил /var/discourse на использование SSH:

origin git@github.com:discourse/discourse_docker.git

и операции Git работают.

Однако внутри контейнера приложения Discourse:

cd /var/www/discourse
git remote -v

показывает:

origin https://github.com/discourse/discourse.git

Таким образом, во время начальной загрузки Discourse все еще пытается использовать HTTPS.

Чего я хочу добиться

Моя главная цель — обеспечить надежную пересборку Discourse в среде, где соединения с GitHub по HTTPS нестабильны или часто приводят к тайм-аутам.

Мне хотелось бы узнать:

  1. Существует ли официально поддерживаемый способ заставить Discourse использовать GitHub по SSH вместо HTTPS при начальной загрузке и пересборке?
  2. Если нет, какой рекомендуемый подход для сред, где Git по HTTPS ненадежен, но SSH работает корректно?
  3. Существует ли поддерживаемый метод внедрения SSH-учетных данных на этапе начальной загрузки/сборки?
  4. Удавалось ли кому-либо успешно настроить discourse_docker для получения обновлений исходного кода Discourse по SSH?

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

Любые рекомендации будут очень кстати.

Спасибо.

2

Возможно, исходящий HTTPS заблокирован?

Переписывать все компоненты, которые ожидают возможность использования HTTPS, будет непросто. Боюсь, вам необходимо решить проблему с надёжностью сетевого подключения.

3

Спасибо за уточнение, Джей.

После дополнительной диагностики выяснилось, что исходящий HTTPS не заблокирован на самом хосте — прямые запросы curl к GitHub и raw.githubusercontent.com выполняются стабильно. Проблема проявляется только внутри контейнера инициализации (bootstrap), где команда git ls-remote по HTTPS периодически завершается с таймаутом SSL. Доступ к GitHub по SSH остаётся полностью надёжным, поэтому изначально я исследовал возможность использования чистого SSH-пути на этапе инициализации.

Ваше замечание о сложности переписывания всех компонентов, которые предполагают использование HTTPS, вполне обосновано. Учитывая, что сбои HTTPS связаны с нестабильностью маршрута моего провайдера к GitHub, а не с локальным файрволом или настройками Docker, я сосредоточусь на стабилизации сетевого пути на стороне провайдера, вместо того чтобы пытаться изменять процесс инициализации.

Ещё раз спасибо за советы и за разъяснение ограничений, связанных с использованием HTTPS в конвейере сборки.

4

Думаю, есть способ указать прокси-сервер, так что, возможно, вы могли бы использовать прокси, который не использует сеть вашего интернет-провайдера. Кажется, что проще найти другого провайдера, но жизнь часто бывает не такой простой, как нам хотелось бы.