![自动扩展 EC2 服务器并更新代码](https://linux22.com/image/600482/%E8%87%AA%E5%8A%A8%E6%89%A9%E5%B1%95%20EC2%20%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%B9%B6%E6%9B%B4%E6%96%B0%E4%BB%A3%E7%A0%81.png)
我们已经到了需要为我们的 Web 服务器设置自动缩放功能的阶段,但我不确定如何进行缩放服务器和更新现有代码的过程,而无需重新制作新的 AMI 并更改自动缩放配置以使用它。
我读过一些关于人们捆绑新代码并将其上传到 s3 并让新服务器在启动时抓取捆绑包的文章,但这似乎也不那么令人愉快。
目前,Web 应用程序的文件位于 git repo 中,当我们更新代码时,我们将其推送到 github,通过 ssh 进入 Web 应用程序并运行钩子来获取最新代码。
因此,我认为另一个选择可能是在每小时或每日的 cron 任务中运行该钩子。不幸的是,这并不涵盖所有类型的更新(例如,新博客文章的图片等未包含在 git repo 中),但总归是有用的。
有人能提供一些建议,说明什么是常见的解决方案,或者为什么我提出的解决方案是个坏主意吗?
谢谢大家
答案1
我热衷于为主要版本和系统更改创建新的 AMI,但对于次要版本,我也喜欢将盒子配置为git pull
在启动时仅更新代码库。我们定期发布小的代码更改,因此创建新 AMI 的负担是不值得的。
机器启动并运行后,我认为最好使用像 capistrano 这样的工具进行推送式部署。我不喜欢看到新代码通过 cron 作业自动启动到服务器,因为处理异常要困难得多。不可避免地,有人会将代码推送到他们需要恢复的存储库中,与此同时,cronjobs 可能会触发并启动错误的代码。
主要问题是,当在自动扩展上下文中启动新实例时,它可以在无人值守的情况下使用最新的代码库进行更新。
答案2
亚马逊的建议是,自动扩展 AMI 必须能够在启动时完全配置自身。因此,对于一个好的云应用程序,您应该让您的 AMI 向某个中央配置存储(S3?)报告自身并获取代码/配置。然后可以使用中央配置获取有关正在运行的实例的信息,以推送新版本的软件等。静态内容也应放置在 S3 中,这样它就不会依赖于代码/正在运行的实例。