Das ist unwahrscheinlich. Das ist eine Sache, die man wahrscheinlich genau einmal macht und die man macht, wenn man sowieso schon mit der app.yml herumhantiert.
Ich werde sehen, ob ich einen PR erstellen kann, der sie zur standalone.yml hinzufügt.
Und mit dieser Funktion ist das viel einfacher!
Danke dafür, ich habe templates/web.letsencrypt.ssl.template.yml lokal modifiziert, aber das erleichtert mir das Leben ungemein!
Müssen wir den (OG) Hostnamen hier mit einbeziehen oder nur die Aliase?
Nur die Aliase. Der Hostname ist der Hostname.
Also so dann?
env:
DISCOURSE_HOSTNAME: domain.com
DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org
Philosophisch mit der Bedeutung von „Alias“ ringend, habe ich beide URLs, die zu meiner Website führen sollen, aufgenommen: nzarchitecure.net.nz und www.nzarchitecture.net.nz, ohne offensichtliche negative Auswirkungen (und vermutlich auch ohne Vorteile).
Kann standalone.yml von einer laufenden Instanz von Discourse geändert werden oder angewiesen werden, Administratoreinstellungen zu lesen?
Wenn ja, wäre das eine große Hilfe für neue Benutzer und diejenigen, die Domänen migrieren oder Aliase hinzufügen möchten – ein Problem weniger, das recherchiert und behoben werden muss.
Nein. Es wäre wirklich schlecht, wenn die im Container laufenden Jobs Dinge wie app.yml ändern könnten. Tatsächlich ist es eine gute Sicherheitspraxis, Dinge wie S3-Schlüssel in die yml-Datei zu packen, damit sie vor der Discourse-Oberfläche verborgen sind.
Auch hier ist es sehr selten, dass Sie Änderungen vornehmen, wie z. B. welche Domains umgeleitet werden müssen, und sie erfordern andere Dinge, wie z. B. DNS-Einstellungen. Die Zeit dafür ist, wenn Sie Discourse einrichten, und wenn Sie Discourse einrichten, fummeln Sie an der yml-Datei herum.
Dies wurde gefragt und beantwortet, aber es scheint, dass DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com erforderlich ist und nicht nur der Alias wie in DISCOURSE_HOSTNAME_ALIASES: other.domain.com
Kann das jemand bitte bestätigen?
Außerdem sieht es so aus, als wäre der PR von @pfaffman nicht gemergt worden, sodass die Beispielvorlagen manuell geändert werden müssen, oder?
Nein. Das Beispiel ist verwirrend. Nur ZUSÄTZLICHE Namen müssen in DISCOURSE_HOSTNAME_ALIASES stehen.
Sie benötigen DISCOURSE_HOSTNAME_ALIASES überhaupt nicht, es sei denn, Ihre Seite benötigt ein Zertifikat für einen anderen Namen (wie gestern, als ich jemanden von forum.example.com nach fancyword.example.com verschoben habe).
Also habe ich Folgendes getan:
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: forum.example.com
Und habe ein Backup des Forums erstellt, bevor ich die Änderungen vorgenommen habe, die Änderungen vorgenommen, neu erstellt, das Backup wiederhergestellt (der Wiederhersteller kümmert sich um die Korrektur der Hostnamen-Referenzen) und jetzt erhalten Sie ein gültiges Zertifikat und werden auf die neue Subdomain weitergeleitet, wenn Sie zu forum.example.com gehen.
Ja, es sieht so aus, als hätte niemand die PR bemerkt. Ich muss immer danach suchen. Sicher, DISCOURSE_HOSTNAME_ALIASES ist „offensichtlich“, aber nur, wenn ich es mir ansehe. 
Vielen Dank dafür, @pfaffman
In meinem Fall benötige ich dies, damit AWS CDN und AWS S3 CDN ordnungsgemäß mit dem Caching funktionieren
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: cloudfront.example.com
Das Erstellen mehrerer Zertifikate ist genau das, was wir brauchten. Leider haben wir das Konto gestern zu oft mit certbot bombardiert, daher ist es Zeit für eine Sperre für diese Seite. Ich werde es mit einer anderen Seite versuchen, nachdem Sie die korrekte Verwendung von DISCOURSE_HOSTNAME_ALIASES bestätigt haben.
Dann müssen Sie dies bei AWS tun.
Wenn Sie einen weiteren Alias hinzufügen, können Sie ein neues anfordern (es sei denn, Sie haben etwas getan, um die gesamte Domain zu blockieren)
Sieht so aus, als wäre das doch nicht nötig. Das Caching scheint zu funktionieren. Ich werde unter Issues with AWS CDN and S3 weitere Details bekannt geben.