Discourse 재구축 시 부트스트랩 단계에서 실패: Git HTTPS 타임아웃 발생, SSH 기반 대안 방법 문의

지원
1

안녕하세요,

저는 공식 discourse_docker 설정을 사용하여 Ubuntu에서 표준 셀프호스트드 Discourse를 실행하고 있습니다.

환경

  • Ubuntu Server
  • Docker
  • 공식 discourse_docker
  • 단일 컨테이너 설치 (app.yml)
  • 다음 명령을 사용하여 재빌드 수행:
cd /var/discourse
./launcher rebuild app

문제

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

역시 정상적으로 작동합니다.

제 환경에서 HTTPS를 통한 Git은 불안정합니다

Discourse 환경 내부에서:

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

은 다음과 같은 오류로 실패합니다:

SSL connection timeout

제 조사 결과, 이는 인터넷 제공업체의 GitHub HTTPS 연결 문제 때문으로 보입니다. 현재 저는 그 네트워크 문제 자체를 해결하는 데 집중하지 않고 있습니다. 대신, 제 환경에서 SSH를 통한 GitHub 연결이 정상적으로 작동하므로 SSH를 사용하여 Discourse 재빌드를 수행하는 방법을 찾고 있습니다.

GitHub SSH 인증은 작동합니다

새로운 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를 사용하려고 합니다.

달성하고자 하는 목표

제 주요 목표는 GitHub HTTPS 연결이 불안정하거나 자주 타임아웃되는 환경에서 Discourse 재빌드가 안정적으로 수행되도록 하는 것입니다.

다음 사항에 대해 알고 싶습니다:

  1. Discourse의 부트스트랩 및 재빌드가 HTTPS 대신 SSH를 통해 GitHub를 사용하도록 하는 공식적으로 지원되는 방법이 있습니까?
  2. 만약 없다면, Git HTTPS가 불안정하지만 SSH는 정상적으로 작동하는 환경에 대한 권장 접근 방식은 무엇입니까?
  3. 부트스트랩/빌드 단계에 SSH 자격 증명을 주입하는 지원되는 방법이 있습니까?
  4. discourse_docker를 구성하여 Discourse 소스 업데이트를 SSH를 통해 가져오는 데 성공한 사례가 있습니까?

미래 업그레이드에도 유지되는 솔루션을 선호하지만, 부트스트랩 중 SSH 기반 가져오기가 기술적으로 지원되는지에 대한 이해도 중요합니다.

어떤 지침도 크게 감사하겠습니다.

감사합니다.

2

출력 HTTPS가 어떤 방식으로 차단되고 있는 건가요?

HTTPS를 사용할 수 있다고 기대하는 모든 코드를 다시 작성하는 것은 쉬운 일이 아닙니다. 안정적인 네트워크가 해결책이라고 생각합니다.

3

Jay님, 설명해 주셔서 감사합니다.

추가 진단을 진행한 결과, 호스트 자체에서는 아웃바운드 HTTPS가 차단되어 있지 않은 것으로 보입니다. GitHub와 raw.githubusercontent.com에 대한 직접적인 curl 요청은 일관되게 성공합니다. 문제는 부트스트랩 컨테이너 내부에서만 발생하며, 여기서 HTTPS를 통한 git ls-remote가 간헐적으로 SSL 타임아웃을 겪고 있습니다. GitHub에 대한 SSH 기반 접근은 여전히 완전히 안정적이므로, 처음에는 부트스트랩 단계에서 깨끗한 SSH 경로를 사용할 수 있는지 탐구해 보았습니다.

HTTPS를 전제로 하는 모든 컴포넌트를 다시 작성하는 것이 어렵다는 지적은 타당합니다. HTTPS 실패가 로컬 방화벽이나 Docker 네트워킹 문제보다는 ISP의 GitHub 라우트 불안정성과 관련이 있으므로, 부트스트랩 프로세스를 수정하려는 시도보다는 업스트림 네트워크 경로를 안정화하는 데 집중할 예정입니다.

빌드 파이프라인에서 HTTPS 사용에 대한 제약 사항을 명확히 설명해 주시고 가이드를 제공해 주셔서 다시 한번 감사합니다.

4

프록시를 지정하는 방법이 있을 것 같아서, ISP 네트워크를 우회하는 프록시를 지정해 보라고 제안합니다. 다른 ISP를 찾는 것이 더 쉬워 보이지만, 현실은 우리가 바라는 만큼 그리 쉽지 않습니다.