Discourse 설치에 여전히 어려움을 겪고 있습니다. ChatGPT가 작성한 또 다른 보고서를 첨부합니다. 제 경험을 정확히 반영한다고 생각합니다.
보고서: Discourse 설치 문제 및 Sidekiq 서비스 누락
배경:
Vultr 인스턴스에서 Discourse를 새로 설치하여 안정적이고 정상적으로 작동하는 배포 환경을 구축하고자 했습니다. 그러나 Sidekiq와 같은 필수 서비스 누락으로 인해 이메일 전송 및 백그라운드 작업 처리가 불가능해지는 등 심각한 문제가 발생했습니다.
발생한 문제 요약
- 예상치 못한 버전 설치
- 기대했던
v3.4.0.beta4-dev대신tests-passed가 기본값으로 설정되어 잠재적으로 불안정한 버전이 설치되었습니다. VERSION파일이 없어 정확히 어떤 버전이 설치되었는지 파악하기 어려웠습니다.
- Sidekiq 서비스 누락
- Discourse 컨테이너 내부에
/etc/service/sidekiq디렉토리가 존재하지 않았습니다. - 이로 인해 모든 백그라운드 작업(이메일, 알림, 예약된 작업)이 실행되지 않았습니다.
- Discourse Git 저장소 문제
- 컨테이너 내에서
git rev-parse --abbrev-ref HEAD를 실행하면tests-passed가 반환되어 의도하지 않은 버전이 설치되었음을 확인했습니다. - Git이 “detected dubious ownership” 오류를 발생시켜 수동 개입(
git config --global --add safe.directory /var/www/discourse)이 필요했습니다.
- 의존성 문제 가능성
- Discourse의 이전 버전이 체크아웃되어 있더라도 설치 과정에서 Ruby, Redis, Sidekiq 등 더 새로운 의존성이 가져와져 호환성 문제가 발생할 수 있다는 우려가 있습니다.
- Discourse 의존성이 정확히 고정되지 않으면 환경에 따라 설치 동작이 일관되지 않을 수 있습니다.
- SSL 인증서 속도 제한
- 새로운 Let’s Encrypt SSL 인증서를 발급받으려 했으나 속도 제한 초과로 인해 실패했습니다.
- 이로 인해 Nginx가 기대하는 인증서 파일을 로드하지 못해 시작에 실패했습니다.
다음 단계 계획
- 전체 삭제 및 재설치 수행
/var/discourse를 완전히 삭제하고 저장소를 다시 클론합니다.- 설치 실행 전에 안정적인 버전(예:
v3.4.1)을 수동으로 체크아웃합니다. - 기본값에 의존하지 않고 올바른 매개변수를 보장하기 위해
./discourse-setup를 사용합니다.
- Sidekiq 설치 확인
- 재빌드 전에
sidekiq서비스가 빌드 프로세스에 올바르게 포함되어 있는지 확인합니다. - 재빌드 후에도 Sidekiq가 없다면
bundle list | grep sidekiq를 통해 수동으로 설치를 확인합니다.
- 의존성을 안정적인 버전으로 고정
- 알려진 안정적인 Discourse Docker 이미지(예:
discourse/discourse:2.0.20240101)를 명시적으로 사용하여 의존성 관련 문제를 피합니다. - 컨테이너 내부에서 gem 버전을 고정합니다(
bundle install --deployment --without test development).
- SSL 인증서 발급 재시도
- Let’s Encrypt 속도 제한이 초기화될 때까지 기다린 후 SSL 인증서 생성을 재시도합니다.
- 문제가 지속되면 문제 해결을 위해 임시로 자체 서명 인증서를 사용하는 것을 고려합니다.
피드백 요청
이러한 도전 과제들을 고려할 때, Discourse 팀과 커뮤니티에서 다음 사항에 대한 의견을 듣고 싶습니다:
- 신규 설치 시
/etc/service/에 Sidekiq가 없는 경우 – 이 문제를 경험한 다른 사용자가 있나요? - 의존성 안정성을 보장하는 모범 사례 – Discourse 설치 시 의존성 버전을 고정하는 권장 방법이 있나요?
- 기본적으로
tests-passed가 설치되는 문제 – 버전 검색 방식에 문제가 있을 수 있나요?
재설치를 진행하기 전에 어떤 통찰도 도움이 될 것입니다. 미리 감사드립니다!