作者：约瑟夫·霍尔
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
精通SaltStack试读：
前言
很高兴能完成这本书的写作。从Tom Hatch脑中的一个构想，到一个屡获殊荣的开源项目，再到一个屡获殊荣的开源公司，我是看着Salt一步一步成长起来的。如今Salt已经成为一个极其强大的框架，这是我多年以来的梦想。
每天，我都在学习关于Salt的新知识。本书针对高级用户收集了部分此类东西。不要认为这本书涵盖的主题就是Salt的全部了。相反地，应该只把本书作为工具的指导手册，充分发挥其潜力。
通过阅读本书，我希望本书的想法和例子能激发你更新和创新你的基础设施。本书涵盖的内容
第1章，Salt概览，探讨了如何检阅一些基本原则和基本概念，以进入正确的思维框架中。尽管很多概念可能对熟练用户来说比较熟悉，但你同样可能会发现很多新的信息。
第2章，深入Salt内部，深入到Salt背后更深层次的工作原理。本章探讨了内部配置、加载器系统、渲染器，以及State编译器。
第3章，探索Salt SSH，探讨了Salt SSH这个强大的工具。它最近已经得到了许多核心开发者的青睐。这可能是Salt SSH最完整的相关讨论了。
第4章，异步管理任务，讨论了Salt背后最重要的概念之一，就是异步性。本章罗列的基本原理将会一直引用至本书剩余内容。
第5章，Salt Cloud进阶，不断深入，揭开Salt Cloud，它是普通用户转变成专家的必经之路。不论你使用了多少Salt Cloud的功能，都应该了解一下Salt Cloud。
第6章，使用Salt REST，探讨了REST服务的便利性。Salt REST使用Salt轻松绑定这些服务到你的基础设施。
第7章，理解RAET协议，教你RAET背后的概念，以及它们如何影响到你。RAET目前仍是新技术，但是已经找到了进入大型组织的方法。
第8章，扩展策略，讨论了你永远不应假设你的基础设施规模一直这么小。本章内容教你考虑在火烧眉毛之前如何正确扩展你的基础设施。
第9章，用Salt监控系统，讨论了如果你知道如何使用时，Salt是一个多么强大的监控工具。本章告诉你如何和已有的工具集成，或单独使用Salt。
第10章，探索最佳实践，探讨了使用任何工具的最佳和最差方式。本章教你如何以正确的方式使用Salt。
第11章，故障排查，告诉你当出问题时，应该去哪查，怎么寻求帮助。本书的学习方式
要执行本书的范例，你应该运行2015.5版本以上的Salt。只需要一台主机即可，因为salt-master和salt-minion服务可以在一台主机运行，但是目前需要Linux以运行salt-master服务。
如无特别说明，则本书的示例都是针对Ubuntu Linux的。本书的目标读者
本书非常适合那些管理服务器组，并希望了解如何添加新功能和扩展他们的工具集的专业人士。本书解释了一些Salt更先进的特性，也探索了如何使用这些特性为专业人士已经使用的工具带来额外的功能。本书约定
在本书中，你会发现很多不同种类的文本风格，用于区分不同种类的信息。下面是一些风格的范例和含义解释。
代码部分、数据库的表名、目录名、文件名、文件扩展名、路径名、假想URL、用户输入、Twitter handle像这样书写：“这个功能不过是test.ping命令而已。”
代码块以如下方式书写： nodegroups: webdev: 'I@role:web,G@cluster:dev' webqa: 'I@role:web,G@cluster:qa' webprod: 'I@role:web,G@cluster:prod'
任何命令行的输入或输出以如下方式书写： # salt -S 192.168.0.0/24 test.ping
新术语和重要字词以黑体方式书写。就如你看到的那样。比如，在菜单或对话框中，出现这样的文字：“点击将订阅并加入该组”。警告或重要标记将出现在这样的文本框中。小贴士和小技巧看起来像这样。下载示例代码
你可以从http://www.broadview.com.cn下载所有已购买的博文视点书籍的示例代码文件。勘误表
虽然我们已经尽力谨慎地确保内容的准确性，但错误仍然存在。如果你发现了书中的错误，包括正文和代码中的错误，请告诉我们，我们会非常感激。这样，你不仅帮助了其他读者，也帮助我们改进后续的出版。如发现任何勘误，可以在博文视点网站相应图书的页面提交勘误信息。一旦你找到的错误被证实，你提交的信息就会被接受，我们的网站也会发布这些勘误信息。你可以随时浏览图书页面，查看已发布的勘误信息。第1章Salt概览
Salt是一个强有力的自动化基础框架。在我们深入了解本书中的高级用法之前，有必要掌握一些要领。通过本章，你可以了解到以下内容。
• 远程执行。
• 基本的SLS文件树结构。
• 用于配置管理的State。
• Grain、Pillar及模板（template）基础。
在开始之前，你需要有一台已安装了常见的Linux发行版并具有root访问权限的设备。本书例子，除非有特殊说明，一般基于Ubuntu 14.04。当然，大部分例子都可以运行在其他主流的发行版上，如最新的Fedora、RHEL 5/6/7或Arch Linux版本。远程执行命令
Salt底层架构起源于远程执行命令的想法。这并不是一个新的概念，它所有的网络组件都是围绕着远程执行的一些部分设计的。就如同向一个Web服务器请求一个静态Web页面一样简单，或者如同在一个远程服务器上使用shell进行交互处理命令一样复杂。
说得直白点，Salt是众多复杂类型的远程执行的一个典型。但和大多数互联网用户使用的一次只能和一台服务器进行交互的工具不太一样（就他们所知道的而言），Salt允许用户直接在众多主机上运行命令。Master和Minion
Salt基于一主（Master）控制多从（Minion）的思想。通常是从Master上发送命令到一组Minion，然后执行命令中的既定任务，最后将执行结果返回到Master。Targeting Minion
salt命令首先要进行targeting。每个远程执行都需要指定一个匹配的target（即需要哪些Minion进行执行）。默认情况下，使用的target类型是glob（通配），这与大多数shell命令中参数的模式匹配风格一致。其他类型的targeting需要通过添加对应的选项（flag）进行指定。例如，想匹配一段特定子网中的一组主机，需要使用-S选项进行指定： # salt -S 192.168.0.0.24 test.ping
接下来我们将通过一些基本的使用例子来讲述一下常用的target类型。这里并没有覆盖所有的target类型，如Range以及其他超出本书范围的扩展等。当然，大多数常用的类型都能介绍到。Glob
Salt默认的target类型，因此它没有命令行选项。使用shell的通配符来指定一个或多个Minion ID。
在大多数命令shell中执行salt命令时，都需要保护通配符以避免被shell展开： # salt '＊' test.ping # salt \＊ test.ping
通过API或其他用户接口使用Salt时，通配符（＊）通常不需要引号和逃逸字符（\）保护。Perl语言兼容正则表达式（PCRE）
短选项：-E
长选项：--pcre
为了满足更复杂的匹配规则，可以使用Perl语言兼容性正则表达式（Perl Compatible Regular Expression, PCRE）。在早期的Salt版本中就包含了该targeting类型，也是在shell脚本中最常用的正则表达式。当然，也可以在salt命令行中使用PCRE的威力：[1] # salt -E '^[m|M]in.[e|o|u]n$' test.pinglist
短选项：-L
长选项：--list
该选项通过逗号分隔的列表来指定多个Minion。列表中的项不使用glob或正则表达式进行模式匹配，必须是显式声明的： # salt -L web1,web2,db1,proxy1 test.pingSubnet
短选项：-S
长选项：--ipcidr
通过指定一个IPv4地址或一个CIDR的IPv4子网来target Minion。 # salt -S 192.168.0.42 test.ping # salt -S 192.168.0.0/16 test.ping
截至2015.5版本，Salt还不能通过命令行选项来target IPv6地址。不过可以通过其他方式实现，比如通过Grain进行匹配。Grain
短选项：-G
长选项：--grain
Salt可以通过如操作系统、CPU架构以及自定义的信息（将在本章稍后进行详细描述）等机器特征进行target Minion。因为一些网络信息也存在于Grain中，所以IP地址也可使用该方式进行target。
由于Grain是键/值对（key/value pair），所以键名及值都必须指定，通过冒号（:）进行分隔： # salt -G 'os:Ubuntu' test.ping # salt -G 'os_family:Debian' test.ping
一些Grain是多级字典，可以通过冒号（:）进行分隔字典中的每一级键名： # salt -G 'ip_interfaces:eth0:192.168.11.38'
如果Grain含有冒号，同样需要指定，尽管这可能看上去很奇怪，如匹配本地IPv6地址（::1）。请注意冒号的数量： # salt -G 'ipv6:::1'Grain PCRE
短选项：无
长选项：--grain-pcre
通过Grain来匹配很高效，但如果想进行更复杂的grain匹配，可以使用grain pcre进行匹配： # salt --grain-pcre 'os:red(hat|flag)' test.pingPillar
短选项：-I
长选项：--pillar
Salt支持通过pillar数据进行匹配，Pillar的相关内容将在稍后进行描述，但就目前而言，我们认为它们和Grain一样即可。 # salt -I 'my_var:my_val' test.ping混合（Compound）
短选项：-C
长选项：--compound
混合target允许用户在一个shell命令中指定多种target类型。默认使用glob，想指定其他target类型，则需要在前面追加上类型简写和@符号。target简写GGrainEPCRE Minion IDPGrain PCREL列表（list）IPillarS子网/IP地址RSECO范围
如想匹配的系统是Ubuntu, Pillar中role的设置是web，且属于192.168.100.0/24子网的Minion： # salt -C 'G@os:Ubuntu,I@role:web,S@192.168.100.0/24' test.ping
布尔符号中的与（and）、或（or）及非（not）也可以在target类型中使用，如： # salt -C 'min＊ or ＊ion' test.ping # salt -C 'web＊ or ＊qa, G@os:Arch' test.ping节点组（Nodegroup）
短选项：-N
长选项：--nodegroup
节点组是在Salt内部使用的（所有的targeting终将创建一个动态节点组），从命令行中显式地指定节点组十分常用。在命令行使用前必须先在Salt Master的配置文件中以target列表进行定义（使用混合匹配语法），如在配置文件中进行如下定义： nodegroups: webdev: 'I@role:web,G@cluster:dev' webqa: 'I@role:web,G@cluster:qa' webprod: 'I@role:web,G@cluster:prod'
节点组定义完毕并重载Master配置文件后，可以通过salt进行target： # salt -N webdev test.ping运行模块方法
指定target后，接下来需要声明要运行的方法（function）。之前的例子中我们使用了test. ping方法，当然也可以指定其他方法。方法包含两部分，通过点（.）来分割： <模块名>.<方法>
在Salt命令中，模块方法紧随target其后，但也可以在最后给方法加任何参数： salt
如下salt命令，让所有的Minion返回“Hello world”字符串： salt '＊' test.echo 'Hello world'
Salt核心发行版内置了众多执行模块，并且将越来越多。在2015.5版本中，Salt内置的执行模块超过200个。这些模块并不能运行在所有的平台上，实际从设计上讲，有些模块需要用户自行解决依赖后才可以使用。
比方说，作为Salt测试的基本方法并对Minion可用，test模块中的所有方法均可以运行在所有的平台上。而Apache模块中的方法，则只能在Minion本地存在必须的命令时才能可用。
执行模块是Salt的基础组件，其他模块可以利用它们进行构建。由于执行模块的设计是使用命令行，因此需要给方法传递的参数通常是字符串。而一些参数可以来自于Salt的其他部分，在命令行中使用与Python格式类似的数据结构可以使用JSON字符串。
之所以这么设计也是有依据的，是因为Salt使用YAML作为其配置格式，而且所有的JSON格式都可以直接在YAML中使用。为了避免shell展开，需要在命令行中JSON外部使用单引号进行包裹，在字符串内部则使用双引号。如以下例子所示。
列表使用中括号声明： '["item1", "item2", "item3"]'
字典使用大括号声明： '{"key":"value", "key2":"value2", "key3":"value3"}'
列表中包含字典，字典中包含列表： '[{"key1":"value1"}, {"key2":"value2"}]' '{"list1": ["item1", "item2"], "list2": ["item3", "item4"]}'
以下模板是Salt的核心部分，每个模块中都包含一些常用方法。test.ping
这是Salt最基本的命令。最终它只要求Minion返回True。因为其足够简单，在文档中会常常见到，用于监测Minion是否可响应，而无法担心Minion的响应异常。如果没有响应，则并不一定意味着Minion宕掉，如由于某些原因导致Minion响应速度慢。不过，连续失败的话就要引起注意了。test.echo
该方法相比test.ping命令来说会用得少一些，它用于让Minion显示出传递给自己的字符串。还有一些其他的类似方法，如test.arg、test.kwarg、test.arg_type及test. arg_repr。test.sleep
稍微高级的测试场景，需要Minion先sleep若干秒后再返回True，常用于测试或验证任务系统。test.rand_sleep方法也非常实用，常用于在大规模Minion中进行发布并检查返回结果的测试场景。test.version
在大规模的Minion场景中，Minion间可能运行着不同的Salt版本。当在排错需要获取salt的具体版本时，它是最简单的获取方法，会返回每个Minion的Salt版本。如果想获取系统其他软件包的版本，可以使用pkg.version。pkg.install
Salt（2015.5）中的每一种包管理器都支持安装软件包功能。该方法只需要指定一个软件包名，或者指定一组软件包，甚至可以指定具体的版本。当使用执行模块时，可能只需要指定软件包名就够了，但在State模块中（稍后会做详细描述），高级的用法会更重要。pkg.remove
与pkg.install方法搭配使用，用于指定卸载哪个软件包。不过因为卸载软件包时，软件包版本变得不那么重要，因此它的用法非常简单。它允许用Python的列表（使用pkgs参数）来一次性卸载若干软件包。如果在命令行中，则可以使用JSON字符串。file.replace
sed命令是一个UNIX系统中常用的管理员工具，常用于处理包括编辑文件中的特定行、搜索和替换等任务。Salt做过一些类似于sed命令行的尝试。最先是file.sed方法，它是一个简单的UNIX sed命令的封装。file.psed方法则提供了一个基于Python的替代方案。然而sed不仅仅是个查找/替换的工具，它是一门完整的语言，如果不正确使用，将会碰到问题。因此Salt决定开发file.replace方法，只用于满足大多数用户的查找/替换需求，规避sed封装中的差异性问题。其他文件类操作方法
一系列通用UNIX命令逐步加入到file方法中，用于管理文件及它们的元数据信息，如：file.chown、file.chgrp、file.get_mode、file.set_mode、file.link、file. symlink、file.rename、file.copy、file.move、file.remove、file.mkdir、file. makedirs、file.mknod等。用户及用户组管理方法
Salt中也包含大多数UNIX中用于管理用户及用户组的工具，如user.add、user.delete、user.info、group.add、group.delete、group.info、user.chuid、user.chgid、user.chshell、user.chhome、user.chgroups等。sys.doc
在设计时，每一个执行模块中的公共方法都必须包含自述文档。自述文档是在方法顶部下方的一段注释，里边包含该方法的用途，以及至少一个命令行实例。
可以使用sys.doc方法来查看Minion端的这些文档。如果没有其他参数，则将在一个Minion中显示所有方法的文档内容。如果指定了模块名字，将显示该模块中所有方法的文档内容。如果也指定了方法的名字，则只显示该方法的文档内容。它常用于查询在一个有效的模块中如何使用这些方法。SLS文件树
Salt中的一些子系统需要使用SLS文件树，最常见的是用于Salt State的/srv/salt，其次是Pillar系统的/srv/pillar，它们之间的文件格式不同，但目录结构相同。接下来我们将讲述如何存放这些目录。SLS文件
SLS指代SaLt State，在Salt中首先会用到这种类型文件的结构。尽管它们可以用不同的格式进行渲染，但就目前而言默认的YAML格式是最常用的。多种模板引擎同样可以用于生成YAML（或其他数据结构），同样地，最流行的是默认的模板引擎Jinja。
请记住，Salt和数据息息相关。YAML是Python中指代字典类型数据结构的序列化格式。说到SLS文件如何设计时，只需要记住它们是一组键/值对：每项都有一个唯一的键，引用一个值。值可以是一个单项、一个列表项，也可以是其他的键/值对。
在SLS文件中每个小节（stanza）的key称为ID。如果小节内没有显式声明name属性，那么ID会作为name。记住ID必须全局唯一，重复的ID会报错。使用top文件将配置绑定在一起
State和Pillar系统中，都有一个名为top.sls的文件，用于将SLS文件拉在一起并指定在哪个环境下应该为Minion提供哪些SLS文件。
top.sls文件中的每个key都定义一个环境（environment），一般情况下，定义一个叫作base的环境，此环境包含基础设施中所有的Minion，定义其他环境只包含Minion的子集。每个环境中包含一组SLS文件。来看看下面这个top.sls文件的内容： base: '＊': - common - vim qa: '＊_qa': - jenkins web: 'web_＊': - apache2
在这个top.sls中，声明了3个环境，分别是base、qa和web。base环境指定所有Minion执行common和vim State。qa环境指定所有以_qa结尾ID的Minion执行jenkins State。web环境指定所有以web_开头ID的Minion执行apache2 State。SLS目录组织
SLS文件的名字可以是SLS文件本身的文件名（如apache2.sls），也可以是有init. sls文件在内的目录名（如apache2/init.sls）。注意执行时会首先搜索apache2.sls，如果不存在，才会使用apache2/init.sls。
SLS文件可以有多层深度，目录层级深度并没有限制。当定义多层深度目录结构时，每一个层级将在SLS名后追加句点（如apache2/sls/init.sls对应的是apache2.ssl）。一个好的实践是保持目录结构尽量浅显，这样用户就能通过SLS树快速找到所需要的东西。使用State进行配置管理
/srv/salt目录下的文件用于定义Salt State。这是配置管理格式，用来强制Minion处于某一状态（State）:X软件包（package）需要安装，文件（file）Y格式正确，服务（service）Z开机自启并处于运行状态等，如下： apache2: pkg: - installed service: - running file: - managed - name: /etc/apache2/apache2.conf
State可能保存在单个SLS文件中，但更好的做法是按照你或你的组织约定的规范，把这些State分开写入不同的文件中。SLS文件可以通过include块引用其他的SLS文件。使用include块
在大的SLS树中，一个SLS文件引用其他SLS文件非常常见。通过使用include块实现，通常放在SLS文件顶部： include: - base - emacs
在本例中，SLS文件将include块内容替换为base.sls（或者base/init.sls）及emacs. sls（或者emacs/init.sls）的内容。对于用户来讲会有一些限制。最重要的限制是，SLS文件中不能包含已存在于include的SLS文件中的ID。
另外需要注意的是，include本身作为一个顶级声明（top-level declaration），不允许在同一个文件中出现多次。下边的书写是错误的： include: - base include: - emacs使用requisite排序
State SLS文件具有声明式（declarative）和命令式（imperative）特性，在所有配置管理系统格式中是独一无二的。说State SLS文件是命令式的，因为每个State的评估顺序是按照它在SLS文件中出现的位置排序的。说它们又是声明式的，因为State可以通过requisite来更改它们实际执行时的顺序。例如： web_service: service.running: - name: apache2 - require: - pkg: web_package web_package: pkg.installed: - name: apache2
如果服务在声明时通过require指定了SLS文件中在它之后的软件包，则pkg State会首先执行。如果没有声明依赖，由于服务代码块在pkg代码块之前，所以Salt会在安装软件包之前先尝试启动服务。它的执行过程与下面的State执行过程一致： web_service: service.running: - name: apache2 web_package: pkg.installed: - name: apache2
requisite指向SLS文件中其他位置的项目列表将影响State的执行行为。列表中的每一项包含两个部分：模块名字和相关State ID。
下边是Salt State和Salt其他部分中State编译器可以支持的requisite列表。require
require是最基本的requisite，它表示State会等待列表中定义的每一项State都成功执行后才会执行。例如下面的例子： apache2: pkg: - installed - require - file: apache2 service: - running - require: - pkg: apache2 file: - managed - name: /etc/apache2/apache2.conf - source: salt://apache2/apache2.conf
在这个例子中，文件会首先复制到Minion上，然后进行软件包的安装，之后再进行服务的启动。显而易见的是，服务只有在提供该服务的软件包安装后才能启动。但是基于Debian的操作系统，如Ubuntu，会在软件包安装后自动启动服务，如果默认配置文件并非所需时，会有问题。因此该State会确保在安装Apache之前先配置正确。watch
在之前的例子中，新的Minion在第一次运行State时就能配置正确。但是如果之后配置文件发生了变更，apache2服务需要重启才行。这时可以在service中添加watch requisite，强制State在发现它watch的项目发生了变更时执行一个指定的动作。 apache2: ...SNIP... service: - running - require: - pkg: apache2 - watch: - file: apache2 ...SNIP...
watch requisite并不是对所有State模块类型都有效。这是因为它需要执行的指定动作依赖于模块类型。如之前的例子中，当一个服务通过watch触发时，如果服务此时是关闭的，则Salt会尝试启动它。如果服务已经在运行中，则Salt会根据情况尝试service.reload、service.full_restart或service.restart中的一个。
截至2015.5版本，支持watch requisite的State模块有：service、cmd、event、module、mount、supervisord、docker、tomcat和test。onchanges
onchanges requisite和watch有点类似，但它并不需要使用它的State模块的任何特殊支持。只有当State成功完成并且有变化发生时，那些onchanges关联到的列表项才会执行。onfail
在简单的State树中，onfail requisite很少使用。但在一个更高级的State树中，如出现问题需要告警给用户或自动进行正确处理时，则需要使用onfail。当一个State已评估并且执行失败时，那些onfail关联到的列表项才会进行评估。假设PagerDuty服务已经通过Salt进行了正确的配置，并且apache_failure State已经用到了该服务，那么下面的State会在Apache启动失败时通知运维团队： apache2: service: - running - onfail - pagerduty: apache_failureuse
在Salt中，是可以在一个State中声明一些默认值的，然后其他的State可以继承（inherit）这些默认值。最常见的是一个State文件通过include语法去引用其他文件。
如果State中使用的项已经重新声明了，那么就会被新值覆盖。否则，该项在使用时并不会进行任何修改。使用use的State并不会将requisite继承过来，只会继承非requisite选项。如下面的SLS, mysql_conf State会安全地从apache2_conf State中继承user、group及mode，并且不会触发Apache重启： apache2_conf: file: - managed - name: /etc/apache2/apache2.conf - user: root - group: root - mode: 755 - watch_in: - service: apache2 mysql_conf: file: - managed - name: /etc/mysql/my.cnf - use: - file: apache2_conf - watch_in: - service: mysqlprereq
在某些情况下，有可能State并不需要运行，只有在另一个State预计会变更时才需要运行。例如一个Web应用使用Apache来提供服务，当产品服务器上的代码库需要变更时，Apache应该先关闭，以免代码没部署完时会有错误。
prereq requisite就是针对这样的需求设计的。当一个State使用prereq时，Salt会先对prereq中指定关联的项目运行test模式来预计是否会进行变更。如果预计有变更，则Salt会用prereg标记该State需要执行。 apache2: service: - running - watch: - file: codebase codebase: file: - recurse ...SNIP... shutdown_apache: service: - dead - name: apache2 - prereq: - file: codebase
在这个例子中，shutdown_apache State只会在codebase State报告需要有变化时进行变更。如果有变化，Apache会进行关闭，然后codebase State会执行。一旦执行完成，它会触发apache2的service State，再次启动Apache。反转requisite
之前提到的requisite都可以通过在最后添加_in的方式进行反转。例如，不是State X requiring State Y，而是声明State X is required by State Y，可以按照如下方式写： apache2: pkg: - installed - require_in: - service: apache2 service: - running
添加每个State的反转看起来有点模糊，但实际上它在include块中是一个很好的用例。
SLS文件不能使用requisite指向文件内部不存在的代码。而使用include块会将其他SLS文件中的内容导入该SLS文件。因此一般情况下在一个SLS文件中定义好配置，在其他SLS文件中include，并通过use_in requisite修改使更具有更多的特性。扩展SLS文件
除了include块之外，State SLS文件还可以使用extend块来修改include块引入的SLS文件的内容。使用extend代码块和使用requisite类似，但还是有一些明显的不同。
use或use_in requisite会复制默认值到另外的State中或从其他State上复制默认值到本State中，extend块则只能对引入的State进行修改。 # cat/srv/generic_apache/init.sls apache2_conf: file: - managed: - name: /etc/apache2/apache2.conf - source: salt://apache2/apache2.conf (In django_server/init.sls) include: - generic_apache extend: apache2_conf: - file: - source: salt://django/apache2.conf (In image_server/init.sls) include: - generic_apache extend: apache2_conf: - file: - source: salt://django/apache2.conf
本例中使用的通用（generic）Apache配置文件，会被Django服务器或Web图片服务器覆盖。Grain、Pillar及模板基础
Grain和Pillar提供了一种允许在Minion中使用用户自定义变量的方案。模板则为这些变量提供在Minion上创建文件的更高级用法。
在详细了解之前，先让我们记住下边的内容：Grain定义在指定的Minion上，而Pillar则定义在Master上。它们都可以通过静态（statically）或动态（dynamically）的方式进行定义（本书主要介绍静态方式），但是Grain常用于提供不常修改的数据，至少是不重启Minion就不会变，而Pillar更倾向于动态数据。使用Grain来获取Minion特征数据
Grain在设计之初用于描述Minion的静态要素，执行模块能够使用它来判断应该如何执行。例如，当os_family的Grain数据为Debian时，则会使用apt工具组件来进行软件包管理，当os_family为RedHat时则使用yum来进行软件包管理。
Salt会自动发现很多Grain数据，像os、os_family、saltversion及pythonversion等Grain通常总是可用的。而像shell、systemd及ps等Grain并不总是可用的，比如Windows Minion就没这些。
Grain会在Minion进程启动时进行加载，并缓存在内存中。这样salt-minion进程就无须每次操作都重新检索系统来获取Grain，极大地提升了Minion的性能。这对Salt来讲是必需的，因为Salt设计的目的是快速执行任务，而不是每次执行都等待很长时间。
可以通过grains.items方法来查看Minion都有哪些Grain数据： salt myminion grains.items
想查看某个特定的Grain，可以将对应的名字作为参数传递给grains.item： salt myminion grains.item os_family
同样可以自定义Grain。在以前的版本，是在Minion的配置文件（Linux和一些UNIX平台对应的路径是/etc/salt/minion）中定义静态的Grain数据： grains: foo: bar baz: qux
这种做法至今依然可用，但已不建议使用。现在更常用的方法是将自定义的静态Grain存放在一个叫作Grain的文件中（在Linux和一些UNIX平台对应的路径是/etc/salt/grains）。这么做的好处是：
• Grain独立存储，易于在本地查找。
• Grain能够通过Grain执行模块进行修改。
第二点是非常重要的：Minion的配置文件设计允许用户级注释，而Grain文件设计用于Salt按需进行重写。手动编辑Grain文件也是没问题的，但不要期望能在内容中保留注释。除了不包括Grain的顶级声明外，Grain文件和在Minion文件中的Grain配置看起来一样： foo: bar baz: qux
需要在Grain文件中添加或修改Grain时，可以使用grains.setval方法： salt myminion grains.setval mygrain 'This is the content of mygrain'
Grain的值支持多种类型。大多数Grain只包含字符串，但也可能包含列表： my_items: - item1 - item2
想对该列表添加项目（item）时，可以使用grains.append方法： salt myminion grains.append my_items item3
想从Grain文件中移除一个Grain，可以使用grains.delval方法： salt myminion grains.delval my_items使用Pillar使变量集中化
在大多数场景中，Pillar的表现行为和Grain一致，但有个很大的区别是：Pillar在Master上进行定义，存在于一个集中化的路径。默认情况下，在Linux主机上对应的目录是/srv/pillar/。由于该区域存放的是用于众多Minion的信息，因此需要一种target方式来对应Minion。正因为如此，使用了SLS文件。
Pillar的top.sls文件在配置和功能上和State的top.sls文件一致：首先声明一个环境，然后是一个target，最后是该target需要使用的SLS文件列表： base: '＊': - bash
Pillar的SLS文件相对于State的SLS文件要简单许多，这是因为Pillar只用于提供静态的数据存储。以键值对（key/value pair）的方式进行定义，有时会包含一定的层级： skel_dir: /etc/skel/ role: web web_content: images: - jpg - png - gif scripts: - css - js
和State的SLS文件相似，Pillar SLS文件也可以通过include来引用其他Pillar SLS文件。 include: - users
想查看所有Pillar数据，可以使用pillar.items方法： salt myminion pillar.items
需要注意的是，当运行该命令时，默认情况下Master的配置数据也会以名为Master的Pillar项显示出来。如果Master配置文件中包含一些敏感数据，这么做会有问题。可以在Master的配置文件中添加如下内容来关闭它的输出： pillar_opts: False
这里需要说一下，除了Master配置数据外，Pillar数据只能被特定的target Minion看到。换句话说，没有Minion允许访问其他Minion的Pillar数据，至少在默认情况下是这样的。Salt中是允许Minion使用Peer系统来执行Master命令的，不过Peer系统的内容在本章中不做过多的描述。通过模板动态管理文件
Salt可以使用模板，结合Grain和Pillar数据，使State系统变得更动态。当前（2015.5版本）支持如下模板引擎。
• jinja
• mako
• wempy
• cheetah
• genshi
通过Salt的渲染器系统（rendering system）使用这些引擎。以上
试读结束[说明：试读内容隐藏了图片]