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