使用 Auto Scaling 管理 Amazon EC2 中应用程序代码更改的最佳方式
我有多个实例在 AWS 中使用 Auto Scaling 的负载均衡器后面运行。
现在，如果我必须将一些代码更改推送到这些实例以及由于自动扩展策略而可能启动的任何新实例，那么最好的方法是什么？
我知道的唯一方法是，使用最新代码创建一个新的 AMI，修改自动扩展策略以使用这个新的 AMI，然后终止现有实例。但这可能会涉及更长的停机时间，而且我不确定整个过程是否可以自动化。
任何朝这个方向的指示都将受到高度赞赏。
I have multiple instances running behind Load balancer with Auto Scaling in AWS.
Now, if I have to push some code changes to these instances and any new instances that might launch because of auto scaling policy, what's the best way to do this?
The only way I am aware of is, to create a new AMI with latest code, modify the auto scaling policy to use this new AMI and then terminate the existing instances. But this might involve a longer downtime and I am not sure whether the whole process can be automated.
Any pointers in this direction will be highly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我更改代码的方法是拥有一个主服务器，我可以在该服务器上编辑代码。所有可扩展的从属服务器然后通过 cron 作业通过 ssh 进行 rsync，以使所有文件保持最新。所有服务器每 30 分钟 +- 几秒随机同步一次，以防止在同一秒访问它。 （请注意，我将主服务器保留在负载均衡器之外，因此用户始终会向他们发送相同的代码。同样，当我决定发布代码更改时，我会从测试服务器到主服务器进行 rsync。
使用这种方法，您只需将同步命令放入启动中，而不必担心从属映像上的代码状态，因为它在启动后将是最新的
：
我们现在已停止使用此方法，并开始使用专门为此目的而制作的新服务 AWS CodeDeploy：
http:// /aws.amazon.com/codedeploy/
希望这有帮助。
The way I do my code changes is to have a master server which I edit on the code on. All the slave servers which scale then rsync via ssh by a cron job to bring all the files up to date. All the servers sync every 30 minutes +- a few random seconds to keep from accessing it at the exact same second. (note I leave the Master off of the load balancer so users always have the same code being sent to them. Similarly, when I decide to publish my code changes, I do an rsync from my test server to my master server.
Using this approach, you merely have to put the sync command in the start-up and you don't have to worry about what the code state was on the slave image as it will be up to date after it boots.
EDIT:
We have stopped using this method now and started using the new service AWS CodeDeploy which is made for this exact purpose:
http://aws.amazon.com/codedeploy/
Hope this helps.
我们将启动配置配置为使用“干净”的现成 AMI - 我们使用这些： http://aws.amazon.com/amazon-linux-ami/
这些 AMI 的功能之一是 CloudInit - https://help.ubuntu.com/community/CloudInit
此功能使我们能够向新生成的普通 EC2 实例传递一些数据。具体来说，我们为实例提供一个要运行的脚本。
该脚本（简而言之）执行以下操作：
它确实比从预配置的 AMI 启动需要更长的时间，但每次更新软件（每周几次）时，我们都会跳过实际制作这些 AMI 的过程，并且服务器始终“干净” - 无需手动修补，所有软件模块都是最新的等。
现在，为了升级软件，我们使用本地 boto 脚本。
该脚本会一一杀死运行旧代码的服务器。 Auto Scaling 机制启动新的（和升级的）服务器。
确保使用
as-terminate-instance-in-auto-scaling-group因为使用ec2-terminate-instance将导致 ELB 继续向关闭发送流量-down 实例，直到健康检查失败。有趣的相关博客文章：http://blog.codento.com/2012/02/hello-ec2-part-1-bootstrapping-instances-with-cloud-init-git-and-puppet/
We configure our Launch Configuration to use a "clean" off-the-shelf AMI - we use these: http://aws.amazon.com/amazon-linux-ami/
One of the features of these AMIs is CloudInit - https://help.ubuntu.com/community/CloudInit
This feature enables us to deliver to the newly spawned plain vanilla EC2 instance some data. Specifically, we give the instance a script to run.
The script (in a nutshell) does the following:
It does take longer than booting from a pre-configured AMI, but we skip the process of actually making these AMIs every time we update the software (a couple of times a week) and the servers are always "clean" - no manual patches, all software modules are up to date etc.
Now, to upgrade the software, we use a local boto script.
The script kills the servers running the old code one by one. The Auto Scaling mechanism launches new (and upgraded) servers.
Make sure to use
as-terminate-instance-in-auto-scaling-groupbecause usingec2-terminate-instancewill cause the ELB to continue to send traffic to the shutting-down instance, until it fails the health check.Interesting related blog post: http://blog.codento.com/2012/02/hello-ec2-part-1-bootstrapping-instances-with-cloud-init-git-and-puppet/
看来您可以手动将自动缩放组大小加倍，它将使用当前启动配置中的 AMI 创建 EC2 实例。现在，如果您将 Auto Scaling 组减小回之前的大小，旧实例将被终止，只有从新 AMI 创建的实例才能存活。
It appears you can manually double auto scaling group size, it will create EC2 instances using AMI from current Launch Configuration. Now if you decrease auto scaling group back to the previous size, old instances will be killed and only instances created from a new AMI will survive.