我用的是AWS弹性豆柄。在那里,我选择了一个流量分割部署策略,使用100%拆分(这样,100%的新实例将拥有新版本并进行健康评估)。
下面(根据他们的文档)应该如何工作:
在分流量部署期间,ElasticBean秸秆在一个单独的临时自动缩放组中创建一组新的实例。然后,弹性豆杆指示负载均衡器将一定百分比的环境传入流量引导到新实例。然后,在配置的时间内,ElasticBean秸秆跟踪新实例集的运行情况。如果一切顺利,ElasticBean秸秆将剩余的流量转移到新实例,并将其附加到环境的原始自动缩放组中,替换旧的实例。然后弹性豆柄清理-终止旧的实例,并删除临时自动缩放组。
更具体而言:
将部署回上一个应用程序版本是快速的,不影响客户端通信量的服务。如果新实例未通过健康检查,或者您选择中止部署,则ElasticBean秸秆将流量移回旧实例并终止新实例。
但是,它只查看我的内部/health健康检查,而不查看它已经拥有信息的环境的总体健康状态,这似乎很愚蠢。
我尝试了以下场景:
请参阅以下两个日志转储屏幕截图(它们是最老的-第一)。
在流量分割期间,我是否可以让AWS尊重它已经执行的基于HTTP状态的健康检查?还是我一定要完全依靠定制的健康检查?
更新1:更奇怪的是,我尝试让我自己的健康检查总是失败,但它仍然决定使用失败的健康检查部署新版本!
更新2:我注意到它在评估健康时创建的临时自动缩放组只具有"EC2“类型的健康检查,而不是"ELB”。我认为这可能是根本原因。如果我能让它用"ELB“代替。


发布于 2021-03-28 01:25:05
太有意思了!我不知道是否可以将健康检查类型设置为"ELB“,因为我们使用的是CodeDeploy,它比AWSElasticBean秸秆具有更好的回滚功能。
但是,docs 1中有一种文档很好的方法来应用您要寻找的设置:
...默认情况下,为您的环境创建的自动缩放组使用亚马逊EC2状态检查。如果您的环境中的一个实例失败了亚马逊的EC2状态检查,自动缩放就会把它取下来并替换它。
Amazon状态检查只涵盖实例的健康状况,而不包括运行在实例上的应用程序、服务器或任何Docker容器的健康状况。如果应用程序崩溃,但运行的实例仍然正常,则可能会将其从负载均衡器中踢出,但是自动缩放不会自动替换它。..。
如果希望自动缩放替换应用程序已停止响应的实例,则可以使用配置文件配置自动缩放组以使用弹性负载平衡健康检查。下面的示例将组设置为使用负载平衡器的健康检查,以及Amazon状态检查,以确定实例的健康状况。示例.eb扩展名/autoscaling.config
资源: AWSEBAutoScalingGroup: Type:"AWS::AutoScaling::AutoScalingGroup“属性: HealthCheckType: ELB HealthCheckGracePeriod: 300
不过,它没有提到新的分流量部署功能。因此,我不能确定这是实际的解决方案,但至少你可以尝试一下。
发布于 2021-04-15 15:56:29
很久以前,我认为ElasticBean秸秆中的不可变部署选项是一种灵丹妙药--但只有当部署不涉及对应用程序的数据库模式的更改时,它才能工作。
我们现在求助于蓝绿色的部署。但是,只有当您控制DNS时,这才有效。如果您是SaaS解决方案,并且允许客户创建CNAME,那么B/G通常是企业的一大失败:( a)设置一个非常高的TTL,和/或( b)他们的内部DNS或防火墙缓存ALB的底层IP地址(这些地址是动态的,当然,在交换蓝色和绿色环境的URL时被替换)。
https://stackoverflow.com/questions/66687957
复制相似问题