简单，简洁，简洁
许多最强大和最有用的工程解决方案都建立在简单的原则之上。 Salt State努力做到这一点：K.I.S.S （Keep It Stupidly Simple）。
Salt State系统的核心是SLS或SaLt State文件。 SLS表示系统应处于的状态，并设置为使用一种简单的格式包含此数据。 这通常称为配置管理。
注：这只是学习使用state状态的开始，请务必仔细阅读
Pillar next
。
您也可以参考github上相同的一份技术资料：
HOW DO I USE SALT STATES?
IT IS ALL JUST DATA
在深入研究细节之前，理解SLS文件只是一个数据结构会有帮助。 虽然理解SLS只是一种数据结构对于理解和利用Salt States并不重要，但它应该有助于增强对实际功能如何发挥作用的了解。
SLS文件实际上只是字典、列表、字符串和数字。 通过使用这种方法，Salt可以更加灵活。 当一个人写入更多的状态文件时，它就会更清楚地写出正在编写的内容。 结果会是一个易于理解的系统，但随着管理员或开发人员的需求而增长。
THE TOP FILE
可以使用名为top.sls的文件将以下部分中的示例SLS文件分配给主机。 需要深入了解此文件，可以参照
这里
。
DEFAULT DATA – YAML
默认情况下，Salt代表SLS数据，它是最简单的可用序列化格式之一–YAML。
典型的SLS文件在YAML中通常如下所示：
注： 这些演示使用一些通用服务和包名称，不同的发行版通常对包和服务使用不同的名称。 例如，在Red Hat系统上应该用httpd替换apache。 Salt使用init脚本的名称、systemd名称、upstart名称等基于平台的底层服务管理。 要获取平台上可用服务名称的列表，请执行service.get_all salt函数。
有关如何使状态与多个发行版一起工作的信息将在本教程的后面部分中介绍。
apache:
pkg.installed: []
service.running:
- require:
- pkg: apache
此SLS数据将确保安装名为apache的程序包，并确保apache服务正在运行。 下面对各组件做简单的解释。
- 第一行是一组数据的ID，称为ID声明。 此ID设置的是需要操作的事物的名称。
-
第二行和第三行包含要运行的状态模块函数，格式为
<state_module>.<function>
。
pkg.installed
状态模块功能可确保通过系统的本机程序包管理器安装软件包。
service.running
状态模块函数确保给定的系统守护程序正在运行。 -
最后，在第四行，是单词
require
。 这称为必需语句，它确保仅在成功安装apache包后才启动Apache服务。
ADDING CONFIGS AND USERS
在设置Apache Web服务器之类的服务时，可能需要添加更多组件。 比如很可能会管理Apache配置文件，并且可能需要设置用户和组。
apache:
pkg.installed: []
service.running:
- watch:
- pkg: apache
- file: /etc/httpd/conf/httpd.conf
- user: apache
user.present:
- uid: 87
- gid: 87
- home: /var/www/html
- shell: /bin/nologin
- require:
- group: apache
group.present:
- gid: 87
- require:
- pkg: apache
/etc/httpd/conf/httpd.conf:
file.managed:
- source: salt://apache/httpd.conf
- user: root
- group: root
- mode: 644
此SLS数据极大地扩展了第一个示例，并包括了一个配置文件、一个用户一个用户组和一个新的必需条件关键词：
watch
。
添加更多状态很容易，因为新的用户和组状态在Apache ID下，用户和组将是Apache用户和组。 require语句将确保只在组之后创建用户，并且只有在安装Apache软件包之后才会创建该组。
接下来，服务中的
require
语句被更改为
watch
，现在正在观看3个状态而不是仅仅一个状态。 watch语句与require相同，确保在使用watch运行状态之前运行其他状态，但它会添加一个额外的组件。 watch语句将运行状态的观察器功能，以便观察对状态进行的任何更改。因此，如果更新了包、更改了配置文件或者修改了用户uid，那么将运行服务状态的观察程序。在这里服务状态的观察者只是重新启动服务，因此在这种情况下，配置文件的更改将触发相应服务的重新启动。
MOVING BEYOND A SINGLE SLS
以可扩展的方式设置Salt States时，需要使用多个SLS文件。 上面的示例位于单个SLS文件中，但可以组合两个或多个SLS文件来构建状态树。 上面的例子还引用了一个带有奇怪源文件路径的文件 –
salt://apache/httpd.conf
。 该文件也需要提供。
SLS文件布局在Salt master的目录结构中; SLS只是一个文件，要下载的文件也都只是文件。
Apache示例将在Salt文件服务器的根目录中像下面这样布局，如下所示：
apache/init.sls
apache/httpd.conf
所以httpd.conf只是apache目录中的一个直接引用的文件。
注意：不要在SLS文件名或其目录中使用
.
的字符。top.sls和Include声明的初始实现遵循python导入模型，其中斜杠表示为句点。 这意味着无法在引用名称中使用带有句点的SLS文件（除了后缀句点）。 例如，webserver_1.0.sls不可引用，因为webserver_1.0将会去尝试引用配置目录/文件webserver_1/0.sls 。
这同样适用于任何子目录，这在创建git repos时特别“棘手”。 另一个通常无法正常呈现输出的命令是包含点的路径中文件的
state.show_sls
。
但是，当使用多个单个SLS文件时，可以将更多组件添加到工具箱中。 看下这个SSH示例：
ssh/init.sls:
openssh-client:
pkg.installed
/etc/ssh/ssh_config:
file.managed:
- user: root
- group: root
- mode: 644
- source: salt://ssh/ssh_config
- require:
- pkg: openssh-client
ssh/server.sls:
include:
- ssh
openssh-server:
pkg.installed
sshd:
service.running:
- require:
- pkg: openssh-client
- pkg: openssh-server
- file: /etc/ssh/banner
- file: /etc/ssh/sshd_config
/etc/ssh/sshd_config:
file.managed:
- user: root
- group: root
- mode: 644
- source: salt://ssh/sshd_config
- require:
- pkg: openssh-server
/etc/ssh/banner:
file:
- managed
- user: root
- group: root
- mode: 644
- source: salt://ssh/banner
- require:
- pkg: openssh-server
请注意，我们使用了两种类似的方式表示文件由Salt管理。 在上面的/etc/ssh/sshd_config状态部分中，我们使用
file.managed
状态声明，而使用/etc/ssh/banner状态部分，我们使用文件状态声明并向该状态声明添加托管属性。 两种方式都产生相同的结果; 第一种方式使用file.managed会更加简洁一些。
现在我们的State Tree看起来像这样：
apache/init.sls
apache/httpd.conf
ssh/init.sls
ssh/server.sls
ssh/banner
ssh/ssh_config
ssh/sshd_config
此示例中引入了
include
语句。 include语句用于包含另一个SLS文件，在其中找到的组件同样可以被required、watched或者extended。
include语句允许状态跨链接引用。 当SLS具有include语句时，它实际上会被扩展为包括所包含的SLS文件的内容。
请注意，某些SLS文件称为init.sls，而其他文件则不称为init.sls。 有关这意味着什么的更多信息可以在
States Tutorial
中找到。
EXTENDING INCLUDED SLS DATA
有时需要扩展SLS数据。 也许apache服务需要观察额外的资源，或者在某些情况下需要放置不同的文件。
在这些示例中，第一个将向ssh添加自定义banner，第二个将向apache添加更多观察者以包含mod_python。
ssh/custom-server.sls:
include:
- ssh.server
extend:
/etc/ssh/banner:
file:
- source: salt://ssh/custom-banner
python/mod_python.sls:
include:
- apache
extend:
apache:
service:
- watch:
- pkg: mod_python
mod_python:
pkg.installed
custom-server.sls
文件使用extend语句覆盖下载banner配置文件的位置，从而更改用于配置banner的文件。
在新的mod_python SLS中添加了mod_python包，但更重要的是扩展了apache服务以观察mod_python包。
Using extend with require or watch
extend语句中require或watch的工作方式不同。 它采取附加而不是替换必需的组件。
UNDERSTANDING THE RENDER SYSTEM
由于SLS数据只是数据，因此不需要用YAML表示。 Salt默认为YAML，因为它非常简单易学，易于使用。但是，只要提供了渲染器模块，就可以从几乎任何可以想象的介质渲染SLS文件。
默认渲染系统是
jinja|yaml
渲染器。
jinja|yaml
渲染器将首先通过Jinja2模板系统传递模板，然后通过YAML解析器。这样做的好处是在创建SLS文件时可以使用完整的编程结构。
其他可用的渲染器是
yaml_mako
和
yaml_wempy
，它们分别使用
Mako
或
Wempy
模板系统而不是jinja模板系统，更值得注意的是纯Python或
py
，
pydsl
和
pyobjects
渲染器。
py
渲染器允许用纯Python编写SLS文件，在准备SLS数据时允许最大程度的灵活性和功能;而
pydsl
渲染器提供了一种灵活的，特定于域的语言，用于在Python中创建SLS数据;
pyobjects
渲染器为你提供了一个建立状态数据的“
Pythonic
”界面。
注意：上述模板引擎不仅可用于SLS文件。它们还可以用于
file.managed
状态中，使文件管理更加动态和灵活。有关在托管文件中使用模板的一些示例，请参阅
文件状态的文档
以及下面的MooseFS示例。
GETTING TO KNOW THE DEFAULT – JINJA|YAML
默认渲染器 –
jinja|yaml
允许使用jinja模板系统。 可以在这里找到Jinja模板系统的指南：
http://jinja.pocoo.org/docs
使用渲染器时，会传入一些非常有用的数据。对于基于模板引擎的渲染器，可以使用三个关键组件，salt, grains和pillar。
salt
对象允许从模板中调用任何Salt函数，而
grains
允许从模板中访问Grains。 几个例子：
apache/init.sls:
apache:
pkg.installed:
{% if grains['os'] == 'RedHat'%}
- name: httpd
{% endif %}
service.running:
{% if grains['os'] == 'RedHat'%}
- name: httpd
{% endif %}
- watch:
- pkg: apache
- file: /etc/httpd/conf/httpd.conf
- user: apache
user.present:
- uid: 87
- gid: 87
- home: /var/www/html
- shell: /bin/nologin
- require:
- group: apache
group.present:
- gid: 87
- require:
- pkg: apache
/etc/httpd/conf/httpd.conf:
file.managed:
- source: salt://apache/httpd.conf
- user: root
- group: root
- mode: 644
这个例子很简单。 如果
os
grain声明的操作系统是Red Hat，那么Apache包和服务的名称需要是httpd。
下面是一个更积极的使用Jinja的方法，在一个模块中设置一个MooseFS分布式文件系统块服务器：
moosefs/chunk.sls:
include:
- moosefs
{% for mnt in salt['cmd.run']('ls /dev/data/moose*').split() %}
/mnt/moose{{ mnt[-1] }}:
mount.mounted:
- device: {{ mnt }}
- fstype: xfs
- mkmnt: True
file.directory:
- user: mfs
- group: mfs
- require:
- user: mfs
- group: mfs
{% endfor %}
/etc/mfshdd.cfg:
file.managed:
- source: salt://moosefs/mfshdd.cfg
- user: root
- group: root
- mode: 644
- template: jinja
- require:
- pkg: mfs-chunkserver
/etc/mfschunkserver.cfg:
file.managed:
- source: salt://moosefs/mfschunkserver.cfg
- user: root
- group: root
- mode: 644
- template: jinja
- require:
- pkg: mfs-chunkserver
mfs-chunkserver:
pkg.installed: []
mfschunkserver:
service.running:
- require:
{% for mnt in salt['cmd.run']('ls /dev/data/moose*') %}
- mount: /mnt/moose{{ mnt[-1] }}
- file: /mnt/moose{{ mnt[-1] }}
{% endfor %}
- file: /etc/mfschunkserver.cfg
- file: /etc/mfshdd.cfg
- file: /var/lib/mfs
这个例子展示了Jinja的更多可用功能。 多个for循环用于动态检测可用的硬盘驱动器并将它们设置为挂载状态，并且多次使用salt对象调用shell命令来收集数据。
INTRODUCING THE PYTHON, PYDSL, AND THE PYOBJECTS RENDERERS
有时，所选的默认渲染器可能没有足够的逻辑能力来完成所需的任务。 发生这种情况时，可以使用Python渲染器。 通常，YAML渲染器可以用于大多数SLS文件，但是设置为使用其他渲染器的SLS文件也可以轻松添加到树中。
下面是一个非常基本的Python SLS示例文件：
python/django.sls:
#!py
def run():
'''
Install the django package
'''
return {'include': ['python'],
'django': {'pkg': ['installed']}}
这是一个非常简单的例子; 第一行有一个
#!py
，它告诉Salt不使用默认渲染器，而是使用
py
渲染器。 然后定义run函数，run函数的返回值必须是Salt友好的数据结构，或者更好地称为
Salt HighState
数据结构。
或者，使用
pydsl
渲染器，上面的示例可以更简洁地编写为：
#!pydsl
include('python', delayed=True)
state('django').pkg.installed()
pyobjects
渲染器提供了一种基于“
Pythonic
”对象的方法来构建状态数据。 上面的例子可以写成：
#!pyobjects
include('python')
Pkg.installed("django")
如果它们是用YAML编写的，那么这些Python示例将如下所示：
include:
- python
django:
pkg.installed
这个例子清楚地说明了: 一、默认情况下使用YAML渲染器是一个明智的决定；二、可以通过使用纯Python SLS在需要的地方获得无限制的功能。
RUNNING AND DEBUGGING SALT STATES
一旦SLS中的规则准备就绪，就应对其进行测试以确保它们正常工作。 要调用这些规则，只需在命令行上执行
salt '*' state.apply
。 如果执行后只返回了主机名，但是没有返回数据，则可能是一个或多个sls文件出现问题。 在minion上，使用salt-call命令检查错误输出：
salt-call state.apply -l debug
这应该有助于解决问题。
通过运行
salt-minion -l debug
，也可以在调试模式下在前台启动minion，帮助调试问题。
NEXT READING
了解states状态后，下一个建议是熟悉Salt的pillar接口：