结合 salt、docker 和 Amazon EC2 来托管 Python 应用程序

Question

我们公司目前的情况是：

• 3 个可以根据需要多次生成的 Python 应用程序
• 单个 Amazon EC2 服务器托管所有提到的应用程序（每个 1 个实例）
• CPU 利用率 ~30%
• 我们希望在 1 小时内完成的定期工作需要 2 小时（我们应用的单个实例无法更快地运行 - 原因在这里并不重要 - 但生成第二个实例就可以了）

我们想找出使用​​ docker、salt 和 Amazon EC2 的自动可扩展解决方案。由于我没有管理员背景，因此很难评估我们提出的哪些可能的解决方案是好的，哪些是坏的。因此，我决定询问您在上述技术方面的经验，也许您可​​以指出以下解决方案可能存在的问题：

1. 我们有处理单个 ec2 服务器的 salt。它正在安装所有应用程序依赖项并使用最新的应用程序版本创建 AMI 映像。然后，我们使用 Amazon 自动扩展服务在需要时生成新的 AMI。
   • 优点：
     • 很简单
     • 很灵活
     • 很好地处理硬件故障
   • 缺点：
     • 不划算
     • 我们并未使用所有资源
2. 我们在 EC2 服务器实例上部署了固定数量的应用程序（由 docker 容器包装），例如我们总是在服务器 L4.medium 上运行 3x 应用程序 A。当我们需要更多应用程序实例时，Amazon 自动扩展正在生成新的 EC2 服务器，并且 salt 正在处理我们将有 3 个 docker 容器，其中运行应用程序 A。
   • 优点：
     • 我们可以使用任何我们想要的 EC2 服务器
     • 我们可以使用特定服务器上的所有可用资源
   • 缺点：
     • 扩展粒度：如果四个应用程序 A 实例在 1 小时 20 分钟内完成工作，而我们的目标是 1 小时，我们将生成接下来的 4 个实例，然后工作在 40 分钟内完成（这太快了）。
3. 我们有任何我们想要的服务器，扩展意味着将新的 ec2 实例或新的 docker 容器添加到现有的 ec2 实例。所以换句话说，我们正在向现有机器添加新的 docker 容器，除非亚马逊自动扩展添加新的 ec2 实例。从理论上讲，这是我们找到的最佳解决方案，但问题是我不知道是否可以用盐来实现。
   • 优点：
     • 灵活
     • 性价比高
     • 很酷:)
   • 缺点：
     • 最复杂的解决方案
     • 缩减问题（我们在 3 台服务器上有 6 个应用程序 A 实例，现在我们只需要 2 个，因此我们从 2 台服务器中删除 4 个实例，但可能有不同的应用程序阻止我们停止 ec2，因此我们有未使用的资源再次）
     • 我什至不知道从哪里开始

这就是我们所拥有的:) 任何建议将不胜感激。任何与这三个不同的解决方案都非常受欢迎（尤其是那些已经在生产环境中运行的解决方案）。

Answer 1

您是否有理由不考虑使用亚马逊容器服务（ecs，http://aws.amazon.com/ecs/）？我想这将涵盖你描述的码头场景，也许你甚至不需要盐（也许这只是我的无知，没有使用它）。您可以以任何您想要的方式将您的应用程序容器化，基于 ecs AMI 创建一个 docker 集群，并让亚马逊在您的 docker 集群中进行调度，或者您自己通过 API 在需要时添加新的集群节点来监控资源。来自 ecs 常见问题解答 (http://aws.amazon.com/ecs/faqs/)：

我是否可以安排容器启动和管理 跨集群放置？是的。您可以通过两种方式做到这一点。你可以 选择让 EC2 容器服务将您随机放置在一个 集群尝试使用 RunTask API，或者您可以使用 DescribeCluster API 获取信息 关于集群的完整状态。 API 返回所有数据 集群中的容器实例，它们正在运行的任务，以及 哪些资源仍然可用。有了这些信息，您可以使用 StartTask API 以针对您的特定容器实例 集群或使用自定义调度程序根据您的 要求。

我认为这样您可以首先充分利用所有可用的集群节点，然后触发创建新的集群节点，当您完成计算时可以将其删除。这应该解决方案 2 的粒度问题和方案 3 的缩减问题。就复杂性而言，它仍然相当高，至少与方案 1 相比，因为您需要对所有内容进行 docker 化并学习 ecs。