파일이 비어 있는 것으로 보입니다.
그렇다면 현재 올바른 디렉토리에 있지 않은 것입니다. 먼저 올바른 디렉토리로 이동하거나, 경로를 포함하세요 
아, 맞다, 컨테이너! 고마워
DISCOURSE_SMTP_PORT는 수신용인가요, 아니면 발신용인가요?
수신(incoming)이 아니야. 머리가 좀 녹아내려서..
그냥 app.yml 파일을 수정한 다음 나갔을 때 저장할지 물어볼까?
그 다음 다시 빌드하는 거지?
아니, SMTP는 송신용이지 않나요?
잠시 쉬었다가 새로운 마음으로 다시 생각해야겠어요…
안녕하세요. 혹시 질문 하나 해도 될까요? 단일 Discourse 인스턴스를 사용하면서 그룹을 통해 서비스하려는 물리적 그룹을 구분하고 있다면, 해당 그룹들을 개별적으로 내보내고 상태를 유지하면서, 각 그룹이 영원히 행복하게 함께 지낼 수 있는 자체 Discourse 인스턴스로 이관하는 것이 얼마나 쉬울까요? 
질문을 정확히 이해하지 못하겠습니다. 포럼의 일부를 내보낸 다음 다른 포럼에 가져오자는 말씀이신가요? 현재는 사이트 전체를 복사한 후 원하지 않는 부분을 복사본에서 삭제하는 방법 외에는 그렇게 할 수 있는 방법이 없는 것으로 알고 있습니다.
rake 작업이 있습니다. 다소 번거롭습니다(예를 들어 사용자 비밀번호에 대해서는 어떻게 처리할지 확실하지 않나요?) 하지만 작동한다고 생각합니다.
이것은 원하시는 주제 모음집인 카테고리를 가져옵니다. 게시글을 작성한 사용자들도 함께 가져오는 것 같습니다. 게시글을 작성하지 않은 다른 사용자들에 대해서는 확실하지 않습니다.
솔직히 추천하지는 않지만, 한 그룹이 매우 커져서 분리하고 싶다면 이렇게 할 수 있거나, 전체 데이터베이스를 복원한 후 원하지 않는 카테고리를 삭제하는 방법도 있습니다. 실제 데이터를 확인할 수 없으므로 어느 방법이 더 쉬운지 단정하기 어렵습니다.
다들 감사합니다. 여기서 제가 언급하고자 하는 것은 이 스레드 초반에 표현했던 요구사항입니다. 자율적이고 독립적이며 전반적으로 비공개인 소규모 그룹이 매우 많고, 그 위에 국가 차원의 공개 포럼이 있는 구조입니다.
이 글을 쓰기 불과 24시간 전에야 Discourse에 대해 알게 된 터라, 제 아이디어가 이 플랫폼에서 어떻게 구현될 수 있을지 살펴보고 있었습니다. 여러분의 소프트웨어가 제 요구사항에 얼마나 잘 부합하는지 보고 아직도 놀랍기만 합니다. 제가 원하는 것이 실제로 존재하는 줄은 몰랐거든요!
전체 소프트웨어 아키텍처가 어떻게 보일지에 대한 제약 조건은 빠르게 명확해졌습니다. 여러분의 답변을 통해, 제가 희망하는 기능이 멀티사이트 모델로 가장 잘 충족될 수 있다는 점이 확인되었습니다. @pfaffman Jay 님은 이를 위해서는 '전문성이나 자금 중 하나’가 필요하다고 덧붙였습니다. 네트워크 컴퓨팅을 학부 수준으로 공부한 경험이 있긴 하지만(그것도 꽤 오래전에) 전문성 확보 쪽으로 결심했습니다.
제가 구축 중인 시스템에 대해 더 나은 이해를 드릴 수 있기를 바랍니다.
제가 마지막으로 질문했던 내용을 명확히 하기 위해, 저는 상당히 복잡한 작업의 매우 초기 단계에 있고 여전히 적응 중입니다. 제 소규모 그룹들이 포함된 단일 인스턴스에서 이 시스템을 구축해야 할까요? 시스템이 성장하고 복잡성을 더 잘 이해하게 되면, 그룹들을 별도의 인스턴스로 분리할지 여부를 가치 판단을 통해 결정해야 하는 것일까요? 아니면 처음부터 소규모 그룹들을 Discourse의 별도 인스턴스에 두어야 할까요? 그룹들을 개별 인스턴스에 두는 것이 더 큰 제어력과 유연성을 제공하지만, 모든 그룹을 하나의 설치 환경에 두는 것과 비교했을 때 관리 오버헤드와의 트레이드오프가 있는지 궁금합니다.
결국, 멀티사이트 모델로 시작해야 하는지, 아니면 단순함을 위해 하나에서 시작해서 나중에 그룹을 별도 설치 환경으로 내보내는 것을 고려해야 하는지 묻는 것입니다. 전자(멀티사이트 모델)가 합리적인 방법인 것 같습니다.
나는 아마 멀티사이트 구성을 선택하고, 각 커뮤니티마다 자체 Discourse 인스턴스를 갖춘 별도의 서브도메인을 생성하는 방식을 취할 것 같습니다. 처음에는 단일 인스턴스로 충분하며, 단일 인스턴스가 감당할 수 있는 사용자를 초과할 정도로 사용자가 많아지면 그때는 이미 충분한 수익이 들어와서 문제가 되지 않을 것입니다.
Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy 에서 설명된 구성은 실제로 꽤 간단합니다. 아마도 저는 launcher를 통해 데이터베이스를 생성하는 방식 대신 다른 방법으로 데이터베이스를 추가할 것인데, 특히 데이터베이스를 자주 추가하는 경우라면 더 그렇습니다. 하지만 시작하기에는 충분히 좋은 방법일 것입니다.
그리고 만약 각 커뮤니티가 자체적인 세계가 되기를 원한다면, 단일 인증 소스가 필요하거나 원하지 않을 수 있으므로, 아마도 제가 처음에 생각했던 것보다 더 간단한 것이 원하시는 것일 수 있습니다.
20개 사이트로 시작할 계획인지, 2,000개 사이트로 시작할 계획인지는 명확하지 않습니다. 20개라면 위의 솔루션이 충분하지만, 2,000개라면 더 정교한 것이 필요할 가능성이 높습니다.