저는 수년간 Discourse를 자체 호스팅해 왔으며, 상당히 사양이 좋은 머신에서 여러 인스턴스를 안정적으로 구성하고 운영해 왔습니다.
오늘 갑자기 포럼 중 하나가 다운되어 있는 것을 발견했습니다. 처음 원인은 디스크 공간 부족으로 보였고, 이를 해결한 뒤 Discourse 인스턴스를 다시 시작했습니다.
하지만 그 이후로 인스턴스가 주기적으로 다운되고 있습니다. 부팅할 때마다 즉시 sidekiq가 폭주하고, 실패한 이메일 작업이 대량으로 발생하며, 이로 인해 redis에 막대한 양의 상태가 저장되고 있습니다. 이것이 실제 디스크 공간 문제의 원인이었다고 생각합니다. (다음에 머신을 올릴 때 flush를 수행할 예정입니다. 하지 않으면 이 머신의 공간이 금방 부족해져 Discourse를 시작해서 flush를 할 수도 없게 될 테니까요. 하지만 flush를 해도 redis 디스크 사용량이 크게 줄지는 않는 것 같습니다.)
에러 메시지는 인증서 이름 불일치에 관한 내용을 보여주고 있는데, 제가 사용하는 메일 서버는 내부 서버이고 TLS나 인증이 필요하지 않아서 다소 의외입니다. 같은 이메일 구성을 사용하는 다른 인스턴스에서도 이메일이 더 이상 작동하지 않는 것을 확인했습니다. 메인 프로덕션 로그에서는 422 에러만 보이지만, 비밀번호 재설정 같은 작업을 수행하면 sidekiq 로그에서 유사한 에러가 나타납니다:
Jobs::HandledExceptionWrapper: Wrapped OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)
명령줄을 통해 이메일을 보낼 수 있다는 것을 확인했으므로, 이는 메일 서버 자체의 문제가 아니라 Discourse 구성에 뭔가 문제가 있는 것으로 보입니다.
최근까지 정상적으로 작동했던 원래의 메일 구성은 다음과 같습니다:
DISCOURSE_SMTP_ADDRESS: outbound-relays.techservices.illinois.edu
DISCOURSE_SMTP_PORT: 25
DISCOURSE_SMTP_ENABLE_START_TLS: false
다시 말하지만, 이 메일 서버는 내부 서버이며 사용자 이름이나 비밀번호가 필요하지 않습니다. 그리고 이 설정은 최근까지 정상적으로 작동했습니다. DISCOURSE_SMTP_OPENSSL_VERIFY_MODE를 실험해 보고 있지만, 이 옵션이 여전히 지원되는지 확신할 수 없습니다. 어쨌든 도움이 되지 않는 것 같습니다. 이 포럼들을 설정한 이후에 추가된 몇 가지 새로운 이메일 설정을 발견했지만, 이 메일 서버의 구성을 고려할 때 필요하지 않은 것 같습니다.
도움 주시면 감사하겠습니다! 지금은 컨테이너 재구축에 시간이 걸리고, 프로덕션 로그의 에러 메시지는 422 에러만 나와서 실제 근본 원인을 어디서 찾아야 할지 알 수 없어, 무엇이 문제인지 파악하거나 반복적으로 테스트하는 것조차 어려운 상태입니다. (어딘가에는 원인이 있을 텐데, 제가 그냥 놓치고 있는 것 같습니다.)