我们正在遇到一个有趣的争论，正在陷入两个阵营。 我感兴趣的任何想法或陷阱我们可能会失踪的任何特定的问题。 真的，任何能够帮助我们做出决定的东西，或者指出我们没有考虑到的事情。 我知道这个裙带着“无意见”的规则，但我希望这仍然是一个可以接受的问题。 对不起，长度也有一些微妙的差别。
1）一方（我 – 我不是没有偏见）发现云系统非常有趣的不变的服务器模型。 为此，我们将基础架构的所有组件移植到Docker中。 我们的自定义应用程序通过Jenkins直接构build到部署到本地Docker Registry的Docker镜像中。 然后，我们创build了一大组Ansibleangular色和一个能够伸手去找空服务器的剧本，安装Docker，然后告诉Docker根据需要安装所有的容器。 几分钟后，整个应用程序及其所有的支持基础架构就被连接起来并工作 – logging，监视，数据库创build/填充等。完成的机器是一个独立的QA或开发环境，具有应用。 我们计划扩大规模的计划是制作新的手册，从基础可信AMI（可能是一张非常光滑的图像）构build新的AWS服务器，对生产应用程序进行滚动部署以处理configurationpipe理和发布，而且通常不会再次编辑服务器 – 只是让他们重新。 我并不担心在实践中得到我所描述的工作 – 只要这是一个合理的模型。
2）另一个阵营希望使用Puppet来处理configurationpipe理，Ansible部署我们的自定义应用程序，这些应用程序是我们构build过程中生成的压缩包，Foreman负责处理整个stream程的触发和pipe理，Katello做一些基础图像pipe理。 发布将涉及Puppet根据需要更改configuration和Ansible部署更新的组件与一定数量的工头协调。 如果我们需要新的服务器，那么服务器的build立就会相当快，但是不要把它们作为标准stream程的一部分来处理。 尽pipe使用寿命长，但它更接近凤凰服务器模式。
所以我的问题真的归结为这个：是不是一成不变的服务器模型，我已经用上面描述的这些工具实际上是现实的了？ 我喜欢这样一个想法，即我们的暂存过程实际上可以在现场构build完整的应用程序副本，让QA锤击它，然后只是翻转数据库存储和一些DNS设置以使其生存。
还是不可变的服务器模型在实践中失败？ 我们在AWS和云环境方面拥有丰富的经验，所以这不是关注的问题 – 更重要的是如何让一个相当复杂的应用程序可靠地部署到今后。 这是我们特别感兴趣的，因为我们经常发布。
我们有Ansible，除了为我们创buildEC2服务器之外，还需要做大部分工作，这并不困难。 我很难理解为什么你真的需要木偶/工头/ Katello在这个模型中。 Docker比任何自定义的部署脚本更加清洁和简单。 Ansible似乎比Puppet简单得多，当你不必担心必须现场configuration它们，而只需使用新configuration再次构build它们。 我是KISS校长的粉丝，尤其是在墨菲法则猖獗的自动化领域。 国际海事组织越好，机械越less。
任何想法/意见或build议的方法将不胜感激！
在我们公司，我们已经成功地在客户的遗留基础设施上实施了Puppet。 我们也在使用Docker容器来运行一个专门的服务（事实上这是一个旧的应用程序被修剪和扭曲以适应容器）。
当我第一次和他们一起工作时，我对容器不满意（是的，30kb的应用程序变成了200MB的大图片），但是当我在一场小小的灾难之后不得不重新创build整个环境时，我改变了主意。 我认为Docker正是为此而发明的：快速且经常部署，无需担心服务器configuration。 如果您正确devise容器，则可以轻松地在云提供商，开发人员笔记本电脑和托pipe数据中心之间进行切换。 因为所有你需要的是一个带有Docker守护进程的vanilla Linux机器。
在我以前的项目中，我也是使用Puppet的，我迄今为止的经验是，不可变的服务器可以实现，而不是使用Docker而不是Puppet或Chef。 我相信configurationpipe理工具对云提供者而不是开发团队更有用。
这是我的2欧分。
你提出的两个选项是实现（某种）不变性的有效选项。
我想你应该select一个更舒适的。
但是，从你写的东西看来，目前还没有达成共识。
那么可能需要第三个选项？ ;）
然而，由于这种不变性不是一个目标，而是确保其他属性（没有configuration漂移，更好的稳定性…）的手段。
我会清楚地说明我的目标，提出一些指标来validation它们，并使用2个选项做一些testing。 然后你会有一些数字来select最符合你的业务的数字。
祝你好运！