Personalización del comportamiento del servidor web de Discourse usando outlets

Resumen

A partir de este commit, la configuración predeterminada de nginx para Discourse incluye lo que se conoce como “outlets” (salidas): una forma compatible de inyectar declaraciones adicionales en la configuración de nginx en lugares apropiados.

Este cambio permite un enfoque más robusto para administrar la configuración y el comportamiento de un servidor web, donde anteriormente dependíamos de comandos de búsqueda/reemplazo relativamente frágiles.

Con el tiempo, adaptaremos nuestras propias plantillas de configuración para usar outlets.

Uso

Hay tres secciones de outlet compatibles:

  • before-server: declaraciones de configuración del contexto http
  • server: declaraciones de configuración del contexto server
  • discourse: declaraciones de configuración del contexto location: estas se aplican a las solicitudes reenviadas a Discourse

Ejemplos

Aquí hay algunos ejemplos de cómo usar estos outlets en su archivo de configuración app.yml para lograr objetivos.

Estos se pueden agregar en cualquier lugar donde pueda usar un comando run o file; mi recomendación es hacerlo en el hook after_code para que la reconstrucción pueda fallar rápidamente si hay algo mal con la sintaxis.

Agregar una cabecera de respuesta

Este ejemplo agrega una cabecera a cada respuesta que se reenvía a Discourse:

hooks:
  after_code:
    - file:
        path: /etc/nginx/conf.d/outlets/discourse/clacks-overhead.conf
        chmod: 444
        contents: |
          add_header x-clacks-overhead "GNU Terry Pratchett";

Resultado:

○ → curl -I https://example.contoso.com/
HTTP/2 200 
…
x-clacks-overhead: GNU Terry Pratchett

Agregar un archivo estático en una sola ruta

Este ejemplo agrega un archivo estático servido por nginx en una sola ruta, fuera del árbol normal de Discourse.

hooks:
  after_code:
    - file:
        path: /etc/nginx/conf.d/outlets/server/well-known-important-file.conf
        chmod: 444
        contents: |
          location = /.well-known/important-file {
            default_type application/json;
            root /var/www/static/;
          }
    - file:
        path: /var/www/static/.well-known/important-file
        chmod: 444
        contents: |
          {"content-free":true}

Resultado:

○ → curl -i https://example.contoso.com/.well-known/important-file
HTTP/2 200 
server: nginx
date: Fri, 07 Mar 2025 23:22:38 GMT
content-type: application/json
content-length: 22
last-modified: Fri, 07 Mar 2025 23:12:08 GMT
strict-transport-security: max-age=63072000
accept-ranges: bytes

{"content-free":true}
8 Me gusta

Creo que realmente estoy emocionado con esto, excepto… No lo entiendo muy bien. ¿El segundo ejemplo nos da una forma de servir una página estática de nuestra elección?

Exactamente.

No es una solución muy escalable en términos de gestión del contenido, pero tiene el beneficio de ser fácil de implementar.

1 me gusta

Gracias Michael, al menos entendí lo suficiente para darme cuenta de lo que está pasando.

Genial, gracias por las pistas.