Tag: 盐堆栈

结合salt，docker和Amazon EC2来托pipePython应用程序

我们目前在我们公司的情况是： 3个python应用程序可以根据需要多次生成 托pipe所有这些应用程序的单个Amazon EC2服务器（每个应用程序有1个实例） CPU利用率〜30％ 我们希望在1小时内完成的定期工作需要2小时（我们的应用程序的单个实例不能工作得更快 – 原因在这里不重要 – 但产生的第二个实例是诀窍） 我们希望使用docker，salt和Amazon EC2找出可自动扩展的解决scheme。 由于我没有pipe理员背景很难评估我们提出的哪些可能的解决scheme是好的，哪些是坏的。 所以我决定问你使用上述技术的经验，也许你将能够指出以下解决scheme的可能的问题： 我们有照顾单个ec2服务器的盐。 它正在安装所有应用程序依赖项，并使用最新的应用程序版本创buildAMI映像。 然后，我们正在使用Amazon自动扩展服务在需要时产生新的AMI。 优点： 这很简单 它很灵活 处理硬件故障相当好 缺点： 这不符合成本效益 我们没有使用所有资源 我们在EC2服务器实例上部署了固定数量的应用程序（由docker容器包装），例如，我们总是在服务器L4.medium上运行3x应用程序A. 当我们需要更多的应用程序实例时，亚马逊自动缩放会产生新的EC2服务器，而salt正在处理这个问题，我们将有3个Docker容器，在那里运行应用程序A. 优点： 我们可以使用任何我们想要的EC2服务器 我们可以使用特定服务器上的所有可用资源 缺点： 缩放的细微程度：如果四个应用程序A实例在1小时20分钟内完成工作，并且我们的目标是1小时，则会产生接下来的4个实例，然后在40分钟内完成工作（不必要的快）。 我们有任何我们想要的服务器和扩展意味着添加新的EC2实例或新的docker容器到现有的EC2实例。 换句话说，我们正在将新的Docker容器添加到现有机器，除非亚马逊自动缩放增加了新的ec2实例。 这在理论上是我们find的最好的解决scheme，但问题是我不知道是否可以用盐来实现。 优点： 灵活 成本效益 很酷:) 缺点： 最复杂的解决scheme 缩小问题（我们在3个服务器上有6个应用程序A实例，现在我们只需要2个，所以我们从2个服务器中删除了4个实例，但是可能会有不同的应用程序阻止我们停止ec2，因此我们再次使用了未使用的资源） 我甚至不知道从哪里开始 这就是我们所有:)任何build议将不胜感激。 任何不同于这三者的解决scheme都是非常受欢迎的（尤其是那些已经在生产中运行的）。