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