当我的组中的自动扩展规则触发新 EC2 实例的部署时，或者例如我更改实例大小以模拟节点部署的行为，但在应用程序准备好之前它会被添加到负载均衡器中。
部署开始，.ebextensions 中的脚本开始执行。由于这是第一次部署到此节点，因此名为 current 的文件夹为空，因此访问此节点会在浏览器中显示 403 Forbidden 错误。
最终，应用程序部署完成，并且 ondeck 文件夹按预期移至当前文件夹，此时应用程序可以正常工作并且 403 错误消失。
这里的问题是，该节点在该过程完成之前被添加到负载均衡器，因此部分流量被分发到损坏的节点。
有什么办法可以阻止这种情况发生吗？我做错了什么吗？
答案1
一旦新 EC2 实例开始通过负载均衡器的健康检查，负载均衡器就会开始向该实例发送流量。我猜您的负载均衡器配置了 TCP ping 健康检查。这意味着，一旦新实例开始响应端口 80 上的 ping，它就被视为健康并准备好接收请求。不过，正如您所注意到的，这将在应用程序完全部署并实际提供良好响应之前发生。
解决方案是配置您的负载均衡器以使用 HTTP 请求执行健康检查，这样，在您的应用程序运行并成功响应 Web 请求之前，新的 EC2 实例不会被视为健康。在 AWS 控制台上，找到 EC2 仪表板的负载均衡器部分，然后选择您的 Elastic Beanstalk 环境的负载均衡器。您将在负载均衡器配置面板中看到一个“健康检查”选项卡，您可以在其中编辑健康检查设置并切换到 HTTP 请求作为您的 ping 方法。
如果您的应用程序配置为仅处理通过生产主机名发送的请求，您可能会发现 HTTP 运行状况检查总是失败。负载均衡器将请求发送到 EC2 实例的特定 URL，如果您的应用程序对这些请求的响应是错误或 30x 重定向，则负载均衡器将认为它不健康。在这种情况下，您需要在请求过滤中添加例外，以允许运行状况检查请求成功，无论主机名是什么。例如，将一个静态的空 elbhealthcheck.html（或您想要的任何名称）文件添加到您的应用程序，并允许使用任何主机名对该文件进行请求。然后将负载均衡器运行状况检查配置为在其 HTTP ping 中使用该 URL，您就可以开始了。