2

我的生产环境中有一个自动缩放的环境，当我们在其上更新构建时，这目前是一个严重的破坏，所以我们认为我们最好转移到 AWS 的开发 opsworks 以使这个过程对我们来说更容易。我们不能承受停机时间，现在不能，永远不能，永远不能；更新构建并可能重新启动 apache 的第二次损失会花费一大笔钱。

当基于 AMI 的新 ec2 机器出现新更新时，我们不可能让我们的机器被自动缩放策略终止，实际上，当自动缩放在任何情况下终止机器时，它都不关心您在该机器上运行的请求，它只是将它关闭，而它应该做的是优雅的关闭，通过 apache 上的 drainstop 之类的东西，所以它至少可以首先完成手头的工作。

现在 opsworks 来了，我们计划用它来更自动地更新我们的构建，新的更新推送是否会再次运行配方，事实上我刚刚读到的这一段更让我担心，是不是意味着它不会在新实例上自动更新构建。

修改应用程序设置后，您必须部署应用程序。首次部署应用程序时，部署配方会将代码和相关文件下载到应用程序服务器实例，然后运行本地副本。如果您在存储库中修改应用程序，则必须确保更新的代码和相关文件已安装在您的应用程序服务器实例上。AWS OpsWorks 在启动时自动将当前应用程序版本部署到新实例。但是，对于现有实例，情况有所不同：

您必须手动将更新的应用程序部署到在线实例。

您不必将更新的应用程序部署到离线实例存储支持的实例，包括基于负载和基于时间的实例；AWS OpsWorks 会在重新启动时自动部署最新的应用程序版本。

您必须重启离线 EBS 支持的 24/7 实例并手动部署应用程序；当这些实例重新启动时，AWS OpsWorks 不会在这些实例上运行 Deploy 配方。

您无法重新启动离线 EBS 支持的基于负载和基于时间的实例，因此最简单的方法是删除离线实例并添加新实例以替换它们。

因为它们现在是新实例，AWS OpsWorks 将在它们启动时自动部署当前应用程序版本。

4

1 回答 1

2

首先，让我声明一下，大约 2 周前我才开始研究 OpsWorks。所以我离专业人士还很远。但这是我的理解它是如何工作的：

我们需要区分实例存储支持的实例和 EBS 支持的实例：

  • 一旦关闭，实例存储就会与实例一起消失。因此，再次提起它，从零开始。它必须再次下载最新的应用程序并将其部署。
  • 对于 EBS 支持的实例，部署的代码保持完整（持久）超过它所附加到的实例的生命周期。因此，让 EBS 支持的实例恢复生机，不会自动更新您的应用程序。旧版本仍然部署。

所以你的第一个决定需要是使用什么实例类型。在所有实例上使用相同版本的应用程序通常是个好主意。因此，我建议使用 EBS 支持的实例，这些实例在启动时不会自动部署新版本。在这种情况下，部署新版本意味着启动全新的实例，这些实例将自动运行新代码（因为它们是新的），然后销毁旧实例。您将有很短的时间让新旧代码并行运行。

但是，如果您希望始终部署最新版本，并且可以承受在很长一段时间内单个实例之间存在差异的风险（例如，根据实例最初启动的时间部署不同的应用程序版本），那么支持实例存储可能成为您的选择。每次启动新实例时，都会部署最新最好的代码。如果要更新现有实例，只需启动新实例并终止现有实例即可。

这两种策略都应该为您提供零停机时间的预期效果。不同之处在于何时以及如何部署最新代码。将此与HAProxy结合使用可以更好地控制将使用哪些服务器。例如，您可以逐渐将流量从旧实例转移到新实例。

于 2013-11-28T17:34:01.913 回答