Not likely. It’s the kind of thing that you’re likely to do exactly once, and you’ll do it when you’re already mucking with app.yml.
I’ll see about making a PR that adds it to the standalone.yml, though.
https://github.com/discourse/discourse_docker/pull/995
And with this in place, this is much simpler!
thanks for this, i have been locally modifying templates/web.letsencrypt.ssl.template.yml but this makes my life so much easier!
Do we need to include the (OG) hostname in this, or just the aliases?
Just the aliases. The hostname is the hostname.
So like this then?
env:
DISCOURSE_HOSTNAME: domain.com
DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org
Wrestling philosophically with the meaning of ‘alias’, I included both urls that I want to lead to my site: nzarchitecure.net.nz and www.nzarchitecture.net.nz with no obvious ill effects (& presumably no benefit either).
Can standalone.yml be altered by or tasked to read administrator settings within a running instance of Discourse?
If so that would be a real help to new users and those looking to migrate domains or add aliases - one less headache to research and troubleshoot.
No. It would be really bad if the jobs running in the container could change things like app.yml. Actually, a good security practice is to put stuff like S3 keys in the yml file so that they are hidden from the Discourse interface.
Again, it’s very rare that you make changes like what domains need to be redirected, and they require other things, like DNS settings. The time to do it is when you set up Discourse, and when you set up Discourse, you’re mucking with the yml file.
이것은 이미 질문과 답변이 이루어졌지만, DISCOURSE_HOSTNAME_ALIASES: other.domain.com처럼 별칭만 사용하는 것이 아니라 DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com처럼 전체 도메인이 필요해 보입니다.
누군가 확인해 주실 수 있을까요?
또한, @pfaffman의 PR이 병합되지 않은 것으로 보이므로, 샘플 템플릿에 수동으로 변경 사항이 필요한 것이 맞나요?
아니요. 예시가 혼란스럽습니다. 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는 “명백한” 설정이지만, 제가 직접 보고 있을 때만 그렇습니다. 
@pfaffman 감사합니다.
제 경우에는 캐싱이 정상 작동하도록 AWS CDN과 AWS S3 CDN을 설정해야 합니다.
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: cloudfront.example.com
여러 개의 인증서를 생성하는 것이 정확히 우리가 필요했던 것이었습니다. / 어제 certbot으로 해당 계정에 너무 많은 요청을 보냈던 터라, 해당 사이트는 이제 ‘jail’(제한) 상태입니다. 이제 DISCOURSE_HOSTNAME_ALIASES의 올바른 사용법을 확인해 주셨으니 다른 사이트로 시도해 보겠습니다.
그렇다면 AWS에서 그렇게 처리해야 합니다.
또 다른 별명을 추가하면 새로운 인증서를 요청할 수 있습니다(전체 도메인이 차단되도록 한 것이 아니라면)."
결국 필요하지 않을 수도 있습니다. 캐싱이 작동하는 것 같습니다. https://meta.discourse.org/t/issues-with-aws-cdn-and-s3/391132에서 세부 내용을 업데이트하겠습니다.