当您想在ELB后面部署新版本的应用程序时,如何在AWS中建立维护页面?我们希望在新的自动缩放实例出现时将ELB路由流量提供给维护实例,并且只有在它们完全启动时才“翻转”到新实例。我们使用自动缩放功能将现有实例降低,并使用具有新代码的新实例。
我们试图避免的情况是让ELB同时为新的EC2实例提供流量,同时提供维护页面。由于我们没有启用粘性会话,因此我们希望防止用户在维护模式页面和部署在EC2实例中的应用程序之间来回切换。我们也不能只扩展(例如从2到4个实例然后再回到2)来引入新实例,因为代码更改可能涉及数据库更改,这将破坏旧代码的更改。
AWS上最简单的方法是使用他们的DNS服务Route 53。
您可以使用Weighted Round Robin的功能。
“您可以使用WRR将服务器投入生产,执行A / B测试,或平衡不同大小的区域或数据中心的流量。”
有关AWS documentations on this feature的更多信息
编辑:Route 53最近添加了一项新功能,允许DNS故障转移到S3。查看他们的文档以获取更多详细信息:http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html
Route53不是解决此问题的好方法。在维护页面显示之前,DNS条目需要花费大量时间才能到期(然后在维护完成后更新之前需要相同的时间)。我知道在提出这个问题的时候Lambda和CodeDeploy触发器不存在,但是我想让其他人知道Lambda可以用来创建一个相对干净的解决方案,我在博客文章中有详细说明:http://blog.ajhodges.com/2016/04/aws-lambda-setting-temporary.html
解决方案的要点是将Lambda函数订阅到CodeDeploy事件,这将在部署期间用负载平衡器中的静态页面替换您的ASG。
想出了另一个对我们有用的解决方案。以下是获取简单503 http响应所需的步骤:
app-environment-maintenance
。aws elasticbeanstalk swap-environment-cnames \
--profile "$awsProfile" \
--region "$awsRegion" \
--output text \
--source-environment-name app-prod \
--destination-environment-name app-prod-maintenance
这会将你的app-prod
环境换成维护模式。这将导致ELB抛出503,因为没有任何正在运行的EC2实例,然后Cloudfront可以捕获503并返回您的自定义503错误页面,如下所述。
使用Cloudfront的自定义错误页面的奖励配置:
我们使用Cloudfront,因为许多人都会使用HTTPS等.Cloudfront有错误页面。这是一项要求。
/error/*
等路由。/error/503-error.html
现在,当您的ELB抛出503时,将显示您的自定义错误页面。
就是这样。我知道有很多步骤来获取自定义错误页面,我尝试了很多建议的选项,包括Route53等。但所有这些都与它们如何使用ELB和Cloudfront等有关。
请注意,在交换环境的主机名后,传播大约需要一分钟左右。
我意识到这是一个古老的问题,但在今天(2018年12月)遇到同样的问题后,看起来还有另一种方法可以解决这个问题。
今年早些时候,AWS引入了对redirects and fixed responses to Application Load Balancers的支持。简而言之:
text/plain
或text/html
响应(即您的维护页面HTML)。一旦规则传播到ELB(对我来说需要大约30秒),当您尝试在浏览器中访问主机时,您将看到503维护页面。
部署完成后,只需删除您添加的规则即可。
我们的部署过程首先运行一个cloudformation来生成一个ec2微实例(维护实例),它将预定义的静态页面从s3复制到ec2上。 Cloudformation由elb提供,微型ec2实例连接到elb。然后运行脚本(powershell或cli)从elb离开维护实例中删除Web实例(ec2)。
这样我们就可以在部署过程中切换到维护实例。
在我们的例子中,我们有两个elb,一个用于外部,另一个用于内部。我们的内部elb将不会在此过程中更新,也就是我们如何进行post prod部署烟雾测试。测试完成后,我们运行另一个脚本将Web实例附加回elb并删除维护堆栈。
据我所见,我们处于上述答案不适用或不理想的情况。
我们有一个运行Puma的Rails应用程序,运行在64位Amazon Linux / 2.9.0上的Ruby 2.3,它似乎带有(经典)ELB。
所以ALB 503处理不是一个选择。
我们还有各种硬件客户端,我不相信它们始终尊重DNS TTL,因此Route53存在风险。
看起来效果很好的是nginx上的辅助端口,它随平台一起提供。
我把它添加为.ebextensions/maintenance.config
files:
"/etc/nginx/conf.d/maintenance.conf":
content: |
server {
listen 81;
server_name _ localhost;
root /var/app/current/public/maintenance;
}
container_commands:
restart_nginx:
command: service nginx restart
并将https://gist.github.com/pitch-gist/2999707的副本丢入public/maintenance/index.html
现在设置维护我只是将我的ELB监听器切换到指向端口81而不是默认的80.没有额外的实例,s3桶或等待客户端到新的DNS。
适用于beanstalk(可能主要是等待后端的cloudformation)大约需要15秒左右才能应用。