Peu probable. C’est le genre de chose que vous ne ferez probablement qu’une seule fois, et vous le ferez lorsque vous manipulerez déjà app.yml.
Je vais essayer de faire une PR qui l’ajoutera à standalone.yml, cependant.
Et avec cela en place, c’est beaucoup plus simple !
Merci pour cela, j’ai modifié localement templates/web.letsencrypt.ssl.template.yml mais cela me facilite tellement la vie !
Devons-nous inclure le nom d’hôte (OG) dans ceci, ou seulement les alias ?
Just the aliases. The hostname is the hostname.
Alors comme ça alors ?
env:
DISCOURSE_HOSTNAME: domain.com
DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org
En réfléchissant philosophiquement à la signification de « alias », j’ai inclus les deux URL qui mènent à mon site : nzarchitecure.net.nz et www.nzarchitecture.net.nz sans aucun effet néfaste évident (et sans aucun bénéfice non plus, présumablement).
standalone.yml peut-il être modifié par ou chargé de lire les paramètres d’administrateur dans une instance Discourse en cours d’exécution ?
Si oui, cela serait d’une grande aide pour les nouveaux utilisateurs et ceux qui cherchent à migrer des domaines ou à ajouter des alias - un casse-tête de moins à rechercher et à dépanner.
Non. Ce serait vraiment mauvais si les tâches exécutées dans le conteneur pouvaient modifier des éléments comme app.yml. En fait, une bonne pratique de sécurité consiste à placer des éléments comme les clés S3 dans le fichier yml afin qu’ils soient cachés de l’interface Discourse.
Encore une fois, il est très rare que vous apportiez des modifications telles que la redirection de domaines, et cela nécessite d’autres éléments, comme les paramètres DNS. Le moment idéal pour le faire est lors de la configuration de Discourse, et lorsque vous configurez Discourse, vous modifiez le fichier yml.
Ceci a été demandé et répondu, mais il semble que DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com soit requis et pas seulement l’alias comme dans DISCOURSE_HOSTNAME_ALIASES: other.domain.com
Quelqu’un peut-il confirmer s’il vous plaît ?
Aussi, il semble que la PR de @pfaffman n’ait pas été fusionnée, donc les modèles d’exemple doivent être modifiés manuellement, n’est-ce pas ?
Non. L’exemple est déroutant. Seuls les noms SUPPLÉMENTAIRES doivent être dans DISCOURSE_HOSTNAME_ALIASES.
Vous n’avez pas du tout besoin de DISCOURSE_HOSTNAME_ALIASES à moins que votre site n’ait besoin d’un certificat pour un autre nom (comme hier lorsque j’ai déplacé quelqu’un de forum.example.com à fancyword.example.com.
Donc, j’ai fait
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: forum.example.com
Et j’ai sauvegardé le forum avant d’apporter les modifications, j’ai apporté les modifications, j’ai reconstruit, restauré la sauvegarde (le restaurateur gère la correction des références de nom d’hôte) et maintenant si vous allez sur forum.example.com, vous obtenez un certificat valide et vous êtes redirigé vers le nouveau sous-domaine.
Oui, il semble que personne n’ait remarqué la PR. Je dois toujours aller chercher ça. Bien sûr, DISCOURSE_HOSTNAME_ALIASES est « évident » mais seulement quand je le regarde. 
Merci pour cela @pfaffman
Dans mon cas, j’ai besoin de cela pour que le CDN AWS et le CDN AWS S3 fonctionnent correctement avec la mise en cache
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: cloudfront.example.com
Créer plusieurs certificats est exactement ce dont nous avions besoin/ Malheureusement, nous avons trop sollicité le compte avec certbot hier, il est donc temps de mettre ce site en prison. Je vais essayer avec un autre site maintenant que vous avez confirmé la bonne utilisation de DISCOURSE_HOSTNAME_ALIASES
Alors vous devez faire cela sur AWS.
Si vous ajoutez un autre alias, cela vous permettra d’en demander un nouveau (à moins que vous n’ayez fait quelque chose pour bloquer tout le domaine)
Il semble que cela ne soit pas nécessaire après tout. La mise en cache semble fonctionner. Je fournirai plus de détails sur Issues with AWS CDN and S3