Amazon web services 通过替换EC2实例进行部署

我有一个ELB设置，间隔为12秒，健康/不健康阈值为2

目前，我的部署过程是：

1） 启动新服务器 2） 当它们健康时，用新的EC2更换ELB后面的现有EC2

它似乎在零停机时间下工作。但我找不到任何关于ELB在特定情况下具体如何运作的信息。有人知道这对于零停机时间部署是否合适吗

Thx

---

Henrik

如果服务器承载web应用程序，那么用户会话呢？

---

在我看来，更好的方法应该使用现有实例来部署，通过或等效工具，并用于存储会话和其他短期数据。

我认为您的方法很好。关键是确保新实例在删除旧实例之前响应请求。这种方法的好处是，如果需要，您可以非常轻松地回滚

有很多不同的方法来解决这个问题。我可能会考虑这与更新正在运行的实例之间的混合，但这取决于您的基础架构有多大、多复杂以及部署的频率

对于跨小车队的小规模升级，更新是可管理的，但您仍然需要弄清楚如何处理回滚。一旦超过几个服务器，这就变得更复杂了

---

如果您的团队足够大，并且您正在使用自动缩放，那么您可能可以更新您的规则，并开始删除旧实例&让新实例出现

每次部署都有新机器是个好主意。特别是，如果您是一家符合PCI标准的公司，并且每周都像这样更新您的计算机，那么它将消除大量的审核标准，从而显著简化您的基础架构。更简单的方法是为新部署创建一个新的自动缩放组。新机器在新的自动缩放组中启动。自动缩放组可以连接到您选择的ELB。然后确保您的健康检查是ELB在每个服务器上点击的端点。如果服务器准备好/能够响应请求，则该端点响应200。一旦准备就绪，它们将自动开始服务流量，您只需杀死由旧部署创建的自动缩放组，即可杀死计算机并将其从ELB中删除。有2个严重的问题需要考虑，它们都与无状态的机器有关：

机器的优雅终止：您需要确保服务web请求的进程在完成对任何已建立的客户端连接的响应后死亡，否则用户将看到50倍的错误代码；另外，如果您正在转发您的日志，比如syslog、splunk、sumologix，那么您还需要确保在终止实例之前转发这些日志

不具有粘性会话/会话关联。如果您正在本地将web应用程序的用户会话存储在这些服务器上，则可能存在粘性会话。这通常是一个坏主意，因为现在每台机器都有一个状态，负载可能不均衡。因此，为会话存储（如reddis/memcache）使用一个中央/共享位置，并禁用粘性会话

---

一旦实现了上述两种方法，您的部署方法将是最干净的

会话已在memcache中处理。因此，Web服务器是无状态的。我喜欢从构建工件启动新服务器的方法。一切都是脚本化的，所以自动缩放等是可能的。我理解。因此，从ELB中删除旧实例，并让CloudWatch通过一些自定义规则杀死该实例。这样，您就可以在旧实例完成时运行请求。我计划旧服务器在发现它们不是最新部署的版本，并且工作队列为空时，就会“自杀”。我的问题是，当您在控制台或API的一次调用中注销旧服务器池并注册新服务器池时，ELB将如何反应。谢谢。因为我问了这个问题，所以我已经设置了一个部署脚本，它完全按照您的建议执行（创建新的自动缩放组等）。当新部署通过负载平衡器回复OK时，我从ELB注销所有旧的指令，然后终止旧的自动缩放组。