Este tema es un complemento de otro, que se centra en la configuración de Discourse. Aquí configuraremos una distribución de Cloudfront como proxy inverso antes de Discourse.
La única vez que necesitas esta combinación es cuando ya tienes una distribución de Cloudfront para el nombre de host principal y deseas enrutar una subcarpeta a un foro de Discourse. Esta guía asume que el lector tiene experiencia previa utilizando Cloudfront en producción.
Flujo del Tráfico
Cuando un usuario carga el sitio, hay dos conexiones de red involucradas. Cada una tiene un nombre de host diferente:
- El navegador web emitirá una solicitud a Cloudfront para el nombre de host público.
- Luego, Cloudfront emitirá una solicitud a los servidores de Discourse para el nombre de host de origen.
.───────. .───────. .─────────.
( browser )───▶( CF )───▶( discourse )
`───────' `───────' `─────────'
Para nuestro ejemplo, haremos como si tu sitio de Discourse se cargara desde https://www.example.com/forum/, utilizando:
| propósito | nombre de host |
|---|---|
| nombre de host público | www.example.com |
| nombre de host de origen | discourse.example.com |
Configuración de Cloudfront
Esto significa que habrá al menos dos orígenes definidos: uno predeterminado para el sitio principal y un segundo para los servidores de Discourse.
También habrá al menos dos comportamientos, uno apuntando a cada origen.
El comportamiento y el origen predeterminados no son relevantes para nuestros propósitos aquí; ya deben estar configurados según sea necesario para tus necesidades. El origen y el comportamiento específicos de Discourse deben configurarse de la siguiente manera.
Origen
El segundo origen para los servidores de Discourse debe apuntar al nombre de host de origen.
No configures una ruta de origen.
La política de protocolo debe ser HTTPS, con TLSv1 como versión mínima.
Comportamiento
El patrón debe coincidir con la subcarpeta.
Debe estar asociado al origen configurado como se describió anteriormente.
Debe redirigir HTTP → HTTPS.
Debe permitir todos los verbos HTTP.
Debe desactivar la caché.
Debe reenviar todas las cabeceras del cliente.
Configuración de Lambda@edge
Los entornos de alojamiento compartido (incluido discourse.org) utilizan SNI. Para que esto funcione con Cloudfront, necesitarás usar Lambda@edge para asegurarte de que Cloudfront utilice el nombre de host de origen para SNI, en lugar de la cabecera Host de la solicitud del visitante.
Visita el panel de control de AWS Lambda y crea una nueva función. Usa el entorno de ejecución Node.js y crea un nuevo rol con “Permisos básicos de Lambda@Edge”:
Haz clic en “Create Function” (Crear función).
Una vez que aparezca el editor de código, reemplaza el ejemplo con esto:
exports.handler = async (event, context) => {
const request = event.Records[0].cf.request;
request.headers['x-forwarded-host'] = [{
key: 'x-forwarded-host',
value: request.headers['host'][0]['value']
}];
request.headers["host"] = [{
key: 'host',
value: request.origin.custom.domainName
}];
return request;
};
Haz clic en “Deploy” (Implementar).
En la esquina superior izquierda, elige Acciones → Deploy to Lambda@Edge (Implementar en Lambda@Edge).
Elige tu distribución de Cloudfront y selecciona el Comportamiento correcto de la lista:
Si necesitas realizar cambios por alguna razón, asegúrate de hacer clic en “Deploy” (Implementar), luego en “Publish new Version” (Publicar nueva versión) desde la pestaña de versiones, y finalmente actualiza tu distribución para usar la nueva versión de Lambda.