Puppet SaltStack Chef Ansible

随着服务器集群规模越来越大，自动化配置和部署这些服务器能够使管理变得非常容易并大大减小管理部署成本，因而得到 IT 公司的高度重视。

目前，市场上主流的四大开源自动化配置管理工具有：Puppet、Chef、Ansible、SaltStack。

1 . 如何驾驭这些工具为己所用？

2 . 如何根据不同的应用环境来选用不同的工具？

3 . 如何根据应用来组合使用工具？

以下对这四款工具逐一剖析：

Puppet  

Puppet 也许是四款工具中最深入人心的。就可用操作、模块和用户界面而言，它是最全面的。Puppet 呈现了数据中心协调的全貌，几乎涵盖每一个运行系统，为各大操作系统提供了深入的工具。初始设置比较简单，只需要在需要加以管理的每个系统上安装主服务器和客户端代理软件。

命令行接口 ( CLI ) 简单直观，允许通过 Puppet 命令下载和安装模块。然后，需要对配置文件进行更改，好让模块适合所需的任务；应接到指令的客户端与主服务器联系时，会更改配置文件，或者客户端通过立即触发更改配置文件的推送 ( push ) 来进行更改。

还有一些模块可以提供和配置云服务器实例和虚拟服务器实例。所有模块和配置都使用基于 Ruby 的 Puppet 专属语言或者 Ruby 本身构建而成，因而除了系统管理技能外，还需要编程专业知识。

Puppet 企业版拥有最全面的 Web 用户界面，允许使用主服务器上的预制模块和菜谱 ( cookbook )，实时控制被管理的节点。Web 用户界面很适合用于管理，但是不允许对模块进行诸多配置。报告工具非常完善，提供了详细信息，以便了解代理软件运行如何、已做出什么样的变更。

Chef  

Chef 的总体概念类似 Puppet，因为在被管理的节点上安装有主服务器和代理软件，但实际部署又不一样。除了主服务器外，安装的 Chef 环境还需要工作站来控制主服务器。代理软件可以借助使用 SSH 来部署的 knife 工具从工作站加以安装，减轻了安装负担。之后，被管理的节点通过使用证书，完成与主服务器之间的验证。

Chef 的配置离不开 Git，所以对 Chef 运作而言，了解 Git 如何工作是先决条件。与 Puppet 一样，Chef 同样基于 Ruby，所以还需要了解 Ruby。与 Puppet 一样，模块可以下载，也可以从头开始编写，可以在所需配置之后部署到被管理的节点。

与 Puppet 不一样，Chef 还没有一项完善的推送功能，不过提供了测试版代码。这意味着需要配置代理软件，以便与主服务器进行联系，实际上不可能立即应用变更的内容。

企业版 Chef 的 Web 用户界面很实用，但不提供更改配置的功能。这个 Web 用户界面不如 Puppet 企业版来得全面，缺少报告及其他功能，但允许库存控制和节点组织。

与 Puppet 一样，Chef 得益于一大批的模块和配置菜谱，那些模块和配置菜谱又高度依赖 Ruby。由于这个原因，Chef 非常适合注重开发的基础设施。

Ansible  

Ansible 极其类似 SaltStack ，而不太类似 Puppet 或 Chef 。Ansible 关注的重点是力求精简和快速，而且不需要在节点上安装代理软件。因此，Ansible 通过 SSH 执行所有功能。Ansible 基于 Python；相比之下，Puppet 和 Chef 基于 Ruby。

Ansible 可以通过 Git 软件库克隆，安装到 Ansible 主服务器上。安装完毕后，需要管理的节点被添加到 Ansible 配置环境，SSH 授权密钥被附加到每个节点上，这与运行 Ansible 的用户有关。一旦完成了这步，Ansible 主服务器可以通过 SSH 与节点进行通信，执行所有必要的任务。为了与默认情况下不允许根 SSH 访问的操作系统或发行版协同运行，Ansible 接受 sudo 登录信息，以便在那些系统上以根用户的身份运行命令。

Ansible 可以使用 Paramiko (基于 SSH2 协议的 Python 实现) 或标准 SSH 用于通信，不过还有一种加速模式，允许更快速、更大规模的通信。

针对确保服务在运行，或者触发更新和重新启动之类的简单任务，Ansible 可以从命令行来运行，不需要使用配置文件。至于比较复杂的任务，Ansible 配置通过名为 Playbook 的配置文件中的 YAML 语法来加以处理。Playbook 还可以使用模板来扩展其功能。

Ansible 有一大批模块，可用于管理各种系统以及亚马逊弹性计算云 ( EC2 ) 和 OpenStack 等云计算基础设施。可以用几乎任何一种语言来编写自定义 Ansible 模块，只要模块输出是有效的 JSON。

Ansible 的 Web 用户界面以 AnsibleWorks AWX 的形式出现，但 AWX 与 CLI 并不直接联系在一起。这意味着，除非进行了同步过程，否则 CLI 里面的配置元素不会出现在 Web 用户界面中。你可以使用那个内置的同步工具，让两者保持一致，但需要按照预定计划运行同步工具。

SaltStack  

SaltStack 类似 Ansible，因为它也是基于 CLI 的工具，采用了推送方法实现客户端通信。它可以通过 Git 或通过程序包管理系统安装到主服务器和客户端上。客户端会向主服务器提出请求，请求在主服务器上得到接受后，就可以控制该客户端了。

SaltStack 可以通过普通的 SSH 与客户端进行通信，但如果使用名为 minion 的客户端代理软件，可以大大增强可扩展性。此外，SaltStack 含有一个异步文件服务器，可以为客户端加快文件服务速度，这完全是 SaltStack 注重高扩展性的一个体现。

SaltStack 与 Ansible 一样，你可以直接通过 CLI，向客户端发出命令，比如启动服务或安装程序包 ; 你也可以使用名为 state 的 YAML 配置文件，处理比较复杂的任务。还有“ pillar ”，这些是放在集中地方的数据集，YAML 配置文件可以在运行期间访问它们。

你可以直接通过 CLI，向客户端请求配置信息，比如内核版本或网络接口方面的详细信息。只要使用名为“ grain ”的库存元素，就可以描述客户端 ; 这样一来，管理员可以轻松向某一种类型的服务器发出命令，不需要依赖已配置群组。比如说，只要使用一个 CLI 命令，你就可以向运行某个内核版本的每个客户端发送命令。

与 Puppet、Chef 和 Ansible 一样，SaltStack 也提供了大量的模块，以处理特定的软件、操作系统和云服务。自定义模块可以用 Python 或 PyDSL 来编写。除了 Unix 管理外，SaltStack 的确提供 Windows 管理功能，但它还是更擅长管理 Unix 和 Linux 系统。

SaltStack 的 Web 用户界面 Halite 非常新，功能不如其他系统的 Web 用户界面来得全面。它提供了事件日志和客户端状态的视图，能够在客户端上运行命令，但除此之外乏善可陈。

SaltStack 的较大优点在于可扩展性和弹性。你可以有多个级别的主服务器。上游主服务器可以控制下游主服务器及其客户端。另一个优点在于对等系统，让客户端可以向主服务器提出问题，然后主服务器从其他服务器得到答案，提供全面信息。如果需要在实时数据库中查询数据，以便完成客户端的配置，这个优点就很方便。

工具只是辅助人进行运维的，这中间还需要人的干预和决策，工具并不能完全代替全部运维工作，还需要结合实际业务逻辑和业务场景，就像架构一样，并不是淘宝、百度等大公司的架构，一定适合任何公司和业务。

写在最后：  

自动化的实现不是单纯学习几个工具就能够做好的，甚至于规划不好的情况，自动化不仅没有节省人力，反而带来了更多的问题。

所以运维人员在考虑自动化流程的过程中应该注重以下几点：

1 . 根据应用选择工具。

2 . 对于关键应用，选择成熟度高的工具。

3 . 不能过分依赖一种工具，需要进行对比和分析。

4 . 对工具的特性做到精通。

5 . 是人驾驭工具，人要监督工具，而不是工具来驾驭人。

6 . 善于利用脚本实现定制化场景。