我们已经到了需要为我们的Web服务器设置自动缩放的点，我不确定如何去扩展服务器和更新现有代码，而不重新创buildAMI并将自动缩放configuration更改为使用它。
我已经读了一些关于人们捆绑新代码并将其上传到s3并让新服务器在启动时抓取捆绑包的方法，但这似乎并不令人愉快。
目前，该应用程序的文件生活在一个git仓库中，当我们更新代码时，我们把它推到github上，ssh进入web应用程序并运行一个钩子来取消最新的代码。
所以我在想，另一个select可能是在每小时或每天的cron任务上运行该钩子。 不幸的是，这并不包括所有types的更新（例如新的博客文章的图像，而不包括在git仓库中），但这是一些东西。
任何人都可以提供一些常见解决scheme的build议，或者为什么我提出的解决scheme是一个坏主意？
谢谢大家
我是为主要版本和系统更改创build新的AMI的粉丝，但是对于次要版本，我也喜欢在启动时configuration一个用于更新git pull框，以更新代码库。 我们定期发布小代码更改，所以创build新AMI的负担是不值得的。
机器启动后，我认为最好使用像capistrano这样的工具来进行推式部署。 我不想看到新的代码自动启动到cron作业的服务器，因为处理exception要困难得多。 不可避免地，有人会将代码推入他们需要恢复的代码库中，同时cronjobs可能触发并启动错误的代码。
主要的问题是当一个新实例在自动扩展上下文中出现时，它可以用最新的代码库无人值守地自我更新。
亚马逊的build议是，自动扩展AMI必须能够在启动时完全自行configuration。 因此，对于一个好的云应用程序，您应该让您的AMI向中央configuration存储（S3？）报告自己，并获取代码/configuration。 然后可以使用中央configuration获取有关运行实例的信息，以推送新版本的软件等。静态内容也应该放置到S3，以便它不依赖于代码/正在运行的实例。