AWS Cloudfront como CDN para el sitio de Heroku con dominio personalizado

5

Recientemente, compré un dominio de AWS Route 53 (brianpatrickhummel.com) para alojar una cartera personal. El sitio de la cartera está en funcionamiento, utilizando un bucket de S3 y Cloudfront como CDN. En el sitio de la cartera, los visitantes pueden obtener una vista previa de algunas aplicaciones que creé, que se inician en el sitio utilizando elementos iframe, y noté que mis aplicaciones implementadas por Heroku tardan entre 10 y 20 segundos en cargarse, ya que esos sitios tienen muy pocos visitantes en promedio y no tienen servicio CDN.

Por lo tanto, comencé a investigar sobre el uso de AWS Cloudfront como CDN. Comencé con una aplicación de Heroku, agregando un dominio personalizado que ahora está configurado como tal:

Domain Name: burger.brianpatrickhummel.com
DNS Target: burger.brianpatrickhummel.com.herokudns.com

El último paso es "configurar el proveedor de DNS de su aplicación para que apunte al destino DNS proporcionado por Heroku". Entre este paso y la configuración adecuada de una distribución de Cloudfront, me he encontrado con una espiral de confusión. No estoy seguro de dónde realizo ciertos cambios de DNS / CNAME, en Cloudfront, Route 53 o ambos.

No hay mucha documentación en línea relacionada específicamente con estas tres tecnologías (Heroku, Cloudfront, Route 53) y he pasado mucho tiempo rebotando entre estos tres artículos, sin éxito:

Heroku: uso de Amazon CloudFront CDN

Configuración del DNS de Amazon Route 53 para su aplicación Heroku

Estoy seguro de que los cambios necesarios son de naturaleza simple y agradecería enormemente cualquier información de aquellos que puedan tener experiencia con esta configuración en particular.

--- ACTUALIZACIÓN ---

Tengo una última pregunta, ahora que tengo todas mis aplicaciones de Heroku enrutadas con éxito a través de Cloudfront, me he dado cuenta de que todas las aplicaciones que tienen componentes que generan solicitudes POST HTTP reciben 403 - errores prohibidos. ¿Tiene esto algo que ver con la URL relativa en las respectivas llamadas AJAX?

$(document).on("click", ".saveButton", function () {
  var thisId = $(this).attr("id");
  $.ajax({
    method: "POST",
    url: "/save/" + thisId
  }).done(function () {} 

Veo lo siguiente en la documentación de Cloudfront:

CloudFront always caches responses to GET and HEAD requests. You can also configure CloudFront to cache responses to OPTIONS requests. CloudFront does not cache responses to requests that use the other methods.

¿Es más un problema con el manejo de las respuestas del servidor de la aplicación Heroku que con el envío exitoso de la solicitud?

- ACTUALIZACIÓN 2 -
Creo que esto tiene que ver con HTTP / HTTPS basado en esta declaración en la Documentación de Cloudfront:

CloudFront doesn't redirect DELETE, OPTIONS, PATCH, POST, or PUT requests from HTTP to HTTPS. If you configure a cache behavior to redirect to HTTPS, CloudFront responds to HTTP DELETE, OPTIONS, PATCH, POST, or PUT requests for that cache behavior with HTTP status code 403 (Forbidden).

Heroku dice:

If you are wanting to serve Cloudfront assets using SSL you can simply use HTTPS on the distribution domain given to you by Amazon. Note, whilst you can create CNAME’s for this purpose, serving Cloudfront assets over your CNAME and SSL has an attached cost.

En la configuración de comportamiento de la caché de distribución de AWS Cloudfront, puede elegir entre tres opciones para la política de protocolo de visor :

If you want CloudFront to allow viewers to access your web content using either HTTP or HTTPS, specify HTTP and HTTPS. If you want CloudFront to redirect all HTTP requests to HTTPS, specify Redirect HTTP to HTTPS. If you want CloudFront to require HTTPS, specify HTTPS Only.

El documento de Cloudfront continúa señalando:

Redirect HTTP to HTTPS Viewers can use both protocols, but HTTP requests are automatically redirected to HTTPS requests. CloudFront returns HTTP status code 301 (Moved Permanently) along with the new HTTPS URL. The viewer then resubmits the request to CloudFront using the HTTPS URL.

When a viewer makes an HTTP request that is redirected to an HTTPS request, CloudFront charges for both requests. For the HTTP request, the charge is only for the request and for the headers that CloudFront returns to the viewer. For the HTTPS request, the charge is for the request, and for the headers and the object returned by your origin.

HTTPS Only Viewers can access your content only if they're using HTTPS. If a viewer sends an HTTP request instead of an HTTPS request, CloudFront returns HTTP status code 403 (Forbidden) and does not return the object.

¡Dios mío, no tenía idea de lo complicado que sería alojar un sitio web personal!

3

Domain Name: burger.brianpatrickhummel.com

Señalará esto a CloudFront, en Route 53 ... pero antes de poder hacer eso, debe crear una nueva distribución de CloudFront y configurar ese nombre de host como un nombre de dominio alternativo para la distribución.

DNS Target: burger.brianpatrickhummel.com.herokudns.com

Configure esto como el nombre de dominio de origen al crear la distribución CloudFront.

En la configuración de Comportamiento de la caché, incluya el Hostencabezado en la lista blanca para que Heroku sepa para qué sitio es la solicitud.

2
  • Gracias por la info! Creé una distribución de Cloudfront con el destino DNS de Heroku como el nombre de dominio de origen (y agregué el nombre de dominio de la aplicación Heroku como un CNAME) y luego creé un conjunto de registros de Route 53 con el nombre que coincidía con el CNAME de Cloudfront, tipo: A, alias: Sí, y luego seleccioné Cloudfront Distribution como el Alias ​​Target ... ¡¡funcionó perfectamente !! Vi a algunas personas mencionar la configuración del tipo de conjunto de registros de Route 53 como CNAME. Elegí el Tipo A y parece funcionar, cuando intenté usar CNAME, no había opciones seleccionables en el menú desplegable Alias ​​Target. Brian Patrick Hummel 9 de septiembre de 2017 a las 0:31
  • Excelente. Un Aregistro con Alias ​​establecido en Sí es la elección correcta. Puede usar un CNAME si tiene el Alias ​​configurado en No, escribiendo el nombre de host del punto final de CloudFront en el cuadro, pero no lo desea . ALos registros con Alias ​​= Sí son aproximadamente dos veces más rápidos de buscar y no hay cargo por consultas a un Alias ​​de registro A que apunta a un servicio de AWS como CloudFront, S3 o ELB, pero las consultas CNAME no son gratuitas. De hecho, tendrá una línea de pedido de $ 0.00 en su factura para esto, y no es un "nivel" gratuito; estos son siempre gratuitos. Michael - sqlbot 9 de septiembre de 2017 a las 1:02
1

Estos son los pasos que haría,

Como ya está en la Ruta 53,

Get a free SSL from ACM

Confirme su verificación SSL a la dirección de correo electrónico del dominio. Asegúrese de que se vea verde como se muestra a continuación,

Confirmación de ACM

Assign it to CloudFront Endpoint with the SSL and CNAME as well

También verá que se creará automáticamente un cname en Route53 para este punto final SSL.

Si hace ping a burger.brianpatrickhummel.com, debería responder desde el frente cerrado.

SSL en la nube

Ahora configure Origins en Cloudfront para que apunte a su punto final con todas las configuraciones de caché necesarias. Si no necesita configuraciones de caché, puede establecerlas todas en 0, por lo que Cloudfront no almacenará en caché ningún dato.

En su patrón de Cloudront, asegúrese de tener * al final para que coincida con todo el patrón de URL para reenviarlo a su punto final.

Si su punto final necesita estar protegido, puede pasar encabezados adicionales desde Cloudfront y asegurarse de que la solicitud se ordene desde Cloudfront, en lugar de cualquier punto final público.

0

I'm uncertain as to of where I make certain DNS/CNAME changes, in Cloudfront, Route 53 or both

Bueno, dado que Route53 es el servicio DNS (no CloudFront), entonces estaría creando el registro CNAME en Route53. Quiere crear un registro CNAME en Route53 que apunte su subdominio a CloudFront. Luego, debe configurar CloudFront para saber que debe servir ese dominio configurando el campo Nombre de dominio alternativo.

0
0

Parece Hostque se ya no confiable y aceptado por heroku . Ya no se vinculará correctamente al sitio.

Úselo en su Origin Custom Headerlugar.

El nombre del encabezado personalizado pasará por algunos cambios de análisis y de mayúsculas y minúsculas, así que para depurarlo, agregue este comando para imprimir los encabezados relevantes proporcionados en la solicitud.

puts request.headers.env.reject { |key| key.to_s.include?('.') }

Debería ver sus encabezados allí, pero probablemente en un formato diferente.

Como referencia, mi encabezado era X-Request-ID(esto es recomendado por Heroku para sus usos adicionales), y se convirtió a HTTP_X_REQUEST_ID.