그럴 가능성은 낮습니다. 그런 종류의 작업은 딱 한 번만 수행하게 되며, 이미 app.yml을 수정하고 있을 때 수행하게 될 것입니다.
다만, standalone.yml에 이를 추가하는 PR을 만들어 보겠습니다.
이것이 적용되면 훨씬 더 간단해집니다!
4개의 좋아요
감사합니다. 그동안 templates/web.letsencrypt.ssl.template.yml을 로컬에서 직접 수정하고 있었는데, 이렇게 해 주시니 정말 편해졌습니다!
1개의 좋아요
이 설정에 (OG) 호스트명을 포함해야 하나요, 아니면 별칭만 포함하면 되나요?
별칭만 해당됩니다. 호스트명은 호스트명 그대로입니다.
1개의 좋아요
이렇게 하면 될까요?
env:
DISCOURSE_HOSTNAME: domain.com
DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org
1개의 좋아요
‘alias’의 의미를 철학적으로 고민하다 보니, 제 사이트로 연결되길 원하는 두 개의 URL(nzarchitecure.net.nz와 www.nzarchitecture.net.nz)을 모두 포함시켰습니다. 이로 인해 눈에 띄는 악영향은 없었고(아마도 이점도 없었을 것입니다).
1개의 좋아요
실행 중인 Discourse 인스턴스에서 standalone.yml 파일을 수정하거나 관리자 설정을 읽도록 할 수 있을까요?
가능하다면 신규 사용자나 도메인 이전 또는 별칭 추가를 고려 중인 사용자에게 큰 도움이 될 것입니다. 조사와 문제 해결의 부담을 한 가지 덜 수 있으니까요.
아니요. 컨테이너에서 실행 중인 작업이 app.yml과 같은 사항을 변경할 수 있다면 정말 나쁜 일이 될 것입니다. 실제로, S3 키와 같은 항목을 yml 파일에 넣어 Discourse 인터페이스에서 숨기는 것이 좋은 보안 관행입니다.
다시 말하지만, 어떤 도메인을 리다이렉트해야 하는지와 같은 변경 사항은 매우 드물게 발생하며, DNS 설정과 같은 다른 조치도 필요합니다. 이러한 작업을 해야 할 시기는 Discourse를 설정할 때이며, Discourse를 설정할 때는 yml 파일을 조작하게 됩니다.
1개의 좋아요
이것은 이미 질문과 답변이 이루어졌지만, DISCOURSE_HOSTNAME_ALIASES: other.domain.com처럼 별칭만 사용하는 것이 아니라 DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com처럼 전체 도메인이 필요해 보입니다.
누군가 확인해 주실 수 있을까요?
또한, @pfaffman의 PR이 병합되지 않은 것으로 보이므로, 샘플 템플릿에 수동으로 변경 사항이 필요한 것이 맞나요?
1개의 좋아요
아니요. 예시가 혼란스럽습니다. DISCOURSE_HOSTNAME_ALIASES에는 추가적인 이름(EXTRA names)만 포함해야 합니다.
사이트에 다른 이름(예: 어제 forum.example.com에서 fancyword.example.com으로 이전한 경우)에 대한 인증서가 필요하지 않다면 DISCOURSE_HOSTNAME_ALIASES가 전혀 필요하지 않습니다.
따라서 다음과 같이 설정했습니다.
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: forum.example.com
변경 사항 적용 전에 포럼을 백업하고, 변경 사항을 적용한 뒤 재빌드(rebuild)하고, 백업을 복원했습니다(복원 도구가 호스트명 참조를 자동으로 수정해 줍니다). 이제 forum.example.com으로 접속하면 유효한 인증서가 적용되고 새 서브도메인으로 리디렉션됩니다.
네, 아무도 그 PR을 인지하지 못한 것 같습니다. 항상 직접 찾아봐야 합니다. 물론 DISCOURSE_HOSTNAME_ALIASES는 “명백한” 설정이지만, 제가 직접 보고 있을 때만 그렇습니다. 
2개의 좋아요
@pfaffman 감사합니다.
제 경우에는 캐싱이 정상 작동하도록 AWS CDN과 AWS S3 CDN을 설정해야 합니다.
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: cloudfront.example.com
여러 개의 인증서를 생성하는 것이 정확히 우리가 필요했던 것이었습니다. / 어제 certbot으로 해당 계정에 너무 많은 요청을 보냈던 터라, 해당 사이트는 이제 ‘jail’(제한) 상태입니다. 이제 DISCOURSE_HOSTNAME_ALIASES의 올바른 사용법을 확인해 주셨으니 다른 사이트로 시도해 보겠습니다.
1개의 좋아요
그렇다면 AWS에서 그렇게 처리해야 합니다.
또 다른 별명을 추가하면 새로운 인증서를 요청할 수 있습니다(전체 도메인이 차단되도록 한 것이 아니라면)."
2개의 좋아요
결국 필요하지 않을 수도 있습니다. 캐싱이 작동하는 것 같습니다. https://meta.discourse.org/t/issues-with-aws-cdn-and-s3/391132에서 세부 내용을 업데이트하겠습니다.
1개의 좋아요