Deployment dev opsworks-更新应用程序，是否会阻止apache

在我的生产环境中有一个自动缩放的环境，当我们在它的基础上更新构建时，它目前是一个巨大的破坏，所以我们认为最好转到AWS的dev opsworks，使这个过程对我们来说更容易。 我们承受不起停工，现在不行，永远不行，永远不行；在更新构建和重新启动apache时，第二次的损失可能会花费大量金钱

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

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

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

您必须手动将更新的应用程序部署到联机实例

您不必将更新后的应用部署到脱机实例 存储备份实例，包括基于负载和基于时间的实例； AWS OpsWorks在安装时自动部署最新的应用程序版本 重新启动

您必须重新启动离线EBS支持的全天候实例并手动部署 应用程序；AWS OpsWorks不会在这些服务器上运行部署配方 实例重新启动时

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

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

---

首先，让我声明，我在大约两周前开始研究OpsWorks。所以我远不是职业选手。但以下是我对其工作原理的理解：

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

• 一旦实例关闭，实例存储将与实例一起消失。因此，再次提起它，从零开始。它必须再次下载最新的应用程序并将其部署
• 对于EBS支持的实例，部署的代码在其所连接的实例的生存期内保持完整（持久化）。因此，恢复EBS支持的实例不会自动更新应用程序。旧版本仍在部署中

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

但是，如果您希望始终部署最新版本，并且能够承受在较长时间内各个实例之间出现差异的风险（例如，根据实例最初启动的时间部署不同的应用程序版本），则您可以选择支持实例存储。每次新实例启动时，都会部署最新、最优秀的代码。如果您想更新现有的实例，只需启动新实例并杀死现有实例即可

---

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

我的观点正好相反：只对数据库实例使用EBS。当您想要部署新版本的代码时，只需“循环舰队”（启动新实例并杀死旧实例）。如果您想要更多的控制，那么放弃ELB并使用nginx/HAProxy。