amazon web services - services - ¿Cómo colocas una página de mantenimiento para AWS cuando tus instancias están detrás de un ELB?

download key pair amazon ec2 (4)

¿Cómo coloca una página de mantenimiento en AWS cuando desea implementar nuevas versiones de su aplicación detrás de un ELB? Queremos tener el tráfico de rutas de ELB a la instancia de mantenimiento mientras surgen las nuevas instancias de escala automática, y solo "dar la vuelta" a las nuevas instancias una vez que estén completas. Usamos escalado automático para reducir las instancias existentes y nuevas instancias, que tienen el nuevo código.

El escenario que intentamos evitar es que el ELB sirva tanto el tráfico a las nuevas instancias de EC2 como también el servicio de la página de mantenimiento. Como no tenemos habilitadas las sesiones adhesivas, queremos evitar que el usuario se mueva hacia atrás y hacia adelante entre la página de modo de mantenimiento y la aplicación desplegada en una instancia de EC2. Tampoco podemos ampliar (por ejemplo, de 2 a 4 instancias y luego volver a 2) para presentar las nuevas instancias, ya que los cambios en el código pueden implicar cambios en la base de datos, que podrían ser cambios importantes para el código anterior.

La forma más simple en AWS es usar Route 53 , su servicio de DNS.

Puede usar la función de Weighted Round Robin .

"Puede usar WRR para llevar servidores a producción, realizar pruebas A / B o equilibrar su tráfico entre regiones o centros de datos de diferentes tamaños".

Más información en la documentación de AWS sobre esta característica

EDITAR: Route 53 agregó recientemente una nueva característica que permite la conmutación por error de DNS a S3. Verifique su documentación para más detalles: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html

Nuestro proceso de implementación primero ejecuta una nube de información para generar una microinstancia ec2 (instancia de mantenimiento) que copia una página estática predefinida de s3 a ec2. Cloudformation se suministra con elb al que se adjunta la instancia de micro ec2. A continuación, se ejecuta una secuencia de comandos (powershell o cli) para eliminar instancias web (ec2) de la salida de la instancia de Mantenimiento.

De esta manera cambiamos a la instancia de mantenimiento durante el proceso de implementación.

En nuestro caso, tenemos dos ELB, uno para externo y el otro interno. Nuestros indicadores internos no se actualizarán durante este proceso y es la forma en que se realiza la prueba de humo posterior a la implementación. Una vez que finaliza la prueba, ejecutamos otra secuencia de comandos para adjuntar las instancias web a las de Elb y eliminar la pila de Mantenimiento.

Route53 no es una buena solución para este problema. Las entradas de DNS tardan una cantidad significativa de tiempo antes de que aparezca la página de mantenimiento (y luego transcurre el mismo tiempo antes de que se actualicen después de completar el mantenimiento). Me doy cuenta de que los disparadores de Lambda y CodeDeploy no existían en el momento en que se hizo esta pregunta, pero quería que otros sepan que Lambda se puede usar para crear una solución relativamente limpia para esto, que he detallado en una publicación de blog: http://blog.ajhodges.com/2016/04/aws-lambda-setting-temporary.html

El objetivo de la solución es suscribir una función Lambda a los eventos CodeDeploy, que reemplaza su ASG con una microinstancia que sirve una página estática en su equilibrador de carga durante las implementaciones.

Salió con otra solución que funciona muy bien para nosotros. Estos son los pasos:

Replica tu entorno de EB para crear otro, llámalo algo así como app-environment-maintenance , por ejemplo.
Cambie la configuración para autoescalar y configure los servidores mínimo y máximo ambos en cero. Esto no le costará servidores EC2 y el entorno se volverá gris y se sentará en su lista.
Este es un requisito, pero usamos Cloudfront, como muchas personas lo harán para HTTPS, etc. Cloudfront tiene páginas de error.
Crea un nuevo espacio de alojamiento web S3 con tus páginas de error. Considere la posibilidad de crear archivos separados para los códigos de respuesta, 503, etc. Consulte # 6 para conocer los requisitos y las rutas del directorio.
Agregue el depósito S3 a su distribución de Cloudfront.
Agregue un nuevo comportamiento a su distribución de Cloudfront para una ruta como /error/* .
Configure las páginas de error en Cloudfront para manejar los códigos de respuesta 503 y apúntelo a la ruta del /error/503-error.html S3, como /error/503-error.html
Finalmente, puede usar AWS CLI para cambiar el entorno CNAME y llevar su entorno principal al modo de mantenimiento. Por ejemplo:
aws elasticbeanstalk swap-environment-cnames / --profile "$awsProfile" / --region "$awsRegion" / --output text / --source-environment-name api-prod / --destination-environment-name api-prod-maintenance

Esto cambiaría su entorno de app-prod en modo de mantenimiento. Haría que el ELB lanzara un 503 ya que no hay ninguna instancia de EC2 en ejecución y entonces Cloudfront capturará el 503 y devolverá su página de error 503 respectiva.

Y eso es. Sé que hay bastantes pasos y probé muchas de las opciones sugeridas, incluyendo Route53, etc. Pero todas estas tienen problemas con la forma en que funcionan con ELBs y Cloudfront, etc.

Tenga en cuenta que después de intercambiar los nombres de host para los entornos, se tarda aproximadamente un minuto en propagarse.