上篇BOSHAnsible和Chef三者比较

Posted 2021-04-25 Pivotal

谈及DevOps，并非仅仅意味着工具，还涉及人员和流程，这句话我们已经听了几千次了。然而，虽然工具确实无法让您实现所有目标，但它们至少可以帮助您实现DevOps。有些工具能够有助于自动化和测试(CI/CD)。而有些工具则可能更关注可观察性(APM)。在本文中，我们将了解一些专为实现“基础架构即代码”理念而设计的工具。它们可能会被视为配置管理(CM)、编排或发布工程工具。

工具

各种解决方案以不同的方式解决此问题。无论如何，几乎都会涉及通过版本受控制的、机器可读的文件定义基础架构。此领域中有无数个选项，我们只重点讨论以下三个：BOSH、Chef和Ansible。但为什么是这三个呢？

首先，我们努力选择能够代表互不相同的方法的工具。Ansible是无代理的，而BOSH和Chef则不然。BOSH是声明式的，Chef是命令式的，Ansible可以兼具这两种形式。在某种程度上来说，它们都使用YAML，但Chef以Ruby为中心，Ansible利用Python，BOSH的CLI和代理采用Go编写，而BOSH Director采用Ruby编写。

虽然有大量比较，但BOSH经常被忽略。Pivotal极力拥护BOSH及其发源地——Cloud Foundry社区。我们有必要了解一下它如何与Ansible和Chef等更受欢迎的工具相抗衡。我们在IT和云计算领域拥有20多年的工作经验，我们的目标是公平地以一种均衡且准确的方式评估和展示每种工具的优缺点。

我们看到许多比较只讨论了每种工具的利弊或只简要介绍了每种工具的功能。我们想选择一个实际场景，对每种工具进行测试。对一种工具的体验与对其他工具的体验相比有何不同？被测试的工具在哪个方面表现出色以及在哪个方面需要改进？要对每种工具进行评估，首先必须定义相应的领域需要哪种出色的工具。

标准

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

了解每种工具如何运作的最佳方式是让其遍历一般应用基础架构的整个生命周期。因此，我们将评估每种工具在以下五个阶段中的功能：打包、调配、部署、监控、升级。本文是第一篇，详细介绍了前三个阶段（初始）的运维。在第二部分中，我们将深入了解后两个阶段（后续）的运维。

我们来详细了解一下我们希望通过工具在每个领域实现的目标：

打包

整个工作负载是在此阶段定义的。工具通过这种方式了解将哪些内容放在服务器上。特定操作系统是否重要？需要哪些额外的软件和设置？应该使用哪个版本？应该如何安装配置软件？打包的一个主要功能是能够定义所发布的软件的具体、已知且可验证的版本。另外，比较每种工具如何提供操作系统映像也很重要。

调配

定义软件包后，工具如何构建基础架构来托管应用？这就是调配步骤。了解每种工具如何查看它要构建的服务器非常重要。 我们通常会构建系统，而不是各台服务器。在此示例中，能够支持不可变基础架构通常很重要。

调配的对象也不仅仅是虚拟机。工具能否实现自动化或全面进行编排以支持网络或存储基础架构？这可能与虚拟机规模设定和操作系统定义存在一些重叠。这些参数是软件包定义的一部分？还是在调配时设置？

部署

我们定义了软件包并设置了底层基础架构。现在是时候部署应用了。在一些情况下，在部署步骤中将会调配基础架构，同时部署应用，或者至少在调配后紧接着快速部署应用。在使用不可变基础架构的情况下尤为如此。

重要的是，部署始终都是一致的。部署是否真的是幂等的？它是否遵循了特定的步骤或者它是否更具声明性？我们希望在所有时候、所有位置部署的都是同一个版本的应用（以及操作系统）。

监控

后续阶段，我们的基础架构和应用启动并正常运行。我们如何对其进行监控？我们的应用可能是能够运行其他应用的平台，也可能是其他应用使用的服务。我们可能已经拥有应用监控解决方案，但我们如何处理基础架构本身呢？工具能否为我们处理这些工作？或者我们是否还需要其他工具？

特别引人注意的是所有恢复功能。如果节点离线，会怎么样？工具能否自愈？如果能，是如何修复呢？是仅重新运行应用部署，还是创建一台全新的服务器？（重新回到不可变基础架构。）是否有能力支持定义“健康”的含义（比如健康检查端点等）？

升级

最后，我们来了解一下最令人担心的后续阶段的活动，也就是升级。工具如何推出更新？在操作系统级别呢？能够在基础架构的所有级别支持零停机升级非常重要。此外，如何知道升级奏效了？理想情况下，工具提供了在继续前确认升级有效的方法。以及工具如何支持扩展？能轻松地将3节点群集转变成6节点群集吗？

评估

现在，我们将详细了解一下各种工具如何按照这些标准进行衡量。本文是第一篇，只介绍初始阶段的活动：打包、调配和部署。（在接下来的文章中，我们将最后介绍后续阶段的运维，也就是监控和升级。）在此处可以找到我们的代码示例。

BOSH

BOSH是指“用于分布式系统发布工程、部署、生命周期管理和监控的工具”。名为BOSH Director的中央服务器负责控制生命周期事件。它源于Cloud Foundry社区，用于安装和管理Cloud Foundry实例。但是，它可用于管理任意类型的应用或基础架构。由于BOSH的根，它尤其擅长处理分布式系统。实际上，BOSH最初由两名前Google工程师创建，受到了Google内部用于群集管理的Borg系统的重大影响。故名BOSH: borg++ (r+1=s, g+1=h)：

打包

BOSH对什么是版本有非常明确的定义。将打包视为版本和stemcell（操作系统映像）的结对是值得的。这两项的版本以及配置全都集成到了一个采用YAML编写的声明式清单中。

作为版本的组成部分，BOSH希望您提供要安装的组件，而不是在部署时下载组件。这是因为一切内容都会在部署时根据所提供的stemcell得到编译，从而确保一致性。

理想情况下，用于创建BOSH版本的最佳实践是提供源代码。这样一来，部署时使用的同一操作系统映像上的一切内容都会从头开始编译。但是，编译可能与选取一个可执行文件的原始码并将其解压缩一样简单。

声明式清单和您提供组件这一事实意味着每次都会部署同样的内容。各次部署之间，不会有任何改变。

在我们的示例中，清单定义了一些内容。它不仅告诉BOSH我们要部署的版本（在本例中是RabbitMQ），还告诉BOSH从哪里获取该版本。它还可以提供版本的SHA1哈希，以确保一切完好无损并包含我们希望它包含的内容。

此外，我们告诉BOSH我们想用于编译和运行RabbitMQ的Stemcell的名称和版本。

最后，我们可以针对部署提供一些配置细节。这包括要部署的实例数量和实例大小等内容，还包括特定于RabbitMQ的一些内容，比如要启用的插件。

调配

BOSH可在核心部署流程中调配基础架构，但单独了解一下它是如何调配的是非常值得的。BOSH将基础架构视为不可变的。也就是说，在您更新底层操作系统时，BOSH将淘汰旧虚拟机并创建新虚拟机，而不是找到当前状态和预期状态之间的差别。

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

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

部署

利用BOSH进行部署的方式与采用其他CM和编排工具时类似，都要使用CLI命令。首先，必须使用上传至环境的相应操作系统映像(stemcells)设置BOSH环境(Director)。此时，有两个选项可用于提供清单中的版本。指定是从特定URL提取版本原始码，还是从本地目录中获取它。要使用本地版本，必须先使用bosh upload-release命令上传它。在我们的示例中，我们提供了特定版本的URL以及SHA1 hash哈希，以用于验证版本。指定版本位置后，使用以下命令进行部署：

通过使用bosh vms命令，我们可以验证作为此版本组成部分而创建的虚拟机。由于BOSH知道清单中定义的预期状态，它会一并处理虚拟机、操作系统和软件部署。部署完成后，BOSH将继续监控此状态以确保它保持不变。如果虚拟机上的进程崩溃，Monit将捕捉到此问题并重新启动进程。如果虚拟机从网络掉线或消失，BOSH将淘汰该实例，如果实例仍然存在，则它会在其位置上创建新实例。它拥有重新创建预期状态所需的一切。

Ansible

Ansible声称是“非常简单的IT自动化引擎”，用于自动执行云调配、配置管理和应用部署。它是无代理的，正是这一主要功能才让其能够保持简单性。没有要连接的中央服务器，也没有要在服务器上安装的代理。它通过SSH从控制机器（客户端）进行连接，以运行自动化。

打包

Ansible可将一切都整理到脚本中。脚本是Ansible使用YAML描述部署和配置的方式。许多Ansible模块可用于完成从运行shell命令或与操作系统软件包管理器连接到在AWS中创建虚拟机的一切操作。Ansible确实能够为软件包管理器等内容提供一些抽象化功能。虽然这有助于实现可移植性，但如果脚本作者打算面向多个发行版产品，就必须特别注意。

与此相关的一个很好的例子是了解一下我们用于部署RabbitMQ的内容。GCE脚本负责创建虚拟机并确保它们上线。此外，Rabbit脚本从创建的虚拟机中获取信息，然后利用社区创建的角色下载、安装和配置RabbitMQ。了解一下社区版本的运作方式也是值得的。

调配

Ansible围绕如何处理调配提供了相应的灵活性和各种选项。与我们讨论过的一些工具相比，它不具备一致性。它确实可以通过使用其中一个自定义模块轻松为IaaS提供程序提供支持。有许多开箱即用的或通过社区提供的模块选项。在我们的示例中，我们使用GCE模块：

调配可以像Ansible中的任何其他任务一样执行，具有出色的可自定义性。这意味着您要为自己的基础架构编写和维护脚本。模块是特定于IaaS的，如果您要在多个提供程序上运行，则需要维护多个脚本。编写脚本通常是为了了解现有主机、收集关于这些主机的信息以及弄清楚需要执行哪些操作才能让它们达到预期状态。

这是与BOSH比较的，BOSH只需删除旧主机，并启动具有全部所需更新的新主机。

在网络管理方面，Ansible要胜于BOSH。对于子网、防火墙规则和负载均衡器，是通过脚本创建和修改的。正如我们所看到的，利用BOSH，必须手动或使用Terraform等外部自动化工具提前创建这些内容。

部署

同样，我们提供了CLI命令，该命令将用于运行部署。Ansible是无代理的，所以无需提前设置中央服务器或基础架构。唯一的前提条件是客户端能够通过SSH访问目标基础架构。如前文所述，目标基础架构本身作为脚本的一部分指定。所以它将在调配过程中通过SSH执行访问操作。以下命令可运行部署：

首次运行部署时，将创建必要的虚拟机。在我们的示例中，我们使用Google Compute Engine (GCE)模块启动实例。接下来，脚本利用“add_host”模块创建临时的内存中组，以便脚本中的后续活动能够管理该组中的虚拟机。这就是rabbit.yml脚本在每台主机上安装RabbitMQ的方式。

第二次运行部署时，会怎么样呢？GCE模块识别到已存在虚拟机，不会重新创建虚拟机。如果虚拟机丢失，则它会创建新的虚拟机。但是，如果没有代理，就没有什么能主动监控虚拟机并确定是否需要重新创建虚拟机了。必须先手动运行部署或将部署作为计划任务的一部分运行，然后再重新创建虚拟机。此示例介绍了GCE模块的工作方式。每个模块的运作方式都不同，各脚本彼此独立工作。因此，确保幂等性可能颇具挑战性。

对于能够安装软件的脚本本身，也有各种不同的编写方法。幸运的是，我们所引用的脚本jasonroyle.rabbitmq刚好允许指定特定版本的软件进行下载。这样一来，便可以轻松下载最新版本。这种方法做到了这一点，所以，后续部署可能与之前的部署有所不同。

脚本可采用这样一种方式编写：部署始终以一致方式运行。但是，利用Ansible，还能够以声明性更低、顺序性更强的方式编写脚本。简而言之，部署一致性极其依赖于脚本的编写方式。应该尽可能地遵循最佳实践以确保幂等性。

Chef

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

打包

和Ansible一样，Chef对于描述软件安装和配置流程有自己的方式。Chef的有助于实现可移植性的抽象化功能被称为Cookbook。同样，我们通过Chef Supermarket来获取RabbitMQ Cookbook。Cookbook使您能够安装、配置和群集化RabbitMQ节点。这些Cookbook能够为部署所需的每个步骤提供相关说明，与Ansible非常像。但是，Chef Cookbook是采用Ruby DSL编写的，而不是YAML。这种格式使辅助代码能够处理更加复杂的部署。例如，RabbitMQ Cookbook使运维人员能够指定软件包管理器版本或从RabbitMQ网站下载，正如此处所示。我们还可以指定“rabbit_cluster”角色，该角色可结合Cookbook中的特定秘诀来定义在每台服务器上运行哪些内容。

调配

和Ansible也一样，Chef在如何创建和管理基础架构方面提供了相当大的灵活性。在我们的示例中，我们使用了knife-google插件。这让我们能够使用一条命令创建虚拟机、启动虚拟机以及分配角色。Chef还受益于现有模块的大型生态系统，该系统可用于广泛的基础架构提供程序。可编写Cookbook来完成BOSH做不到的事情。

在我们的示例中，我们使用了knife-google插件，只需一条命令即可构建虚拟机、启动虚拟机以及分配相应的角色。另外，它能够以秘诀的形式呈现。

部署

利用knife-google插件，只需一条命令即可处理所有工作。它可以创建虚拟机并向其分配RabbitMQ角色，以便Chef了解预期的服务器状态。命令如下所示：

knife-google插件使调配基础架构变得更加便捷。作为配置管理工具，Chef更侧重于让主机达到预期状态。同样，这与BOSH的不可变基础架构方法相反，后者可能更适合以应用单元或群集的形式管理服务器群。

和BOSH一样，Chef具有一个中央服务器，该服务器可主动工作以让服务器保持预期状态。但是，和Ansible一样，它主要专注于弄清楚需要执行哪些操作才能让服务器达到预期状态。这意味着应用和配置的部署是相当一致的。但是，Chef不会管理操作系统或底层虚拟机本身。

未完待续！

评估后续运维

在第二部分中，我们将探讨这三种工具分别如何处理我们提到的领域所涵盖的后续运维：监控和升级。