使用 Docker/Ansible 的不可变服务器模型 vs. AWS 中的 Ansible、Puppet 和 Foreman？

Question

我们遇到了一个有趣的争论，并陷入了两个阵营。我对我们可能遗漏的想法或陷阱的任何特定问题感兴趣。真的，任何可以帮助我们做出决定或指出我们没有考虑的事情的东西。我知道这有点接近“无意见”规则，但我希望这仍然是一个可以接受的问题。长度也很抱歉，有一些细微差别。

1）一方面（我的 - 我并非没有偏见）发现不可变服务器模型对于云系统非常有趣。为此，我们设计了将基础架构的所有组件迁移到 Docker 中的原型。我们的自定义应用程序通过 Jenkins 直接构建到部署到本地 Docker Registry 的 Docker 镜像中。然后我们创建了大量 Ansible 角色和一个剧本，它能够接触到一个空服务器，安装 Docker，然后告诉 Docker 根据需要安装所有容器。几分钟后，整个应用程序及其所有支持基础设施都已连接好并开始工作 - 日志记录、监控、数据库创建/填充等。完成的机器是一个独立的 QA 或开发环境，具有精确的副本应用。我们的扩展计划是制作新的 Playbooks 以从基本可信 AMI（可能是一个非常裸的镜像）构建新的 AWS 服务器，滚动部署生产应用程序以处理配置管理和发布，并且通常不再编辑服务器 -只是让他们重新。我并不担心在实践中得到我所描述的东西——只要它是一个合理的模型。

2) 另一个阵营想用 Puppet 来处理配置管理，Ansible 来部署我们的自定义应用程序，这些应用程序是从我们的构建过程中生成的 tarball，Foreman 来处理整个过程的触发和管理，而 Katello 来做一些基础形象管理。发布将涉及 Puppet 根据需要更改配置，以及 Ansible 通过一定数量的 Foreman 协调部署更新的组件。如果我们需要新的服务器，服务器的构建速度会相当快，但目的不是让它们成为标准流程的一部分。虽然寿命很长，但它更接近凤凰服务器模型。

所以我的问题真的归结为这个：带有我上面描述的工具的不可变服务器模型实际上和它看起来一样真实吗？我喜欢这样的想法，即我们的暂存过程实际上可以实时构建应用程序的完整克隆，让 QA 对其进行锤击，然后只需翻转数据库存储和一些 DNS 设置即可使其生效。

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

除了实际为我们创建 EC2 服务器之外，我们让 Ansible 做大多数需要的事情，这并不难。我无法理解为什么您实际上需要在此模型中使用 Puppet/Foreman/Katello。Docker 比我能说的任何工具中的自定义部署脚本都要干净和简单得多。当您不再担心必须就地配置它们而只需使用新配置重新构建它们时，Ansible 似乎比 Puppet 更易于使用。我是 KISS 原则的粉丝——尤其是在墨菲定律猖獗的自动化领域。机器越少越好 IMO。

对这种方法的任何想法/意见或建议将不胜感激！

Answer 1

这是我的 2 欧分。

您提出的两个选项是实现（某种）不变性的有效选项。
我认为你应该选择一个你更舒服的。
然而，从你写的内容来看，似乎还没有达成共识。
也许需要第三种选择？;)

然而，这种不变性不是目标，而是确保其他属性的手段（无配置漂移、更好的稳定性……）。
我会清楚地陈述我的目标，设置一些指标来验证它们，并使用这两个选项进行一些测试。然后，您将获得一些数据来选择最适合您的业务的数据。

祝你好运！