【发布时间】:2021-06-15 16:03:09
【问题描述】:
我正在使用 AWS Elastic Beanstalk。在那里,我选择了 100% 拆分的流量拆分部署策略(这样 100% 的新实例将拥有新版本并对其运行状况进行评估)。
这是应该如何工作的(根据他们的文档):
在流量拆分部署期间,Elastic Beanstalk 在单独的临时 Auto Scaling 组中创建一组新实例。然后,Elastic Beanstalk 指示负载均衡器将一定百分比的环境传入流量定向到新实例。然后,在配置的时间内,Elastic Beanstalk 会跟踪新实例集的运行状况。如果一切顺利,Elastic Beanstalk 会将剩余流量转移到新实例,并将它们附加到环境的原始 Auto Scaling 组,替换旧实例。然后 Elastic Beanstalk 进行清理 — 终止旧实例并删除临时 Auto Scaling 组。
更具体地说:
将部署回滚到以前的应用程序版本很快,并且不会影响客户端流量的服务。如果新实例未通过运行状况检查,或者您选择中止部署,Elastic Beanstalk 会将流量移回旧实例并终止新实例。
但是,它只查看我的内部/health 健康检查,而不是环境的整体健康状态,从 HTTP 状态代码来看,它已经有信息,这似乎很愚蠢.
我尝试了以下场景:
- 部署新版本。
- “健康评估期”开始后,立即向服务器发送错误 500s(来自我专门为此目的制作的端点)。
- AWS 然后将我的所有实例移入“降级”状态和“不健康”状态,但随后似乎忽略了它,并继续进行。
请参阅以下两个日志转储屏幕截图(它们是最旧的优先)。
有什么方法可以让 AWS 在流量拆分期间尊重它已经执行的基于 HTTP 状态的运行状况检查?还是我只能完全依赖定制开发的健康检查?
更新 1: 更奇怪的是,我尝试让自己的健康检查也总是失败,但它仍然决定部署带有失败健康检查的新版本!
更新 2: 我注意到它在评估运行状况时创建的临时 Auto Scaling 组只有“EC2”类型的运行状况检查,而不是“ELB”。我认为这可能是根本原因。如果我只能让它使用“ELB”。
【问题讨论】:
标签: amazon-web-services amazon-ec2 amazon-elastic-beanstalk traffic