我的生产环境中有一个自动缩放的环境,当我们在其上更新构建时,这目前是一个严重的破坏,所以我们认为我们最好转移到 AWS 的开发 opsworks 以使这个过程对我们来说更容易。我们不能承受停机时间,现在不能,永远不能,永远不能;更新构建并可能重新启动 apache 的第二次损失会花费一大笔钱。
当基于 AMI 的新 ec2 机器出现新更新时,我们不可能让我们的机器被自动缩放策略终止,实际上,当自动缩放在任何情况下终止机器时,它都不关心您在该机器上运行的请求,它只是将它关闭,而它应该做的是优雅的关闭,通过 apache 上的 drainstop 之类的东西,所以它至少可以首先完成手头的工作。
现在 opsworks 来了,我们计划用它来更自动地更新我们的构建,新的更新推送是否会再次运行配方,事实上我刚刚读到的这一段更让我担心,是不是意味着它不会在新实例上自动更新构建。
修改应用程序设置后,您必须部署应用程序。首次部署应用程序时,部署配方会将代码和相关文件下载到应用程序服务器实例,然后运行本地副本。如果您在存储库中修改应用程序,则必须确保更新的代码和相关文件已安装在您的应用程序服务器实例上。AWS OpsWorks 在启动时自动将当前应用程序版本部署到新实例。但是,对于现有实例,情况有所不同:
您必须手动将更新的应用程序部署到在线实例。
您不必将更新的应用程序部署到离线实例存储支持的实例,包括基于负载和基于时间的实例;AWS OpsWorks 会在重新启动时自动部署最新的应用程序版本。
您必须重启离线 EBS 支持的 24/7 实例并手动部署应用程序;当这些实例重新启动时,AWS OpsWorks 不会在这些实例上运行 Deploy 配方。
您无法重新启动离线 EBS 支持的基于负载和基于时间的实例,因此最简单的方法是删除离线实例并添加新实例以替换它们。
因为它们现在是新实例,AWS OpsWorks 将在它们启动时自动部署当前应用程序版本。