2
在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越好。 关于此方法的任何想法/意见或建议将不胜感激！