在AWS中使用Docker / Ansible与Ansible，Puppet和Foreman的不可变服务器模型吗？

我们遇到了一个有趣的争论，并且陷入了两个阵营。我对我们可能会缺少的想法或陷阱的任何特定问题感兴趣。确实，任何可以帮助我们做出决定或指出我们无法解释的事情的事物。我知道这会绕开“无意见”规则，但我希望这仍然是一个可以接受的问题。很抱歉，长度也有很多细微差别。

1）一方面（我-我并非毫无偏见）发现不可变服务器模型对于云系统非常有趣。为此，我们原型化了将基础架构的所有组件移入Docker的过程。我们的定制应用程序通过Jenkins直接构建到部署到本地Docker Registry的Docker映像中。然后，我们创建了大量Ansible角色和一本剧本，该剧本可以连接到空服务器，安装Docker，然后告诉Docker根据需要安装所有容器。几分钟后，整个应用程序及其所有支持的基础结构都已连接并正常工作-日志记录，监视，数据库创建/填充等。完成的机器是一个自包含的QA或开发环境，具有与之完全相同的副本。应用。我们的扩展计划是制造新的Playbook，以从基本受信任的AMI（可能是非常裸露的映像）构建新的AWS服务器，进行生产应用程序的滚动部署以处理配置管理和发布，并且通常不再编辑服务器-只是让他们重新。我不担心在实践中得到我所描述的内容-即使这是一个合理的模型。

2）另一个阵营希望使用Puppet进行配置管理，Ansible部署我们的自定义应用程序，这些应用程序是从我们的构建过程中生成的tarball，Foreman可以处理整个过程的触发和管理，而Katello可以做一些基础工作图像管理。发布将涉及Puppet根据需要更改配置，并通过一定数量的Foreman协调来部署更新的组件。如果我们需要新服务器，则将可以相当快地构建服务器，但目的不是使它们成为一次性使用的标准流程。尽管使用寿命长，但它更接近phoenix服务器模型。

因此，我的问题确实归结为：具有以上所述工具的不可变服务器模型实际上看起来像是现实的吗？我喜欢这样的想法，即我们的登台过程实际上可以实时构建应用程序的完整克隆，让质量检查人员锤打它，然后只需翻转数据库存储和一些DNS设置即可使其生效。

还是不变的服务器模型实际上会失败？我们在AWS和云环境方面都有丰富的经验，因此这并不是真正的问题-而是如何可靠地部署合理复杂的应用程序。由于我们经常发布，因此这特别有趣。

除了实际为我们创建EC2服务器外，Ansible可以完成大多数所需的工作，这并不难。我无法理解为什么您实际上完全需要这个模型中的Puppet / Foreman / Katello。在我所知道的任何工具中，Docker都比自定义部署脚本更加整洁和简单。当您不再担心必须就地配置它们并使用新配置再次构建它们时，Ansible似乎比Puppet使用起来简单得多。我是KISS负责人的粉丝-特别是在墨菲定律猖ramp的自动化领域。机械越少，IMO越好。

关于此方法的任何想法/意见或建议将不胜感激！

在我们公司中，我们已经在客户的传统基础架构上成功实施了Puppet。我们还使用Docker容器运行专用服务（实际上这是一个经过修剪和扭曲以适合容器的旧应用程序）。
第一次盯着容器工作时，我对容器不满意（是的... 30kb的应用程序变成200MB的沉重图像），但是当一次小灾难之后我不得不重新创建整个环境时，我改变了主意。我认为Docker正是为此而发明的：快速且经常部署而无需担心服务器配置。如果正确设计容器，则可以轻松地在云提供商，开发人员便携式计算机和托管数据中心之间切换。因为您只需要一个带有Docker守护程序的普通Linux机器即可。

• 在场景1中，您将所有内容都放在一个地方（我的意思是一个地方，因为使用Docker，您将在同一存储库中拥有代码和配置），易于管理，读取和部署。
  
• 在方案2）中，您必须在一个存储库中存储3个不同（！）工具的配置部分，在另一个存储库中存储应用程序代码，这会使事情变得更复杂

我在上一个项目中也使用过Puppet，到目前为止，我的经验是，使用Docker而不是Puppet或Chef可以实现不可变的服务器。我认为配置管理工具对云提供商而不是开发团队更有用。

这是我的2欧分。

您建议的2个选项是实现（某种）不变性的有效选项。
我认为您应该选择更舒适的一种。
但是，从您写的内容来看，似乎尚未达成共识。
也许需要第三种选择吗？;）

但是，这样的不变性不是目标，而是确保其他属性的方法（无配置漂移，更好的稳定性等）。
我会明确说明我的目标，使用一些指标来验证它们，并使用这两个选项进行一些测试。然后，您需要一些数字来选择最适合您业务的数字。

祝好运！