No es probable. Es el tipo de cosa que probablemente harás exactamente una vez, y lo harás cuando ya estés modificando app.yml.
Intentaré hacer una PR que la agregue a standalone.yml.
¡Y con esto implementado, es mucho más simple!
4 Me gusta
Gracias por esto, he estado modificando localmente templates/web.letsencrypt.ssl.template.yml, ¡pero esto me facilita mucho la vida!
1 me gusta
¿Necesitamos incluir el nombre de host (OG) en esto, o solo los alias?
Solo los alias. El nombre de host es el nombre de host.
1 me gusta
¿Entonces así?
env:
DISCOURSE_HOSTNAME: domain.com
DISCOURSE_HOSTNAME_ALIASES: www.domain.com,otherdomain.org,www.otherdomain.org
1 me gusta
Reflexionando filosóficamente sobre el significado de ‘alias’, incluí ambas URL que quiero que dirijan a mi sitio: nzarchitecure.net.nz y www.nzarchitecture.net.nz sin ningún efecto perjudicial obvio (y presumiblemente ningún beneficio tampoco).
1 me gusta
¿Se puede modificar standalone.yml o se le puede encargar que lea la configuración del administrador dentro de una instancia en ejecución de Discourse?
Si es así, sería de gran ayuda para los nuevos usuarios y para aquellos que buscan migrar dominios o agregar alias, un dolor de cabeza menos que investigar y solucionar.
No. Sería muy malo si los trabajos que se ejecutan en el contenedor pudieran cambiar cosas como app.yml. De hecho, una buena práctica de seguridad es poner cosas como las claves S3 en el archivo yml para que estén ocultas de la interfaz de Discourse.
Nuevamente, es muy raro que hagas cambios como los dominios que necesitan ser redirigidos, y requieren otras cosas, como la configuración de DNS. El momento de hacerlo es cuando configuras Discourse, y cuando configuras Discourse, estás modificando el archivo yml.
1 me gusta
Esto se preguntó y se respondió, pero parece que DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com es requerido y no solo el alias como en DISCOURSE_HOSTNAME_ALIASES: other.domain.com
¿Alguien puede confirmarlo, por favor?
Además, parece que la PR de @pfaffman no se fusionó, así que las plantillas de ejemplo necesitan un cambio manual, ¿verdad?
1 me gusta
No. El ejemplo es confuso. Solo los nombres EXTRA deben estar en DISCOURSE_HOSTNAME_ALIASES.
No necesitas DISCOURSE_HOSTNAME_ALIASES en absoluto a menos que necesites que tu sitio tenga un certificado para otro nombre (como ayer cuando moví a alguien de forum.example.com a fancyword.example.com).
Así que hice
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: forum.example.com
Y hice una copia de seguridad del foro antes de hacer los cambios, hice los cambios, reconstruí, restauré la copia de seguridad (el restaurador se encarga de arreglar las referencias del nombre de host) y ahora si vas a forum.example.com obtienes un certificado válido y eres redirigido al nuevo subdominio.
Sí, parece que nadie notó el PR. Siempre tengo que ir a buscar esto. Claro, DISCOURSE_HOSTNAME_ALIASES es “obvio” pero solo cuando lo estoy mirando. 
2 Me gusta
Gracias por eso @pfaffman
En mi caso necesito esto para que AWS CDN y AWS S3 CDN funcionen correctamente con el almacenamiento en caché
DISCOURSE_HOSTNAME: fancyword.example.com
DISCOURSE_HOSTNAME_ALIASES: cloudfront.example.com
Crear múltiples certificados es exactamente lo que necesitábamos/ Desafortunadamente, ayer saturamos la cuenta con certbot demasiadas veces, así que es hora de la cárcel para ese sitio. Intentaré con un sitio diferente ahora que has confirmado el uso correcto de DISCOURSE_HOSTNAME_ALIASES
1 me gusta
Entonces necesitas hacer eso en AWS.
Si añades otro alias, te permitirá solicitar uno nuevo (a menos que hayas hecho algo para que todo el dominio sea bloqueado).
2 Me gusta
Parece que esto podría no ser necesario después de todo. El almacenamiento en caché parece estar funcionando. Actualizaré con detalles en Issues with AWS CDN and S3
1 me gusta