我将应用程序迁移到Amazon并且ElasticBeanstalk似乎是正确的工具。
此应用程序需要一些未安装在默认AMI中的软件包,我找到了两种方法来为我的应用程序生成完整的环境:
自定义AMI:只需将一些软件包添加到默认AMI并将其另存为我的自定义AMI。
Docker Container:使用支持Docker的Amazon映像,提供Dockerfile并让Amazon构建和部署映像。
我的问题是,建议的选项是什么?
我担心性能或部署与自动缩放相关的时间(会有多个实例)
我想知道是否有人知道真正的职业选手和常规或每个选项(理论上两个选项都是"等于")。 我也知道这两种方法(自定义AMI和Docker),但从未在高负载环境中尝试过。
答案 0 :(得分:1)
经过一段时间尝试不同的选择后,我有足够的信息来回答自己。
我找到的更好的是Elastic Beanstalk而不是使用自定义AMI,然后使用ebextensions自定义实例 使用ebextensions,您可以完全自定义您的实例(包,文件......所有内容)。好处是您的实例将自动更新,并且您不会失去对实例的控制。缺点是你必须使用亚马逊弹性豆茎。
我还注意到docker是一个不必要的额外层。对于开发非常有用,但由于失去了对实例的控制而对生产有点头疼。
我的选择(根据我的个人经验)使用默认的amazon ami然后使用ebextensions自动定制它们。
答案 1 :(得分:0)
See Plunker :介绍了如何正确创建自定义AMI。介绍很好地讨论了AMI与配置文件的优缺点:
如果您需要安装许多标准AMI中未包含的软件,自定义AMI可以在您的环境中启动实例时缩短配置时间。
使用配置文件非常适合快速一致地配置和自定义环境。但是,应用配置可能会在环境创建和更新期间花费很长时间。如果您在配置文件中进行大量服务器配置,则可以通过制作已具有所需软件和配置的自定义AMI来缩短此时间。
自定义AMI还允许您更改难以实现或需要很长时间才能应用于配置文件的低级组件(如Linux内核)。要创建自定义AMI,请在Amazon EC2中启动Elastic Beanstalk平台AMI,根据需要自定义软件和配置,然后停止实例并从中保存AMI。
它显然因用例而异,但听起来一般情况下推荐的方法是使用配置,除非您需要足够严格地修改环境以使旋转时间成为一个因素。还应该考虑他们的团队可能需要将配置文件与应用程序代码分开。