以最less的停机时间生产部署到EC2

这看起来像一个很好的总体方法。 您可以削减第2步，从而降低启动时间，创build一个自定义AMI，其中包括您需要的所有软件层; 话虽如此，我仍然会在启动时更新所有的软件包，以确保您获得所有最新的安全更新。

您可能还想考虑使用EBS支持的实例 – 这样，您可以在EBS上安装启动卷，软件堆栈和应用程序，这样可以省略上述几个步骤。

好的，刚才有人问我这个问题，但是我还是会用我的2分钱报出来。 我想你错过了云计算的好处 。

首先，您应该将您的应用程序代码和您的持久数据分隔在2个不同的虚拟机上。 这会在虚拟机之间的通信延迟中花费一点，但是应该让你的pipe理更简单。 请记住，拥有2个小型虚拟机而不是1个大型虚拟机并不昂贵; 所以请select最符合您需求的主机数量。

如果可能的话，你希望你的应用程序服务器是“无状态的”，因为它们不应该有持久的数据，你应该能够用最less的手工工作产生一个新的实例。

其次，你应该考虑一下像SimpleDB或Relational Database Service（托pipeMySQL）这样的亚马逊托pipe服务是否适合您的持久性数据存储。

理想的stream程看起来像这样：

1. 首先更改“最后面”的后端系统。 例如，如果您的更改需要向数据库表中添加一列，请使用正常的MySQL工具在正在运行的RDS实例上添加该列。 （这假设您的架构允许您的数据存储在保持向后兼容性的同时更改，或者您首先更新您的应用服务器代码，以便向前兼容。）
2. 启动一个新的应用程序服务器实例 ，使用预先准备的定制即用型AMI。
3. 在新的应用程序服务器上安装更新后的代码 ，即使用新列的新代码，并具有新function。
4. testing 。
5. 带来一些或所有的stream量，即通过IP地址/ Elastic Load Balancing切换到新的应用服务器。 （在一个理想的世界里，你只需要移动一小部分，比如5％的stream量，然后观察是否有问题。AFAIK Elastic Load Balancing不支持加权粘性路由，所以你可能不应该这样做。逐步切换也可以通过在您的代码中有2个执行path来实现，但这样做非常耗时，烦人 – 加权粘性负载均衡更简单。
6. 让旧的应用程序服务器实例保持几天 ，以防新代码有回退，并需要回滚。