当您的实例落后于ELB时,如何为AWS建立维护页面？

Question

当您想在ELB后面部署新版本的应用程序时,如何在AWS中建立维护页面？我们希望在新的自动缩放实例出现时将ELB路由流量提供给维护实例,并且只有在它们完全启动时才"翻转"到新实例.我们使用自动缩放功能将现有实例降低,并使用具有新代码的新实例.

我们试图避免的情况是让ELB同时为新的EC2实例提供流量,同时提供维护页面.由于我们没有启用粘性会话,因此我们希望防止用户在维护模式页面和部署在EC2实例中的应用程序之间来回切换.我们也不能只扩展(例如从2到4个实例然后再回到2)来引入新实例,因为代码更改可能涉及数据库更改,这将破坏旧代码的更改.

Answer 1

AWS上最简单的方法是使用Route 53,即他们的DNS服务.

您可以使用加权循环的功能.

"您可以使用WRR将服务器投入生产,执行A/B测试,或平衡不同大小的区域或数据中心的流量."

有关此功能的AWS文档中的更多信息

编辑:Route 53最近添加了一项新功能,允许DNS故障转移到S3.查看他们的文档以获取更多详细信息:http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html

Answer 2

我意识到这是一个古老的问题，但是在今天（2018年12月）面对同样的问题之后，似乎还有另一种方法可以解决这个问题。

今年早些时候，AWS引入了对重定向和对Application Load Balancer的固定响应的支持。简而言之：

• 在控制台中找到您的ELB。
• 查看适当的侦听器的规则。
• 为您的应用程序的主机名添加固定的503响应规则。
• （可选）提供text/plain或text/html响应（即维护页面HTML）。
• 保存更改。

一旦规则传播到ELB（对我来说大约30秒），当您尝试在浏览器中访问主机时，系统将显示503维护页面。

部署完成后，只需删除添加的规则。

Answer 3

Route53不是解决此问题的好方法.在维护页面显示之前,DNS条目需要花费大量时间才能到期(然后在维护完成后更新之前需要相同的时间).我知道在提出这个问题的时候Lambda和CodeDeploy触发器不存在,但是我想让其他人知道Lambda可以用来为这个创建一个相对干净的解决方案,我在博客文章中有详细说明: http: //blog.ajhodges.com/2016/04/aws-lambda-setting-temporary.html

解决方案的要点是将Lambda函数订阅到CodeDeploy事件,这将在部署期间用负载均衡器中的静态页面替换您的ASG.

Answer 4

想出了另一个对我们有用的解决方案.以下是步骤:

1. 复制您的EB环境以创建另一个app-environment-maintenance,例如,调用它.
2. 更改自动缩放的配置,并将min和max服务器都设置为零.这不会花费您任何EC2服务器,并且环境将变为灰色并位于您的列表中.
3. 这是一项要求,但我们使用Cloudfront,因为许多人都会使用HTTPS等.Cloudfront有错误页面.
4. 使用您的错误页面创建一个新的S3网站托管存储桶.考虑为响应代码创建单独的文件,503等.有关目录要求和路由,请参阅#6.
5. 将S3存储桶添加到Cloudfront分发中.
6. 为您的Cloudfront分发添加新行为以获取类似的路由app-prod.
7. 在Cloudfront中设置错误页面以处理503响应代码并将其指向S3存储桶路由,例如 /error/*

8. 最后,您可以使用AWS CLI交换环境CNAME,使您的主环境进入维护模式.例如:

   /error/503-error.html

这会将您的app-environment-maintenance环境转换为维护模式.它会导致ELB抛出503,因为没有任何正在运行的EC2实例,然后Cloudfront将捕获503并返回各自的503错误页面.

就是这样.我知道有很多步骤,我尝试了很多建议的选项,包括Route53等.但所有这些都与它们如何使用ELB和Cloudfront等有关.

请注意,在交换环境的主机名后,传播大约需要一分钟左右.