配置管理作为基础使现代基础设施成为可能。在任何运维团队的工具箱中，都需要那些实现配置管理的工具，甚至对于很多开发团队也是如此。尽管所有的工具旨在解决同样的基本问题集，但它们遵循了不同的看法，并表现出不同的特点。问题在于如何选出适合各个组织具体情况的最佳工具。

本文作为该系列的一部分，旨在介绍当前市场上存在的部分配置工具，以及各个工具背后的原理，和使它们彼此脱颖而出的原因。您可以在这里订阅此系列新文章的提醒。

协会当前状态

几个月前，在蒙特利尔Python和DevOps用户组的联合会议上，我做了以下报告：可用于配置管理的多种可选工具项。不论是自己开发，还是从开源中获取，亦或是商业购买来的，大多数系统管理员、开发人员和IT运维专家都用到一些工具用于自动化基础设施和配置所有方面以确保各技术完成我们所期待的工作。在该报告中，我试图为那些最流行的选项提供客观的看法。但这也取决于你的咨询对象及其思维方式，还有他们的管理对象，几乎每个人都有自己的偏好。

在以往的计算日子里，一般公司只需维护少量服务器，IT人员通过频繁地手动调整及重新调整这些服务器就可以保证其LOLcats网站正常平稳地运行。

但自此之后很多情况都发生了变化，尤其最近这几年变化特别大。现在大型数据中心和向外拓展的服务器集群占据了主导地位，手动管理各个服务器已不再可能。各种配置管理工具不断涌现，尽管如此，即使是在过去十年里设计的一些工具也不能适应目前这种规模等级的发展。

SaltStack因此应运而生。尽管也有一些爱好将SaltStack master运用在Raspberry Pi，或利用它管理几台在自己地下室的服务器所组成的家庭网络，但SaltStack的真正目标是速度和规模。这就是为什么LinkIn、WikiMedia和Google都利用它来管理由数以万计服务器构成的大型基础架构。市场需要的并非是另外一个配置管理工具，它需要的是能适合现代Web大规模基础设施的配置管理工具。这篇文章中，我将重点放在使用SaltStack来进行配置管理上。

首先是一个快速远程执行平台

最初SaltStack被设计为一个特别快速、具有可拓展性和强大的远程执行引擎，目的是为了有效控制分布式基础架构、代码和数据。随后，在远程执行引擎上层构建了配置管理，并使用了相同的内核功能。

“SaltStack能做到这点”是Salt社区最常见的评论。对于Salt用户来说，SaltStack就是数据中心的瑞士军刀。持续却轻量级的SaltStack master/minion拓扑为所有环境带来了广泛的控制和功能性，而所有这些都是来自单一平台，不带有第三方依赖。

Salt master是管理Salt minions的守护进程。同样Salt minions也是守护进程，运行于受控系统上，用于接收来自Salt master的命令。按SaltStack的设计，每个master能处理一万个minion进程，但这也只是保守估计。这一规模可以通过异步、并行指令、对实时管理的控制以及与任何数据中心系统的沟通来实现。

对于不需要实时控制或极端速度及规模的轻量级用例，SaltStack同样也提供了Salt SSH“无代理”模式的系统管理。

此外，远程执行和配置管理结合在一起会更好。因为彼此都需要对方在某一时刻开始为其提供真正的基础设施自动化和控制。SaltStack平台为类似持续代码部署或自动拓展资源等事件驱动行为提供了Salt Reactor系统。

想要基本理解SaltStack事件系统则需要先理解SaltStack reactor系统。事件系统是本地ZeroMQ PUB接口，用于触发SaltStack事件。该事件总线是个开放系统，用于给SaltStack和其它系统发送针对各个操作的提示信息。该事件系统所触发的事件带有十分特定的标准。所有事件都带有标签。该事件标签允许对事件进行快速的顶层过滤。除了标签，所有事件还拥有数据结构。该数据结构是一个包含该事件信息的目录。

SaltStack reactor系统处理SaltStack事件，并基于逻辑引擎执行命令，从而允许事件触发行为。SaltStack能处理和响应来自本身和其它类似Jenkins等系统的事件。

近期Hearbleed漏洞就是个很好的例子，它展示了我们的客户如何通过使用SaltStack控制基础架构的所有点点滴滴。SaltStack以毫秒速度跨越整个大型基础架构，被用于诊断和修复Heartbleed。比如：来自WebPlatform.org和WikiMedia的这些推文强调了SaltStack在作出这些修正时的简单性：

在多台服务器上打OpenSSL的漏洞补丁包？只要输入salt ‘*’pkg.install openssl。是的，就这么简单！Salt Stack真的是太棒了。

- Renoir Boulanger （@renoirb）2014年4月8号

多亏了#SaltStack ,Wikimedia的heartbleed 补丁包安装的相当快速且容易。

- Ryan Lane（@SquidDLane）2014年4月8号

以下SaltStack命令使得评估和修复Heartbleed漏洞成为可能：

Salt \*pkg.install openssl refresh=True; salt \*service.restart nginx; #devops #saltstack #heartbleed

- Dan Garthwaite(@DanGarthwaite) 2014年4月8号

IMO，1000%值得，最新的@SaltStackInc仅远程执行功能就值得拥有。命令行检测40台服务器上的OpenSSL就只要0.2秒！

- John Albietz（@inthecloud247）2014年4月10号

基础设施即数据，而非代码

通过实施“基础设施即数据”方法，SaltStack的配置管理学习和采用曲线已降低。在不牺牲任何功能和性能的情况下，该方法相对传统“基础设施即代码”方法大大降低了复杂度。“基础架构即代码”通常要求用户能够理解复杂的机器代码语言或领域特定语言。而SaltStack方法可人工阅读，当然也能轻松地被机器解读。

尽管SaltStack是用Python语言编写，但其配置管理是语言无关的，且使用了简单、人类可读的YAML文件和Jinja模板。

DevOps和可扩展的WebIT要求速度、敏捷性和通信。学习曲线越短，其竞争优势就越大。尽管在“基础设施即代码”上投资显著，但其实并不需要，因为它阻碍了创新和部署，本来部署就应以快速为原则尽可能快地将服务器及其上面运行的软件调整到稳定、可重用和生产就绪的状态。何必坐着航天飞机到街角市场，明明走路或骑自行车更容易？

极具灵活性

SaltStack由多个不同模块层组成的，全部都利用了相同的快速通信总线，这允许了其与尽可能多的服务器进行并行通信以通知服务器应该做什么。这些命令、例行程序和功能所组成的层为整个计算基础架构和所有数据中心内容提供了广泛的控制。我们的很多用户都通过SaltStack通知Puppet manifest应该做什么，因为SaltStack可以用于管理软件、云或虚拟化的其它任意部分。

在过去几年里对于选择声明式还是命令式方式来配置管理，一直存有纷争。而我们，则“往该纷争中插了个叉子”。SaltStack不仅可使用声明式配置管理，也可以用于命令式。至于怎么用，就取决于你怎么想，以及你的系统如何被管理。

SaltStack配置管理可以以命令式方式执行，所有事务将按给定顺序执行。也可以以声明式方式执行，系统决定如何执行对象间匹配有关联的各事务。

命令式排序是有限的，普遍被认为比较容易编写。声明式排序则强大很多，也更灵活，但往往比较难写。

SaltStack的创建就是为了最好地使用这两种配置方式。状态以有限顺序评估，保证了所有状态总是按同样的顺序执行，而状态运行时确是声明式的，使得Salt能完全意识到关联。Salt总是以有限方式执行状态，这意味着不论运行系统怎样，它们都将以相同的顺序执行。尽管如此，SaltStack近期添加了状态自动排序这一选项，使得状态能按其在Salt状态文件中所定义的顺序被评估。

评估顺序允许我们简单地获知状态将以什么顺序执行，但值得注意的是，在必要时系统会覆盖文件中定义的排序。下面将要描述的排序选项也可以覆盖Salt状态文件中所定义的状态顺序。

当SaltStack提供hook（比如：“on fail”或“on change”）到声明式路径中时，其架构所蕴含的能量允许往配置管理运行过程中插入例行程序，这样即使第一次失败了，也可能在换种方式尝试后成功。SaltStack的先决条件就是其中一个例子。先决条件只有当系统中将来有其他事情发生时才会对系统产生该事件。它是个幂等方式内嵌预测分析。它会问这个问题：“我是否即将要部署代码了？确定？那就把服务器从负载平衡器上卸下来，或者将Apache关闭吧。但所有这些操作只有当我对系统有所修改时发生。”或者SaltStack“fail hard”标识会进一步为命令式配置管理提供能量：相对于放弃例行程序，它会通知流程关于事情部署的情况。

使用SaltStack在Red Hat上安装LAMP Stack

一个简单的SaltStack配置管理场景是安装LAMP stack。尽管在GitHub上有关于更完整采用SaltStack方案的组织实例（https://github.com/saltstack-formulas），但本例应能充分地展示了基本的方案，它是某一指定资源配置管理的预编写Salt状态。SaltStack方案和状态可以用于类似、：安装软件包、配置和启动一个服务、设置用户或权限以及其他常见任务。

由于该例子是为基于Linux的Red Hat环境设计的，其中包含了Python 2.6为现有基础安装的一部分，其Linux和Python部分已经完成了。所有需要做的就是配置一个Web应用程序并使用Apache Web服务器和MySQL数据库服务器。

开始前，我们要确保/srv/salt/目录存在于服务器中。

因为Web应用程序需要在使用前安装数据库服务器，我们将首先定义数据库服务器。

# /srv/salt/mysql.sls
mysql:
 pkg.installed:
  - name: mysql-server
 service.running:
  - enable: True
  - require:
   - pkg: mysql-server

由于该例子除了声明外，并不包含其它任何文件。我们可以简单地将其保存为:/srv/salt/mysql.sls。但是Apache的安装比较复杂，因为它包含了一个配置文件。该文件通过使用file.managed功能被拷贝到web服务器上，支持了像templating这样加强的功能。为了适应这种情况，我们通过在/srv/salt/目录下创建apache/子目录，并创建以下文件：

# /srv/salt/apache/init.sls
httpd:
 pkg.installed:
  - name: httpd
   - file: httpd
 service.running:
  - enable: True
  - require:
   - pkg: httpd
 file.managed:
  - name: /etc/conf/httpd/httpd.conf
  - source: salt://httpd/httpd.conf
  - require:
   - pkg: httpd

由于更多的文件将添加到该方案中，我们创建另外一个目录来保存它们。该目录在包含一个init.sls文件的同时，也包含被管理的httpd.conf文件副本。这些文件现在会与top.sls文件绑定在一起。

# /srv/salt/top.sls
base:
 web*:
  - apache
 db*:
  - mysql

该文件就像胶水一样将这些状态连接在一起，定义了每个服务器上所应用的状态。需要注意的是该文件并没有涉及任何具体路径。因为top.sls定义了这类信息，因此SaltStack会到top.sls目录下查找。当SaltStack在top.sls中找到所需名称，接下来它会查找与其名称相对应的.sls文件（比如：mysql.sls）或者目录，该目录包含一个init.sls文件（比如：apache/init.sls）。

该定义确保了所有名字以“web”为开头的服务器（比如：web01，甚至是web01.example.com）都会有指定的Apache状态，还有任何名字以“db”开头的服务器（比如：db01或db01.example.com）都会有指定的MySQL状态。

将这些状态应用到所有服务器上，我们需要开始运行一个highstate命令:

salt ‘*’ state.highstate

Highstate是状态数据的结合（程序包、服务和文件等），它将应用到目的系统中。

然而，它也提出了另一个挑战。正如我上面所说的，这些web服务器如果没有可工作的数据库服务器的话，基本上是派不上什么用场。该场景在两者都存在的情况下可以正常工作，我们只要往组合中添加服务器就可以了。但对于一个干净的环境，没有任何服务器的情况该怎么办？

这时候就该轮到SaltStack流程引擎上场了。可以通过定义状态执行顺序来定义机器部署顺序：

# /srv/salt/myorchestration.sls
db_setup:
 salt.state:
  - tgt: ‘db*’
  - highstate: True
web_setup:
 salt.state:
  - tgt: ‘web*’
  - highstate: True
  - require:
   - salt: db_setup

这个文件定义了我们之前定义的web状态只有在我们所定义的数据库状态执行完后才能执行。启动该状态，可以执行：

salt-run state.orchestrate myorchestration

注意：在salt 0.17.x里，该命令为：

salt-run state.sls myorchestration

寻址配置漂移

上述场景对初始配置一组服务器是可行的。如果按计划执行的话，它会通过配置漂移缓解问题：如果服务器上httpd.conf文件被修改了，SaltStack会将其放置回它需要在的地方，然后汇报给用户都要做那些修改，以回到正确的状态。但程序包的版本怎么办呢？

当pkg.installed状态被声明后，SaltStack会检测底层包管理器来查看该程序包是否已经安装。如果是，那么该状态就已经实现了，不需要任何进一步行为。然而，如果该程序包还没被安装的话，SaltStack也会通知包管理器安装该程序包，通常会检测该程序包(依具体环境而异)的最新可用版本，然后安装。

但随着时间的推移，这会造成一些服务器上的程序包所带版本不一样，由此产生的问题也将难以定位。其解决方案就是使用pkg.lastes状态取而代之，这样可以一直保证所有服务器上运行的程序包版本都是最新的。

httpd:
 pkg.latest:
  - name: httpd

尽管如此，这也可能产生问题。只要有新版本出来，所有服务器都会试图下载安装。如果你没有预料到会有新版本，且还没有时间执行内部测试的话，这会造成很严重的问题。所以最好还是锁定某一特定版本的程序包比较好：

httpd:
 pkg.installed:
  - name: httpd
  - version: 2.2.15

这保证了只有在状态声明中明确更新时，安装包才会被升级。

SaltStack测试模式

另外一个重要特性是提前知道即将发生的变化。这点简单到只要往highstate命令添加一个选项就可以：

salt ‘*’ state.highstate test=True

当运行于测试模式时，那些已各就各位的状态将显示为绿色，而那些还未执行的状态将显示为黄色。很多用户觉得在实际执行前，能够看到所需执行的变化特别重要。

当然，测试模式也可以用在业务流程引擎中：

salt-run state.orchestrate myorchestration test=True

该命令会按myorchestration.sls文件中定义的顺序评估highstate；与此同时，如果命令在测试模式以外运行的话，也会以相同的方式显示将做出的修改。

总结

SaltStack在配置管理上有明显的重点突破，但我们也不敢打包票。SaltStack学习和运行起来都很简单，我们的社区也非常有活力和帮助，可以一路帮助那些自己动手的人；对于需要帮助的公司，SaltStack Enterprise提供了相应的SaltStack服务和支持团队。