我正在将一个应用程序迁移到Amazon，而ElasticBeanstalk似乎是合适的工具。
这个应用程序需要一些没有安装在默认AMI中的包，我发现有两种方法可以为我的应用程序生成完整环境：
- 自定义AMI：只需向默认AMI添加一些包，并将其保存为我的自定义AMI。
- 码头集装箱：使用带有Docker支持的Amazon映像，提供Dockerfile并让Amazon构建和部署映像。
我的问题是，建议的选择是什么？
我担心与自动扩展相关的性能或部署时间（将有多个示例）
我想知道是否有人知道真实的的利弊或每一个选项（理论上两个选项都是“等于”）。我也知道这两种方法（自定义AMI和Docker），但从未在高负载环境中尝试过。
2条答案
按热度按时间fjaof16o1#
经过一段时间尝试不同的选择，我有足够的信息来回答自己。
我发现Elastic Beanstalk比使用自定义AMI更好，然后使用ebextensions自定义示例。使用ebextensions，你可以完全自定义你的示例（包、文件......所有内容）。好处是你的示例会自动更新，你不会失去对示例的控制。缺点是你绑定到amazon elastic Beanstalk。
我还注意到Docker是一个不必要的额外层。对开发非常有用，但对生产有点头痛，因为你失去了对示例的控制。
我的选择（基于我个人的经验）是使用默认的amazon ami，然后使用ebextensions自动定制它们。
omqzjyyz2#
AWS documentation on creating custom AMIs for Elastic Beanstalk有一些关于如何正确创建自定义AMI的步骤。介绍部分很好地讨论了AMI与配置文件的优缺点：
如果您需要安装标准AMI中没有包含的大量软件，那么自定义AMI可以在您的环境中启动示例时缩短供应时间。
使用配置文件非常适合快速一致地配置和自定义环境。但是，在环境创建和更新期间，应用配置可能会开始花费很长时间。如果在配置文件中执行大量服务器配置，则可以通过创建已具有所需软件和配置的自定义AMI来缩短此时间。
自定义AMI还允许您对底层组件（如Linux内核）进行更改，这些组件很难实现或需要很长时间才能在配置文件中应用。要创建自定义AMI，请在Amazon EC2中启动Elastic Beanstalk平台AMI，根据需要自定义软件和配置，然后停止示例并从中保存AMI。
这显然因用例而异，但听起来一般推荐的方法是使用配置，除非你需要对你的环境进行大量修改，以至于启动时间成为一个因素。你还应该考虑到他们的团队可能需要将配置文件与应用程序代码分开。