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.