配置管理作为基础使现代基础设施成为可能。在任何运维团队的工具箱中，都需要那些实现配置管理的工具，甚至对于很多开发团队也是如此。尽管所有的工 具旨在解决同样的基本问题集，但它们遵循了不同的看法，并表现出不同的特点。问题在于如何选出适合各个组织具体情况的最佳工具。 本文作为该系列的一部分，旨在介绍当前市场上存在的部分配置工具，以及各个工具背后的原理，和使它们彼此脱颖而出的原因。您可以在这里订阅此系列新文章的提醒。 协会当前状态几个月前，在蒙特利尔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在作出这些修正时的简单性：
以下SaltStack命令使得评估和修复Heartbleed漏洞成为可能：
基础设施即数据，而非代码通过实施“基础设施即数据”方法，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”标识会进一步为命令式配置管理提供能量：相对于放弃例行程序，它会通知流程关于事情部署的情况。 |
