저는 ARM 아키텍처를 사용 중인데, 위의 명령어를 실행하면 오류가 발생합니다. 이 플러그인이 arm에 적합하지 않은 것 같습니다.
arm용으로 메일을 수신할 수 있는 다른 플러그인이 있을까요?
arm에 대해 잘 모르기 때문에 부적합한지 여부에 대해서는 조언해 드리기 어렵지만, 이건 플러그인이 아니라는 점만 알려드리고 싶었습니다. 혹시 용어에 대한 오해가 있는 것이라면 다행이지만, 플러그인으로 설치하려고 하신 거라면 작동하지 않을 것입니다. 
답변 주셔서 감사합니다. 아, 제 실수였네요. 플러그인처럼 동작하는 줄 알았습니다. 다른 용어가 있다면 알려 주세요. 제 서버는 아마존 EC2의 새로운 칩이라고 생각하는 arm64로 실행되고 있습니다.
게시글에 설명된 대로 설치했는데, 오류가 발생하네요. arm64에서는 작동하지 않는 것 같습니다.
정확히 확인하기 위해 질문드립니다. 표준 설치 과정을 성공적으로 완료하여 arm 환경에서 Discourse 인스턴스가 정상적으로 작동하고 있지만, 특히 mail-receiver 설정만 실패하고 있다는 말씀이신가요?
어떤 오류가 발생하고 있나요? 오류 메시지를 제공해 주시면 원인을 파악하는 데 도움이 될 수 있습니다. 민감한 정보가 포함되어 있는지 주의 깊게 확인하여 마스킹 처리해 주세요.
Discourse와 관련하여 특정 용어를 정하기가 좀 어렵습니다(저에게). 내부적으로 이것은 수신 전용 이메일 서버를 위한 완전히 독립적인 컨테이너 애플리케이션이며, 의도적으로 Discourse의 API를 통해 해당 이메일을 전달하도록 설정되어 있을 뿐입니다.
네, 그게 Discourse를 설치하는 표준 절차입니다. 그리고 Discourse는 arm64에서 정상적으로 작동하는 것 같습니다.
에러는 다음과 같습니다.
Status: Downloaded newer image for discourse/mail-receiver:release
docker.io/discourse/mail-receiver:release
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/bin/gem: exec format error
cd /pups && /pups/bin/pups --stdin
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
일단 당분간 AWS WorkMail을 사용하기로 했습니다. 하지만 Discourse에 간단한 메일 수신 및 작성 기능이 있다면, 공식 메일함으로 사용하는 것이 확실히 가치가 있을 것입니다.
단순한 메일 서버라는 것은 존재하지 않습니다. 메일 서버가 있거나 없거나 할 뿐입니다. 그리고 메일 서버는 매우 복잡하며, 스팸 센터로 악용될 위험이 크고, 대부분의 클라우드/VPS 서비스에서는 사용이 금지되어 있습니다.
그래서 Discourse는 실제 메일 서버를 폴링(polling)하여 메일을 가져오고, 해당 메일 서버로 전송된 메일을 이동시킵니다. 관리자가 이를 설정한 경우에만 가능합니다.
제가 의도한 바를 오해하신 것 같습니다.
'메일 서버 생성’에 대해 말씀드린 것이 아닙니다. 오히려 이메일을 작성(보내기)하고 수신한 이메일을 읽을 수 있는 단순하면서도 좋은 인터페이스(UX)를 갖추고, 이를 통해 우리가 받은 공식 이메일에 답장할 수 있도록 하자는 것입니다.
AWS의 'Simple Email Service(SES)'는 이미 스팸 등을 제어하고 있지 않나요? 그렇다면 우리는 Discourse 내에서 UX만 제공하면 됩니다. 그러면 깔끔하면서도 단순한 UX의 메일함과 작성기가 갖추어질 것입니다.
Discourse에 단일 페이지 UX를 제공하는 것이 그렇게 복잡한 일인지 확신이 서지 않습니다. (서버가 이미 내장되어 있고, Discourse를 통해 AWS SES도 사용할 수 있으니까요.)
Discourse 기본 이미지의 경우, launcher 도구가 arm64 환경에서 실행되는 것을 감지하면 실험적인 버전이라는 경고와 함께 arm64 이미지로 전환합니다. 그러나 mail-receiver의 경우 동일한 일이 발생하지 않으며, Docker Hub의 이미지를 살펴보면 arm64 버전이 존재하지 않는 것 같습니다.
두 가지 명백한 옵션이 떠오릅니다:
- amd64 EC2 인스턴스로 전환하여, 실험적이지 않은 Discourse 설치를 수행하고
mail-receiver를 함께 설치할 수 있게 합니다. - amd64 아키텍처의 가장 작은 옵션(t3a.nano라고 생각합니다)인 두 번째 EC2 인스턴스를 추가하고,
mail-receiver를 해당 인스턴스에 설치합니다.
mail-receiver가 어디에 위치하는지는 중요하지 않습니다. 이메일로 답변 주소에 대한 DNS MX 레코드가 해당 서비스로 안정적으로 가리키고, 해당 서비스가 Discourse 인스턴스에 연결할 수만 있으면 됩니다.
이것이 info@yourcompany.com, sales@yourcompany.com, support@yourcompany.com 등의 주소로 온 이메일 처리를 의미한다면, 그룹 메시징(Group messaging)이 여러분이 원하는 기능을 제공할 것이라고 생각합니다.
즉, mail-receiver가 작동하도록 설정한 후, Discourse에서 적절한 그룹을 생성하고 해당 그룹에 하나 이상의 사용자 지정 수신 이메일 주소를 지정할 수 있습니다. 자신의 사용자 메시지를 볼 때, 소속된 그룹에 대한 받은 편지함 등이 표시됩니다.
이 도메인을 직원 이메일(예: prettygirl@yourcompany.com)로 사용하는 경우, 특정 주소(예: info@)의 이메일을 Discourse로 전달하기 위해 이메일 제공업체에서 설정을 해야 합니다. 이메일 제공업체가 제공하는 기능에 따라, 올바른 발신자 주소를 유지하면서 이메일을 Discourse로 가져오는 것이 어려울 수 있습니다. 단순히 이메일을 전달하면, Discourse는 원래 발신자가 아닌 자신의 주소에서 온 것으로 모든 것을 인식하기 때문입니다.
Microsoft 365 / Exchange의 경우, mail-receiver로 라우팅하기 위한 커넥터와 특정 이메일이 해당 커넥터를 사용하도록 만드는 전송 규칙의 조합이 작동할 것입니다.
이메일은 복잡한 문제이며, mail-receiver는 이메일 알림에 대한 답변과 기존 이메일 서비스와 중복되지 않는 도메인에서 주제(그룹에 포함된 새 메시지 포함)를 생성하는 것을 단순화하도록 설계되었습니다. 그 이상은 지원되지 않는 고급 영역으로, "그렇게 사용하도록 설계되지 않았습니다"라고 할 수 있는 영역에 접어들게 됩니다.
제목에서 제시한 질문에 대한 답은 "아니요"입니다.
1번이 처음부터 제가 생각했던 방법입니다. 현재 시점에서 이는 권장되고 지원되는 솔루션입니다.
최근 discourse_docker에서 ARM 지원 확대에 대한 움직임이 있었던 것 같지만, ARM에서 메일 리시버를 지원하는 것이 조만간 추가될 가능성은 낮아 보입니다. 하지만 이것은 그저 추측일 뿐입니다. 저는 이 문제에 대해 통제권이 없으며, 모르는 부분이 많습니다.
다른 방법은 ARM이 mail-receiver를 지원하도록 하는 방법을 찾아내고 PR을 제출하는 것입니다.
ARM을 정말, 정말, 정말 좋아하신다면 메일박스 등 모든 기능이 포함된 완전한 메일 리시버를 찾아서 수많은 메일박스를 관리하는 방법도 있습니다.
ARM 시스템에서 mail-receiver를 지원할 수 있는 것은 분명 가능합니다. 코드에는 amd64에 특화된 부분이 없습니다(적어도 제가 만들 당시에는 없었고, 그 전제를 무효화할 만한 주요 변경 사항이 있었다고는 상상할 수 없습니다). 이는 이미 amd64용으로 제공하고 있는 것처럼, Docker 이미지 관리자가 arm64용 이미지를 빌드하는 문제만 해결되면 됩니다.
누군가가 비공식 빌드를 만들어 어딘가에 올리고, pups 템플릿에 필요한 한 줄 수정 사항에 대한 설명을 함께 제공하거나, 현재 사용 중인 arm64 시스템에서 저장소를 직접 로컬 빌드하는 방법도 있습니다.
Dockerfile의 일부로 GitHub에서 /usr/local/bin으로 다운로드되는 socketee가 있습니다. 이것은 x86_64 바이너리이므로 작동하지 않지만, 명시적으로 구성된 경우에만 사용되는 것으로 보입니다.
구체적으로, 위의 해당 기능은 socketee가 실행에 실패하기 때문에 arm64에서 실패할 것입니다. arm64를 위해 빌드하면 바로 작동하지 않을 다른 것은 보이지 않습니다.
100% 확신은 없지만, 대략적인 관찰에 따르면 build 파일에 다음 줄을 추가하는 것만으로도 가능할 것 같습니다:
docker build --platform linux/arm64 --build-arg=http_proxy=$http_proxy -t discourse/mail-receiver:$1 .
docker push discourse/mail-receiver:${1}_arm64
네, mail-receiver 사용자의 대다수가 거의 확실히 하지 않을, Postfix 로그를 중앙화하는 매우 니치한 목적을 위해 포함되었기 때문에 CDCK 외부에서 이를 사용하는 것은 극히 불가능할 것이라고 판단하여 분석에서 제외했습니다.
mail-receiver가 ARM에서 작동하지 않고, IMAP가 GMail에서만 작동한다면, 이는 매우 제한적입니다.
가 제 그림자에서 실행되는 것을 처음 보는 건데, 이 점이 정말 슬픕니다.
관심 있는 분들을 위해, arm64 이미지 빌드를 수행하여 womble/discourse-mail-receiver:arm64에 업로드했습니다. 이는核心团队이 공식 이미지 빌드를 배포할 때까지 임시로 사용할 수 있도록 하기 위한 것입니다. 제한 사항(현재 socketee 미포함. 필요하다고 말씀해 주시면 추가하겠습니다), 사용 방법, 그리고 문제 보고 방법(즉, “核心团队이 아니라 저에게 알려주세요”)에 대한 자세한 내용은 제 브랜치의 README를 참고하세요.
socketee를 제거하는 PR을 올렸습니다. Remove socketee support - Pull Request #28 - discourse/mail-receiver - GitHub
mail-receiver를 discourse_docker/.github/workflows/push-web-only.yml at main · discourse/discourse_docker · GitHub 에서 사용되는 ARM64 빌드 프로세스에 맞게 변경하는 PR도 올리겠습니다.