我在 EC2 的一个大型实例上部署了一个简单的 Web 应用程序。我现在想将最新的代码部署到此服务器,但我希望以一种最大程度地减少停机时间并尽可能让最终用户顺畅的方式来执行此操作。这是我的计划:
- 启动另一个大型实例
- 在该实例上安装所有软件层
- 恢复并将 EBS 驱动器附加到实例
- 在新实例上部署我们最新的生产就绪代码
- 运行所有测试(包括应用程序的手动测试)
- (如果测试通过)在实时网站上放置“网站正在维护”通知。
- 在实时站点上备份 EBS 实例
- 从新服务器分离 EBS 实例并替换为最新备份
- 使用 ec2-associate-address 将 IP 地址移动到新实例
- 坐下来等待流量开始流经新实例
- 终止旧实例
这看起来是个好策略吗?有没有教程或书籍可能涵盖这个主题?我已经读过 George Reese 的《云应用程序架构》,这是一本很棒的书,但没有涵盖部署。此外,我知道有一些工具可以帮助解决这个问题,比如 RightScale 或 enStratus,当我开始使用多个实例时,我会使用这些工具。
答案1
这看起来是个不错的整体方法。您可以省去第 2 步,通过创建包含所有所需软件层的自定义 AMI 来缩短启动时间;话虽如此,我仍然会在启动时更新所有软件包,以确保您获得所有最新的安全更新。
您可能还想考虑使用EBS 支持的实例- 这样,您就可以在 EBS 上拥有启动卷、软件堆栈和应用程序,从而省去上述几个步骤。
答案2
好吧,这个问题是前段时间问的,不过我还是想说说我的看法。我认为你错过了好处云计算。
首先,您应该将应用程序代码和持久数据分离到 2 个不同的虚拟机上。这会稍微增加虚拟机间通信延迟,但应该会使您的管理更加简单。请记住,拥有 2 个小型虚拟机而不是 1 个大型虚拟机并不会更昂贵;因此请选择最符合您需求的主机数量。
如果可能的话,您希望您的应用程序服务器是“无状态的”,即它们不应该具有持久数据,并且您应该能够以最少的手动工作生成一个新实例。
其次,您应该考虑某些亚马逊托管服务(例如 SimpleDB 或关系数据库服务(托管 MySQL))是否适合您的持久数据存储。
理想的流程看起来是这样的:
- 首先更改“最靠后的”后端系统。例如,如果您的更改需要在数据库表中添加一列,则使用正在运行的 RDS 实例上的常规 MySQL 工具添加此列。(这假设您的架构允许您的数据存储在保持向后兼容性的同时进行更改,或者您首先更新应用服务器代码以使其向前兼容。)
- 启动新的应用服务器实例,使用您提前准备好的定制化即用型 AMI。
- 安装更新的代码在新的应用服务器上,即使用新列并具有新功能的新代码。
- 测试。
- 转移部分或全部流量,即转移 IP 地址/切换 Elastic Load Balancing到新的应用服务器。(在理想情况下,您首先只会转移一小部分流量,比如 5%,然后观察是否有任何问题。据我所知,Elastic Load Balancing 尚不支持加权粘性路由,因此您可能不应该这样做。也可以通过在代码中设置 2 个执行路径来实现逐步切换,但这很耗时且很烦人——加权粘性负载平衡更简单。)
- 将旧的应用服务器实例保留几天,以防新代码出现回归而您需要回滚。