chef 【上篇】BOSH、Ansible和Chef三者比较

说到DevOps，不仅仅指工具，还包括人和流程，我们已经听过上千次了。然而，虽然工具不允许你实现所有目标，但它们至少可以帮助你实现DevOps。一些工具可以帮助自动化和测试。而有些工具可能更注重可观测性(APM)。在本文中，我们将学习一些专门设计来实现“基础设施即代码”概念的工具。它们可以被认为是配置管理、编排或发布工程工具。

工具

各种解决方案以不同的方式解决了这个问题。无论如何，它几乎总是涉及到通过版本控制的、机器可读的文件来定义基础结构。这个领域的选择数不胜数，我们就只关注下面三个:BOSH、Chef、Ansible。但是为什么是这三个呢？

首先，我们尝试选择能够代表不同方法的工具。Ansible是无代理的，而BOSH和Chef不是。BOSH是声明性的，Chef是命令性的，Ansible可以两种形式都有。在某种程度上，他们都用YAML，但是Chef以Ruby为中心，Ansible用Python，BOSH的CLI和agent用Go写，BOSH Director用Ruby写。

虽然比较多，但BOSH往往被忽略。Pivotal大力支持BOSH及其发源地——云铸造社区。需要了解它是如何与Ansible、Chef等更流行的工具竞争的。我们有20多年的IT和云计算工作经验，我们的目标是平衡准确地评估和展示每种工具的优缺点。

我们看到很多比较只是讨论每种工具的优缺点或者简单介绍每种工具的功能。我们想选择一个真实的场景，测试每个工具。一个工具和其他工具的体验有什么不同？经过测试的工具在哪些方面表现良好，需要改进？要评估每一个工具，首先必须定义相应领域需要哪些优秀的工具。

标准

首先，我们必须决定这些工具将在演示中管理哪些实际工作负载。我们使用服务器集群，我们还打算选择熟悉的内容。此外，最好让社区为每个工具构建自动化功能。我们决定构建和管理RabbitMQ集群，它符合所有这些标准。

理解每个工具如何工作的最好方法是遍历一般应用程序基础结构的整个生命周期。因此，我们将在以下五个阶段评估每个工具的功能:打包、配置、部署、监控和升级。本文是第一篇，详细介绍了前三个阶段(初期)的操作和维护。在第二部分，我们将深入了解最后两个阶段(后续)的操作和维护。

让我们仔细看看我们希望通过工具在每个领域实现的目标:

大包

整个工作负载在此阶段定义。这样，工具就知道在服务器上放什么了。具体操作系统重要吗？需要哪些附加软件和设置？应该用哪个版本？我应该如何安装配置软件？打包的主要功能之一是定义特定的、已知的和可验证的已发布软件版本的能力。比较每个工具如何提供操作系统映像也很重要。

分配

定义软件包后，工具如何构建基础设施来托管应用程序？这是供应步骤。了解每个工具如何看待它正在构建的服务器是很重要的。我们通常构建系统，而不是单独的服务器。在这个例子中，能够支持不可变的基础设施通常是很重要的。

调配的不仅仅是虚拟机。工具可以自动化或完全协调以支持网络或存储基础架构吗？这可能与虚拟机规模和操作系统定义重叠。这些参数是包定义的一部分？还是在调配时设置？

部署

我们定义了软件包并建立了底层基础设施。是时候部署应用程序了。在某些情况下，在部署步骤中，将同时调配基础架构和部署应用程序，或者至少在调配后立即快速部署应用程序。当使用不可变的基础设施时，尤其如此。

部署始终保持一致非常重要。部署真的等幂吗？是遵循具体步骤还是更具宣示性？我们希望随时随地部署相同版本的应用程序(和操作系统)。

监控和控制

在下一阶段，我们的基础设施和应用程序将正常运行。我们如何监控它？我们的应用程序可能是一个可以运行其他应用程序的平台，或者是其他应用程序使用的服务。我们可能已经有了一个应用程序监控解决方案，但是我们如何处理基础架构本身呢？工具能为我们处理这些任务吗？还是需要其他工具？

特别值得注意的是所有的恢复功能。如果节点离线会怎样？工具能自愈吗？如果有，如何修复？您只想重新运行应用程序部署，还是创建一个全新的服务器？(回归不可变的基础设施。)是否有可能支持“健康”的定义(如健康检查终点等。)?

升级

最后，我们来看看下一阶段最让人担心的活动，就是升级。工具怎么更新？在操作系统层面？能够在基础架构的所有级别支持零停机升级非常重要。另外，你怎么知道升级成功了？理想情况下，该工具提供了一种在继续之前确认升级有效的方法。以及这些工具如何支持扩展。您能否轻松地将3节点集群转换为6节点集群？

估…的值

现在，我们将仔细看看各种工具是如何根据这些标准进行衡量的。本文是第一篇，只介绍了初始阶段的活动:打包、配置和部署。(在下一个张文，我们最终会引入后续阶段的运维，也就是监控和升级。)我们的代码示例可以在这里找到。

胡说

BOSH指的是“用于分布式系统发布工程、部署、生命周期管理和监控的工具”。名为BOSH Director的中央服务器负责控制生命周期事件。它源于云铸造社区，用于安装和管理云铸造实例。但是，它可以用于管理任何类型的应用程序或基础架构。BOSH特别擅长处理分布式系统，因为它的根。其实BOSH最初是由两位前谷歌工程师创建的，受谷歌用于集群管理的博格系统影响很大。因此，BOSH: borg++ (r+1=s，g+1=h):

大包

BOSH对什么是版本有非常明确的定义。把包装当成一对版本和stemcell是值得的。这两个项目的版本和配置都被集成到用YAML写的声明性清单中。

作为发布的一部分，BOSH希望您提供要安装的组件，而不是在部署时下载组件。这是因为在部署时，所有内容都将根据提供的stemcell进行编译，从而确保一致性。

理想情况下，创建BOSH版本的最佳实践是提供源代码。这样，用于部署的同一操作系统映像上的所有内容都将从头编译。然而，编译可能就像选择可执行文件的源代码并解压缩它一样简单。

声明性清单和您提供组件的事实意味着每次都部署相同的内容。部署之间不会有任何变化。

在我们的例子中，清单定义了一些东西。它不仅告诉BOSH我们想要部署的版本(在这种情况下是RabbitMQ)，还告诉我们从哪里获得它。它还可以提供SHA1散列的一个版本，以确保一切都完好无损，并包含我们希望它包含的内容。

分配

BOSH可以在核心部署过程中提供基础设施，但是了解它是如何单独提供的是值得的。BOSH认为基础设施是不可改变的。也就是说，当你更新底层操作系统时，BOSH会淘汰旧的虚拟机，创建新的虚拟机，而不是去寻找当前状态和期望状态的区别。

BOSH可以为许多IaaS提供商提供“开箱即用”的支持。它还可以为创建其他云提供商接口(CPI)提供标准化的接口。这个抽象定义了与基础设施连接所需的标准操作。这包括创建虚拟机、连接磁盘以及将虚拟机连接到适当的网络。通过提供跨提供商的一致体验，这简化了打包和部署过程。

需要在BOSH范围之外处理的一个基础设施组件是网络连接配置。您必须提前创建子网和防火墙规则。通常，使用Terraform脚本等工具来处理这些内容，以实现过程自动化。

部署

使用BOSH的部署类似于使用其他CM和编排工具的部署，它们都使用CLI命令。首先，必须设置BOSH环境(控制器)，并将相应的操作系统映像(干细胞)上传到环境中。此时，提供列表中的版本有两个选项。指定是从特定的网址提取版本源代码，还是从本地目录获取版本源代码。要使用本地版本，您必须首先使用bosh上传-释放命令上传它。在我们的示例中，我们提供了特定版本的网址和SHA1哈希来验证版本。指定版本位置后，使用以下命令进行部署:

通过使用boshmms命令，我们可以验证在此版本中创建的虚拟机。因为BOSH知道清单中定义的预期状态，所以会一起处理虚拟机、操作系统和软件部署。部署后，BOSH将继续监控该状态，以确保其保持不变。如果虚拟机上的进程崩溃，Monit将发现问题并重新启动该进程。如果虚拟机从网络中删除或消失，BOSH将停用该实例，如果该实例仍然存在，它将在其位置创建一个新实例。它拥有重建理想状态所需的一切。

安塞波

Ansible声称是一个“非常简单的信息技术自动化引擎”，用于自动化云配置、配置管理和应用程序部署。它是无代理的，正是这个主要功能使它保持简单。服务器上没有要连接的中央服务器，也没有要安装的代理。它从控制机(客户端)通过SSH连接运行自动化。

大包

Ansible可以把一切组织成脚本。脚本是Ansible使用YAML描述部署和配置的方式。许多Ansible模块可以用来完成从运行shell命令或连接操作系统包管理器到在AWS中创建虚拟机的一切。Ansible确实为包管理器之类的东西提供了一些抽象。虽然这有助于实现可移植性，但如果脚本作者打算针对多个发行产品，则必须特别小心。

这方面的一个很好的例子是找出我们用来部署RabbitMQ的东西。GCE脚本负责创建虚拟机并确保它们在线。此外，Rabbit脚本从创建的虚拟机中获取信息，然后使用社区创建的角色下载、安装和配置RabbitMQ。了解社区版的工作原理也是值得的。

分配

Ansible围绕如何处理资源调配提供了灵活性和各种选项。与我们讨论过的一些工具相比，并不一致。通过使用一个定制模块，它可以很容易地支持IaaS提供商。有许多现成的或通过社区提供的模块选项。在我们的示例中，我们使用GCE模块:

部署

同样，我们提供了命令行界面命令，这些命令将用于运行部署。Ansible是无代理的，所以不需要提前设置中央服务器或基础设施。唯一的先决条件是客户端可以通过SSH访问目标基础架构。如前所述，目标基础结构本身被指定为脚本的一部分。因此，它将在资源调配过程中通过SSH执行访问操作。以下命令运行部署:

首次运行部署时，将创建必要的虚拟机。在我们的例子中，我们使用谷歌计算引擎(GCE)模块来启动实例。接下来，脚本使用“add_host”模块创建一个临时内存组，以便脚本中的后续活动可以管理该组中的虚拟机。rabbit.yml脚本就是这样在每台主机上安装RabbitMQ的。

厨师

Chef是一个配置管理工具。它是一个常见的“基础设施即代码”工具，经常被DevOps社区引用。类似于BOSH，它有一个维护状态的中心服务器，但更侧重于服务器配置。

大包

和Ansible一样，Chef也有自己描述软件安装和配置过程的方式。厨师的抽象功能，有利于移植，叫做Cookbook。同样的，我们通过厨师超市得到了RabbitMQ食谱。Cookbook使您能够安装、配置和集群RabbitMQ节点。这些烹饪书可以为部署所需的每个步骤提供说明，很像Ansible。然而，《厨师烹饪书》是用Ruby DSL写的，不是YAML。这种格式使辅助代码能够处理更复杂的部署。例如，RabbitMQ Cookbook使操作和维护人员能够指定包管理器版本或从Rabbtmq网站下载，如下所示。我们还可以指定“rabbit_cluster”的角色，它可以结合Cookbook中的特定秘密来定义在每个服务器上运行什么。

分配

像Ansible一样，Chef在如何创建和管理基础架构方面提供了相当大的灵活性。在我们的例子中，我们使用了刀形谷歌插件。这允许我们用一个命令创建虚拟机、启动虚拟机和分配角色。厨师还受益于现有模块的大型生态系统，可用于广泛的基础设施提供商。可以写Cookbook做BOSH做不到的事情。

在我们的例子中，我们使用了刀形谷歌插件，它可以构建虚拟机，启动虚拟机，并且只需要一个命令就可以分配相应的角色。此外，它可以作为一个秘密呈现。

部署

使用刀形谷歌插件，你可以用一个命令处理所有的工作。它可以创建虚拟机，并为它们分配RabbitMQ角色，这样Chef就可以知道预期的服务器状态。命令如下:

待续！

评估后续操作和维护

在第二部分，我们将讨论这三个工具如何处理我们提到的领域中的后续操作和维护:监控和升级。