在 Amazon ElasticBeanstalk 中使用 docker 或自定义 AMI

Question

我正在将应用程序迁移到 Amazon，而 ElasticBeanstalk 似乎是正确的工具。

此应用程序需要一些未安装在默认 AMI 中的软件包，我找到了两种方法来为我的应用程序生成完整环境：

• 自定义 AMI：只需将一些包添加到默认 AMI 并将其保存为我的自定义 AMI。

• Docker Container：使用支持 Docker 的 Amazon 镜像，提供 Dockerfile 并让 Amazon 构建和部署镜像。

我的问题是，推荐的选项是什么？

我担心与自动缩放相关的性能或部署时间（会有多个实例）

我想知道是否有人知道真正的优点和 const 或每个选项（理论上两个选项都是“相等的”）。 我也知道这两种方法（自定义 AMI 和 Docker），但从未在高负载环境中尝试过。

Answer 1

尝试不同的选项一段时间后，我有足够的信息来回答自己。

而不是使用自定义 AMI，我发现更好的是 Elastic Beanstalk，然后使用 ebextensions 自定义实例 使用 ebextensions，您可以完全自定义您的实例（包、文件……一切）。好处是您的实例将自动更新，并且您不会失去对实例的控制。缺点是你必须绑定亚马逊弹性豆茎。

我还注意到 docker 是一个不必要的额外层。对开发非常有用，但对生产来说有点头疼，因为您失去了对实例的控制。

我的选择（根据我的个人经验）是使用默认的 amazon ami，然后使用 ebextensions 自动自定义它们。

Answer 2

AWS documentation on creating custom AMIs for Elastic Beanstalk 包含有关如何正确创建自定义 AMI 的步骤。简介很好地讨论了 AMI 与配置文件的优缺点：

如果您需要安装标准 AMI 中未包含的大量软件，自定义 AMI 可以缩短在您的环境中启动实例时的配置时间。

使用配置文件非常适合快速一致地配置和自定义您的环境。但是，在环境创建和更新过程中，应用配置可能需要很长时间。如果您在配置文件中进行大量服务器配置，您可以通过制作一个已经具有您需要的软件和配置的自定义 AMI 来缩短此时间。

自定义 AMI 还允许您对难以实施或需要很长时间才能在配置文件中应用的低级组件（例如 Linux 内核）进行更改。要创建自定义 AMI，请在 Amazon EC2 中启动 Elastic Beanstalk 平台 AMI，根据您的需要自定义软件和配置，然后停止实例并从中保存 AMI。

这显然因用例而异，但听起来通常推荐的方法是使用配置，除非您需要对环境进行足够大的修改，以至于启动时间成为一个因素。还应该考虑他们的团队可能需要将配置文件与应用程序代码分开。