下篇BOSHAnsible 和Chef 三者比较

Posted 2021-04-25 Pivotal

评估 Day 2运维

在上一篇中，我们设置了一些标准，并对比研究了3种不同的用于自动管理服务器或应用系统的“基础架构即代码”工具。在第一部分中，我们只了解了初始活动：打包、调配和部署。现在，我们来深入地看一下各种工具如何按照针对后续运维（监控和升级）制定的标准进行衡量。

BOSH

监控

BOSH同时监控虚拟机（通过自动安装在每个虚拟机上的BOSH代理）和在这些虚拟机上运行的进程（通过Monit）。由BOSH管理的每个虚拟机都将不断向BOSH Director发回检测信号。如果虚拟机出于任何原因而离线，这些检测信号将停止，并且系统将重新创建虚拟机。

此外，BOSH还附带了几个插件，以帮助您集成当前用于发出警报的工具。对于PagerDuty、Datadog、CloudWatch等工具，甚至只是一封很好的老式电子邮件，都可以进行集成。BOSH代理还与每个虚拟机上的Monit进行了集成。这意味着这些功能也会延伸到进程级别。就健康的定义而言，Monit允许进行一些检查，包括检查进程本身。

BOSH的架构还可以让您将作业集中在一起，以便收集指标并将其发送到内部监控和报告解决方案或托管解决方案。例如，我们可以利用bosh-hm-forwarder发送BOSH收集的指标，或为诸如Prometheus等解决方案设置现有版本。

升级

修补和更新也许是BOSH的最大优势领域。BOSH功能已经非常完善，可以轻松实现扩展和零停机滚动更新。我们先来看看简单的扩展。我们可以借助细小的清单更改和CLI命令，将3节点RabbitMQ群集变为6节点群集。我们更新了部署清单中的一行内容，指定了6个实例，而不是3个。然后，我们再次运行部署命令。BOSH负责使环境进入预期状态，启动三个新虚拟机。缩减也是采用相同的方法，从6个更改为3个。

令人高兴的是，这是适用于所有升级功能的模式。想要更新操作系统版本吗？只需更改清单中的stemcell，然后重新部署即可实现。如果需要针对新操作系统重新编译应用，BOSH也可以做到。需要更改应用版本吗？提供新版本，在清单中进行指定，然后重新部署即可实现。因为BOSH拥有虚拟机和操作系统调配以及安装功能，所以这一过程相当简单，且可提供一致的体验。

但BOSH不仅仅非常简单，它还提供了智能升级方式。清单文件允许运维人员定义更新策略。若要执行滚动更新，还可以设置应同时更新的虚拟机数量。它还允许指定金丝雀升级方式，以在继续操作之前验证事情是否进展得顺利。更新操作系统时，它并不是更改虚拟机，而是在新状态下重新创建虚拟机。这遵循了安全性3个R中的“重新铺设(Repave)”原则，因此也更加安全。借助这些结构，BOSH提供了一致的方式来安全执行零停机升级。

Ansible

监控

Ansible开箱即用，不会自动减少中断。无代理，默认情况下不会监控您的虚拟机或其进程。相反，Ansible提供了与许多现有的热门第三方解决方案（比如如DataDog、Pingdom和NewRelic）进行交互的方式。许多监控服务还提供了脚本来帮助安装和配置其代理。一些服务甚至可以监控运行它们的Ansible。

就像我们将RabbitMQ角色变成Ansible Galaxy一样，我们可以针对监控执行相同的操作。从这里，我们可以看到用于安装和配置指标收集代理或设置内部监控解决方案的角色。这就意味着监控和自动修复是由运维人员来实施的。但运维人员可以利用这些角色来集成现有的监控解决方案。

升级

Ansible非常灵活，提供了不同的方式来处理升级。一如既往，具体的升级方法在很大程度上取决于脚本的内容。就我们的示例来说，可以像使用BOSH那样简单地实现纵向扩展。将gce.yml文件中指定的实例数量从3更改为6，然后重新运行脚本。幸运的是，GCE模块知道如何处理事情。如果不知道的话，或者如果脚本依赖于指定的服务器清单，那么事情就会有所不同了。

不过，缩减有所不同。从6更改回3，模块并不会知道它必须删除3个服务器。这成为了一个单独的过程。如果错过了，您最后得到的可能会是您不需要的服务器！另外，如果我们从GCE移动到某个其他IaaS提供程序，那么必须重写整个脚本。因此，一致性是有限的。

至于升级操作系统或应用，这还是依赖于脚本。在我们的GCE示例中，只更改映像名称并重新部署并不会升级操作系统。而借助BOSH，更新清单中的stemcell即可宣告式地确定状态。在这里的Ansible案例中，我们必须首先删除服务器。然后，脚本将使用正确的操作系统重新创建它们。

可以在脚本中添加一些额外步骤，以便首先检查操作系统，或者执行与此类似的操作。但这些内容并不会构建到Ansible内部，也不是GCE模块的一部分。对于应用本身，也是如此。虽然可以用这种方式编写用于安装以及升级的脚本，但有些人认为必须这样编写脚本。是仅仅下载新版本并安装，还是将替换现有版本？由于没有内置不可变基础架构概念，因此很难做出保证，并且将逐个情况地确定更多内容。

Ansible确实有滚动更新的概念。它有一个名为“serial”的参数，可以用来设置定义要同时管理的主机数量。还有一些类似于金丝雀升级的概念。一旦达到某个故障阈值，“max_fail_percentage”参数将停止更新。Ansible还支持预运行和后运行任务，因此可以将检查和回滚构建到脚本中。重申一遍，它非常灵活并且依赖于脚本作者来确定如何执行零停机更新。

Ansible会提供有关故障原因的简要说明，因为它有许多错误处理选项。Ansible中的故障是基于命令和模块的返回代码来确定的。这提供了一种忽略故障并定义“自定义”故障场景的方法。要注意的主要一点是，故障与最近执行步骤的成败息息相关。Ansible没有代理，因此无法了解进程的长期健康。

Chef

监控

与Ansible一样，在监控解决方案方面，我们在出色的灵活性与开箱即用的解决方案之间进行了取舍。我们借助BOSH获得了自动修复和警报功能，而Chef则依赖于运维人员来设置和配置其监控解决方案。我们可以再次向社区寻求此问题的解决方案：可以为New Relic等托管解决方案安装代理，也可以设置像collectd这样的工具来与我们的内部指标收集解决方案集成。

Chef允许运维人员配置系统内发生的事件（比如部署故障），并且该系统有一些集成的监控解决方案（比如Datadog）。这使得运维人员可以从独特视角了解部署本身的指标，这一点非常有用。但长期情况还是取决于环境是如何配置的。

升级

可以使用Chef来升级和扩展应用。然而，这并不像我们使用BOSH那样简单，甚至还不如Ansible简单。在我们的Chef示例中，knife-google插件可一次性调配和配置所有内容。在此模式下，扩展意味着使用不同的主机名运行命令更多次。这将创建更多虚拟机。如果我们将构建调配的路线放入秘诀中，可能还可以更好地扩展虚拟机。在我们的示例中，我们可能会考虑使用脚本来增强knife-google命令。

同样，滚动更新、金丝雀升级或操作系统升级都不是Chef的原生功能。所有这些功能都可以通过使用自定义秘诀来实现。它们全都可以通过组合使用工具来实现，但这项工作留给运维人员自己处理。

总结

那么，您应该使用哪种工具呢？与任何工具选择一样，它取决于使用场景，并且归根结底都要有一些取舍。

Chef和Ansible都提供了一定程度的灵活性。有时这意味着某些任务是手动执行的或需要额外的组件或解决方案。BOSH采取定制程度更高的方法。它采用了用于在云环境中运行分布式软件的最佳实践。BOSH简化了许多运维任务，同时也牺牲了一些灵活性和一次性管理解决方案。修补、升级（应用和操作系统）、健康监控和自愈全都开箱即用。所有这三种工具都可以实现零停机部署，但只有BOSH将其作为核心概念。

此外，BOSH旨在消除环境中的独特性。这有助于确保一致性并强制状态和基础架构分离。对于BOSH，操作系统和应用管理并不是独立的事情。Stemcells和版本可确保明确定义操作系统和软件版本。不可变基础架构可确保虚拟机状态始终与声明的一样。运行stemcell 5的BOSH部署中的虚拟机将始终与运行stemcell 5的其他所有虚拟机相同。

遗憾的是，BOSH的入门门槛比Ansible和Chef高得多。尽管最近采取了一些简化BOSH的措施，但其学习难度仍然非常大。虽然Ansible也使用YAML，但BOSH清单可能比编写脚本更令人感到恐惧。此外，与竞争对手相比，BOSH提供的预包装解决方案较少。对生态系统不熟悉的采用者可能会对BOSH版本这个较小的存储库不满意。

最终，BOSH将分布式系统视为“一等公民”。复杂的服务器群集可以包含在一个BOSH版本中。另一方面，Ansible和Chef则更关注各台主机。它们最终可能会成为使用多个角色的分布式系统。因此，使用哪种工具将取决于您要维护的工作负载和架构类型，请明智选择。

关于作者

Bryan是Pivotal的产品营销总监，他负责帮助客户了解如何改变他们构建软件的方式。在加入Pivotal之前，他曾在一家大型电信公司担任基础架构产品管理总监。在接触云产品管理领域之前，他还在一家涉及各种信息技术领域（包括Web应用开发、文档管理与协作、身份与访问管理以及分析与商业智能）的企业工作了十多年。他和妻子、两个女儿以及一条叫Princeton的小狗一起生活在加利福尼亚州南部。

点击下方“阅读原文”， 查看英文博客

↓↓↓