18

我在 AWS 中使用 Auto Scaling 在负载均衡器后面运行多个实例。

现在，如果我必须将一些代码更改推送到这些实例以及由于自动扩展策略而可能启动的任何新实例，那么最好的方法是什么？

我知道的唯一方法是，使用最新代码创建一个新的 AMI，修改 Auto Scaling 策略以使用这个新的 AMI，然后终止现有实例。但这可能涉及更长的停机时间，我不确定整个过程是否可以自动化。

任何指向这个方向的指针都将受到高度赞赏。

4

3 回答 3

4

我进行代码更改的方式是拥有一个我在代码上编辑的主服务器。所有扩展的从属服务器然后通过 ssh 通过 cron 作业进行 rsync 以使所有文件保持最新。所有服务器每 30 分钟同步一次 +- 随机几秒，以防止在完全相同的秒内访问它。（请注意，我将主服务器从负载均衡器中移除，因此用户总是收到相同的代码发送给他们。同样，当我决定发布我的代码更改时，我会从我的测试服务器到我的主服务器进行 rsync。

使用这种方法，您只需将同步命令放在启动中，您不必担心从映像上的代码状态，因为它会在启动后保持最新状态。

编辑：我们现在已经停止使用这种方法，并开始使用新服务 AWS CodeDeploy，它是为此目的而制作的：

http://aws.amazon.com/codedeploy/

希望这可以帮助。

于 2011-11-10T07:30:19.517 回答
1

我们将启动配置配置为使用“干净”的现成 AMI - 我们使用这些：http ://aws.amazon.com/amazon-linux-ami/

这些 AMI 的功能之一是 CloudInit - https://help.ubuntu.com/community/CloudInit

此功能使我们能够向新生成的普通 EC2 实例提供一些数据。具体来说，我们给实例一个脚本来运行。
该脚本（简而言之）执行以下操作：

  1. 自行升级（以确保应用所有安全补丁和错误修复）。
  2. 安装 Git 和 Puppet。
  3. 从 Github 克隆一个 Git 存储库。
  4. 应用 puppet 脚本（它是 repo 的一部分）来配置自身。Puppet 安装其余所需的软件模块。

它确实比从预配置的 AMI 启动需要更长的时间，但我们每次更新软件（每周几次）时都会跳过实际制作这些 AMI 的过程，并且服务器总是“干净”的 - 没有手动补丁，所有软件模块都是最新的等。

现在，要升级软件，我们使用本地 boto 脚本。该脚本将运行旧代码的服务器一一杀死。Auto Scaling 机制启动新的（和升级的）服务器。

请务必使用as-terminate-instance-in-auto-scaling-group，因为使用ec2-terminate-instance会导致 ELB 继续向正在关闭的实例发送流量，直到它未通过健康检查。

有趣的相关博文：http: //blog.codento.com/2012/02/hello-ec2-part-1-bootstrapping-instances-with-cloud-init-git-and-puppet/

于 2012-05-31T11:58:26.617 回答
-2

看来您可以手动将 Auto Scaling 组大小加倍，它将使用当前启动配置中的 AMI 创建 EC2 实例。现在，如果您将 Auto Scaling 组减小到以前的大小，旧实例将被终止，并且只有从新 AMI 创建的实例才能存活。

于 2015-03-02T13:31:54.513 回答