먼저, 마땅히 감사해야 할 부분이 있습니다: 새로운 설치 프로그램은 큰 개선입니다. 작동하는 경우(대부분의 경우 그렇습니다)에, 이전의 수동 설치 절차보다 훨씬 친절한 경로이며, 이를 통해 깨끗한 설치를 완료할 수 있었습니다. 설치 프로그램을 실행하고, 항상 그랬듯이 등록/활성화를 완료한 다음, 제 사양에 맞게 app.yml을 조정하기만 하면 됩니다. 아주 쉽습니다. @Falco 팀에게 진심으로 감사드립니다. 과거의 Discourse 설치 시절과 비교하면 정말 큰 차이가 있습니다.
이 글을 올리는 이유는, 저 역시 문제를 일으킨 호스트네임을 하나 만났고, 이 경험이 셀프 호스터를 위해 설치 프로그램에서 더 명확한 정보를 제공할 수 있는 몇 가지 지점을 가리키고 있다고 생각하기 때문입니다.
잘 작동한 부분
저는 다음과 같은 설정을 사용하여 새 서버에 Discourse를 성공적으로 설치했습니다:
- 자체 도메인 사용: 예
- SMTP 사용: 예
- 현재 설치 프로그램 플로우 사용
설치는 다음과 같은 단계까지 도달했습니다:
Tallyho!
Congratulations, you installed Discourse!
Register a new account to get started.
따라서 이것은 "새로운 설치 프로그램이 고장 났다"는 게시물이 아닙니다. 설치 프로그램은 매우 잘 작동할 수 있습니다.
문제의 호스트네임
다른 설치 과정에서, 일반적인 경로를 동일하게 사용했을 때 대상 호스트네임은 다음과 같았습니다:
forum.domain.tld
설치 프로그램 명령어는 다음과 같았습니다:
wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash
선택 사항은 대략 다음과 같았습니다:
- 2GB 스왑 파일 생성: 예
- 자체 도메인 사용: 예
- 호스트네임:
forum.domain.tld - SMTP 구성: 예
- SMTP 제공자: SendGrid
- SMTP 포트: 587
설치 프로그램은 다음과 같은 단계까지 도달했습니다:
[4/5] Verifying domain configuration
? Checking your domain name...
? Connection to forum.domain.tld succeeded.
그 후 설정을 작성하고 앱을 다시 빌드했습니다.
하지만 사이트는 브라우저에서 깨끗하게 로드되지 않았습니다. 결국 증상은 다음과 같이 나타났습니다:
forum.domain.tld refused to connect
반복적인 재빌드/재시도 시도로는 해결되지 않았습니다.
Discourse Doctor 결과
./discourse-doctor는 앱 컨테이너와 예상되는 설정 값을 찾았습니다. 컨테이너는 실행 중이었고 포트 80/443이 바인딩된 것으로 보였습니다.
하지만 다음과 같이 보고했습니다:
Discourse version at forum.domain.tld: NOT FOUND
그리고 나중에:
Discourse version at localhost: NOT FOUND
이것은 문제가 단순한 공용 DNS 전파 지연과는 다르다는 느낌을 주었습니다.
ACME 속도 제한
문제 해결 과정에서 앞서, 저는 Discourse 서비스 지원 경로를 사용하여 설치도 시도했습니다:
- DiscourseID
yoursite.discourse.diy플로우
이것이 반복적인 서버 해머링/재시도 동작이 발생했고, ACME 로그에서 Let’s Encrypt 속도 제한이 표시된 곳입니다:
type: urn:ietf:params:acme:error:rateLimited
status: 429
detail: too many certificates (5) already issued for this exact set of identifiers...
유용한 로그 경로는 다음과 같았습니다:
/shared/letsencrypt/acme.sh.log
이것은 큰 교훈이었습니다. 브라우저에서는 실패가 일반적인 도달성 문제로 보였습니다. 하지만 그 시점의 실제 장애물은 인증서 발급이었습니다.
가장 혼란스러운 부분은 설치 완료/최종 상태 블록에서 이것이 실행 가능한 오류로 표시되지 않았다는 점입니다. 최종적으로 사용자에게 노출된 증상은 단순히 사이트가 브라우저 연결을 거부한다는 것이었습니다.
나중에 확인해보니 실패 체인이 더 명확하게 드러났습니다:
ACME 429 rate limit
-> zero-byte .cer files under /shared/ssl
-> nginx tries to load the zero-byte cert
-> nginx fails startup
-> ports 80/443 refuse
-> browser says connection refused
경험 속에 숨겨진 기능 요청:
인증서 단계 후 설치 프로그램/재빌드 루틴이 /shared/letsencrypt/acme.sh.log를 확인하여 다음과 같은 속도 제한 오류를 표시하면 매우 도움이 될 것입니다:
rateLimited
too many certificates
status: 429
예를 들어:
Let's Encrypt rate limit hit for this hostname.
Wait until the retry-after time shown in /shared/letsencrypt/acme.sh.log before retrying.
Repeated rebuilds may not help.
이렇게 하면 실제 문제가 ACME인데도 사용자가 DNS, SMTP, app.yml 인용부호, Docker, 또는 방화벽 문제를 쫓아다니는 것을 막을 수 있습니다.
속도 제한 해제 후
Let’s Encrypt 속도 제한 창이 해제된 후에도 여전히 혼란스러운 도메인 검증 상황을 목격했습니다.
설치 프로그램은 다음과 같이 보고했습니다:
[4/5] Verifying domain configuration
? Checking your domain name...
? Connection to forum.domain.tld succeeded.
하지만 로컬 DNS 조회는 여전히 다음과 같이 표시했습니다:
Resolve-DnsName -Name "forum.domain.tld"
그리고:
Resolve-DnsName: forum.domain.tld : DNS name does not exist.
이 두 가지가 어떻게 공존할 수 있을까요?
여러 가지 가능성이 상상됩니다:
- 서버와 워크스테이션이 다른 재귀 해석기를 사용했을 수 있음
- 한 해석기에 오래된 NXDOMAIN이 캐시되었을 수 있음
- 그 시점에 DNS 전파가 부분적이었을 수 있음
- 설치 프로그램이 단순한 DNS 조회 이외의 것을 확인했을 수 있음
- 설치 프로그램 또는 관련 서비스에 검증 상태가 캐시되었을 수 있음
어떤 것이 사실인지 주장하는 것은 아닙니다. 주로 사용자 입장에서 설치 프로그램이 "연결 성공"이라고 말하는 것이 나중에 발생하는 DNS 또는 도달성 오류를 해석하기 더 어렵게 만들 수 있다는 점을 지적하고 싶었습니다.
DNS 격리 확인
이것이 단순히 Cloudflare의 느린 전파 때문인지 테스트하기 위해 같은 존에 다른 레코드를 추가했습니다:
test.domain.tld
몇 분 안에 공용 DNS 체커 결과가 녹색(정상)으로 바뀌었습니다.
이로 인해 일반적인 Cloudflare 전파가 전체 문제의 원인이 아닐 가능성이 높아 보였습니다. 문제는 forum.domain.tld에 특화된 것처럼 보였습니다.
비교 설치
또 다른 호스트네임에서도 성공적인 설치를 경험했습니다:
discourse.domain2.tld
동일한 일반적인 설치 프로그램 경로를 사용했습니다.
DNS 진단을 위한 또 다른 테스트 호스트네임은 다음과 같았습니다:
forum.domain3.tld
이 비교 설치들이 "새로운 설치 프로그램이 고장 났다"는 생각에서 "여기서 호스트네임 특유의 문제가 발생했다"는 방향으로 제 생각을 옮게 했습니다.
현재 가설
제 현재 가설(증명되지 않음)은 forum.domain.tld가 서버 자체 외부 어딘가에 호스트네임 특유의 캐시/예약/기억된 상태가 있었을 수 있다는 것입니다.
고민해 본 곳들:
- DiscourseID
yoursite.discourse.diy플로우- 설치 프로그램 측 도메인 검증
- 이전 설정 시도와 호스트네임 간의 캐시된 관계
저가 서비스 지원 경로에 대해 고민하는 이유는, 이전에 동일한 문제 호스트네임으로 그것들을 시도해 보았고, 그 경로가 반복된 시도로 인해 결국 Let’s Encrypt 속도 제한에 도달한 경로였기 때문입니다.
다시 말하지만, 이것은 가설이지 결론이 아닙니다.
질문
- 새로운 설치 프로그램은 자체 도메인 설치 중에 Discourse가 제어하는 서비스에 접속합니까?
- DiscourseID 또는
discourse.diy플로우가 호스트네임을 예약, 기억하거나 캐시합니까? - 이전에 설정 중에 사용되거나 시도된 호스트네임에 대해 해제/초기화 경로가 있습니까?
[4/5] Verifying domain configuration은 정확히 무엇을 확인합니까?- 설치 프로그램이 최종 상태/결과 블록 전에 ACME 속도 제한 실패를 더 명확하게 표시할 수 있습니까?
도움이 되었을 것들
세 가지가 문제 해결 경로를 훨씬 명확하게 만들어 주었을 것입니다:
/shared/letsencrypt/acme.sh.log에 속도 제한 실패가 있을 때 설치 프로그램의 명확한 경고.- 도메인 검증 단계가 실제로 무엇을 확인하는지에 대한 짧은 설명.
- DiscourseID /
discourse.diy/ 설치 프로그램 측 호스트네임 캐시나 예약이 존재한다면, 그 상태를 검사하거나 해제할 수 있는 가시적인 방법.
새로운 설치 프로그램에 대한 작업에 다시 한번 감사드립니다. 정말로 올바른 방향이라고 느껴집니다. 이 글을 올리는 것도 그 정신에 따른 것입니다: 작동할 때는 아름답게 작동했고, 여기의 거친 부분은 더 나은 설치 프로그램 메시지로 훨씬 쉽게 진단할 수 있는 종류의 문제처럼 보입니다.
제 입력을 바탕으로 새로운 BFF Codex와 함께 작성했습니다.
