Implementaciones azules / verdes con CloudFront

Estoy buscando una manera de hacer implementaciones azules / verdes con CloudFront .

¿Alguien tiene una buena solución para pasar de una distribución de CloudFront a otra o todos realmente crean su distribución y nunca la vuelven a tocar?

La distribución de My CloudFront consta de un origen S3 para contenido estático (javascript, etc.) y un origen personalizado que apunta a un AWS ELB.

Sin cambios en CloudFront

En circunstancias normales, no realizamos ningún cambio en nuestra distribución de CloudFront. Versionamos nuestro contenido estático en el origen S3 cambiando el nombre de los archivos de contenido estático en S3 y realizamos implementaciones sucesivas en instancias EC2 bajo Elastic Load Balancer (ELB). Sin embargo, hay momentos en los que necesitamos probar y realizar cambios en la distribución de CloudFront en sí o tener cambios lo suficientemente significativos en nuestro entorno que necesitamos apuntar a un nuevo ELB en un nuevo entorno.

Dos distribuciones CloudFront

La primera opción que intenté fue tener dos Distribuciones Web CloudFront separadas , una para mi entorno actual o A y otra para mi entorno nuevo o B. Intenté usar una política de enrutamiento ponderado de Route53 donde agregué dos registros para mi registro de www.domain.com Route53, uno apuntando a CloudFront Distribution A con un peso de 1 y el otro apuntando a CloudFront Distribution B con un peso de 0. El el plan sería cambiar los pesos cuando quiero pasar de la distribución A a la distribución B. Sin embargo, solo una distribución de CloudFront a la vez puede tener registrados los Nombres de Dominio Alternos (CNAME) de www.dominio.com o aparece el siguiente error:

com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: ef84a5f0-44e7-11e5-9315-0ba167bb108a)

One CloudFront Distribution

La segunda opción es mantener una distribución web de CloudFront. Tengo S3 y orígenes personalizados que apuntan a mis entornos A y B y luego actualizo el comportamiento de caché de CloudFront para señalar el otro origen cuando quiero moverme de un entorno a otro. Esto es extremadamente complicado porque estas actualizaciones demoran entre 15 y 60 minutos, no hay visibilidad del progreso de la actualización y, dependiendo de la naturaleza de su cambio, es posible que deba continuar con una invalidación de CloudFront para que no esté sirviendo contenido en caché del antiguo entorno junto con nuevos contenidos.

¡Gracias por su consejo!

Dos distribuciones frente a la nube

Dado que AWS permite la superposición entre comodines alternativos CNAME en la misma cuenta de AWS, puede cambiar entre dos distribuciones en la nube de la siguiente manera:

• Utilice www.dominio.com como CNAME alternativo para la distribución de productos 1
• Use * .domain.com como CNAME alternativo para la distribución de productos 2
• Apunte su DNS de CNAME www.dominio.com a la distribución 1 o distribución 2. (* .cloudfront.net).
• Elimine el CNAME alternativo de la distribución desde la que ya no desea publicar el contenido.

Sin embargo, los dos DNS de distribución diferentes (* .cloudfront.net) pueden apuntar a los mismos nodos perimetrales, lo que significa que la forma en que se sirve su contenido es haciendo coincidir el CNAME de cloudfront.net con los nodos perimetrales que lo sirven y luego haciendo coincidir por nombre de host En este caso, si ambas distribuciones están utilizando los mismos nodos de borde (se puede verificar, por ejemplo, con dig) el corte no será limpio.

por ejemplo, si ambas distribuciones comparten uno o más nodos de borde, la distribución 1 con Alt CNAME www.domain.com tendrá prioridad sobre la distribución 2 con el más genérico * .domain.com hasta que el CNAME se elimine de la configuración de distribución 1 en todos los nodos de borde . Por lo tanto, la versión recuperada de una solicitud puede ser diferente de la otra durante el período de transición.

Un poco tarde en el juego aquí, pero para cualquiera que esté buscando esto. Creo que esto se puede hacer usando lambda @ edge. Similar a las pruebas A / B. https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html . Puede implementar una función lambda activada cuando un usuario solicita una url. Elija servir el contenido azul / verde de diferentes orígenes o prefijo de URL. Un valor de cookie determinará qué implementación se servirá. Cuando llegue la primera solicitud (sin cookie), configure la cookie al azar y diga 95% azul 5% verde.

Disparando desde la cadera, ¿cuánto tiempo lleva cambiar el origen dentro de una distribución frontal de nubes? 1) implemente un nuevo código detrás de ELB, caliéntelo 2) agregue este ELB como un nuevo origen a su distribución frontal de la nube mientras elimina el origen anterior 3) una vez que se corte, elimine el código viejo detrás de un ELB antiguo.

Para alejarse de los retrasos asociados con las actualizaciones de CloudFront o las actualizaciones de DNS, puede intercambiar el grupo de escalado automático detrás de su ELB. 1) despliegue el nuevo código en el nuevo ASG, caliéntelo 2) registre su ELB existente con este nuevo ASG 3) anule el registro del antiguo ASG de su ELB 4) una vez que se corte, elimine el viejo ASG.

También he estado investigando este tema y tengo una solución alternativa (ver más abajo).

Antecedentes:

CloudFront requiere que el CNAME en la configuración de distribución sea único en toda su cuenta. Por lo tanto, el control de azul / verde a través de DNS a diferentes distribuciones no funcionará. Hay un truco que usaría comodines, pero eso no garantiza que se sirvan los archivos correctos. Controlar azul / verde a través de DNS y CloudFront no es factible.

Además, cambiar cualquier configuración en CloudFront (incluido CNAME) genera 15-60 minutos de espera mientras los cambios se propagan a los servidores perimetrales. Además, no es una configuración ideal.

Solución alterna:

Para la aplicación de una sola página, esta configuración puede ser útil:

• URL de la aplicación: app.mydomain.com/app
• Estructura S3:
  • aplicación / (su sitio en vivo)
  • app2 / (tu sitio no es tan vivo)

Ahora configure CloudFront para usar su bucket para servir los archivos. En este punto, todo se reduce a la configuración de caché. Dado que CloudFront tarda una eternidad, configure el encabezado CacheControl en nuestros objetos S3. Para index.html, usamos 5 minutos, todo lo demás, 1 día. Cuando llegue el momento de cambiar, intercambie los nombres de directorio S3. Dentro de 5 minutos, la aplicación estará activa para todos los efectos.

Para las aplicaciones que ya se están ejecutando, tenemos la versión de compilación integrada en el código y un archivo json de configuración de compilación en la raíz de la aplicación. Luego, la aplicación ocasionalmente solicitará el archivo json, verificará la versión, si está desactualizada, solicitará una actualización.

Limitaciones

No puede realizar pruebas de remojo muy bien. Supongo que es posible aumentar el TTL de index.html a unas pocas horas o días (dependiendo de su necesidad), eso ayudaría a garantizar que los clientes obtengan nuevas versiones a medida que caduque su caché local.

En esta publicación de blog, el autor implementa pruebas ab a través de Lambda @ Edge trabajando fuera del código en la documentación de AWS (puede ver sus ejemplos aquí: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- ejemplos.html ).

Básicamente, lo que haces es crear una única distribución de Cloudfront que apunta a dos orígenes diferentes. Luego puede usar Lambda @ Edge para dirigir el tráfico a cualquiera de los orígenes (a través de Cookies) y, por supuesto, puede implementar otras cosas a través de Lambda, como ponderar el tráfico o voltearlo, etc. También es fácil agregar más orígenes y lógica .