saltsatck的使用

1.Grains模块

https://docs.saltproject.io/salt/user-guide/en/latest/topics/grains.html

grains模块是获取minions的系统属性的，如操作系统、域名、IP地址、内核、操作系统类型、内存和许多其他系统属性。

1.1列出grains

#可用的grains可以通过使用grains.ls模块列出:
salt '*' grains.ls
#grains数据可以使用grains.items模块列出:
salt '*' grains.items

1.2目标grains

grains数据可以用作遴选目标minions，通过使用salt -G 'xx'进行遴选，在''中还可以使用通配符进行匹配

#选择系统为Centos的minions执行test.version查看minions的salt版本
salt -G 'os:CentOS' test.version
#选择x86_64的minions执行grains.item num_cpus查看其cpu个数
salt -G 'cpuarch:x86_64' grains.item num_cpus
#还可以使用通配符进行匹配，并且可以通过为遍历的每个级别添加冒号来匹配嵌套在字典中的grains。下面的命令将匹配具有名为ec2_tags grains的主机，该grains本身是一个字典，键名为environment，其值包含单词production:
salt -G 'ec2_tags:environment:*production*'

1.3配置master自动接收具有某些grains的minions

#1.在master配置文件/etc/salt/master.d/grains.conf中配置自动接受minions的grains的目录
vim /etc/salt/master.d/grains.conf
autosign_grains_dir: /etc/salt/autosign_grains
#2.在/etc/salt/autosign_grains/uuid中配置自动接受minions的uuid值
vim /etc/salt/autosign_grains/uuid
8f7d68e2-30c5-40c6-b84a-df7e978a03ee
1d3c5473-1fbc-479e-b0c7-877705a0730f
#3.在minions的配置文件/etc/salt/minion中配置运行自动注册的grains为uuid
vim /etc/salt/minion
autosign_grains:
  - uuid

salt-call state.apply 命令用于在 Salt Minion 上执行配置状态（states），它是通过 Salt Minion 本地模式执行，执行 salt-call state.apply 命令，会将 Minion 上的所有配置状态应用到系统中，配置状态（states）是一组定义在 SaltStack 系统中的 YAML 文件，用于描述和管理系统的配置和状态。也可以指定特定的配置状态进行部署，例如 salt-call state.apply apache 表示执行名为 apache 的配置状态。

1.4定义自定义grains

#1.在执行远程命令时定义
#定义grains值deployment为datacenter4
salt minion01 grains.setval deployment datacenter4
#定义多值的grains roles为roles ['web', 'app1', 'dev']
salt minion01 grains.setval roles ['web', 'app1', 'dev']

在执行以上命令后，自定义的grains将在对应的主机的/etc/salt/grains中自动添加。如果手动在/etc/salt/grains中添加自定义变量，那么这个主机的grains动态更新，在master中也可以直接调用这个grains。这种为动态添加，静态添加grains的方式为在/etc/salt/minion.d/下添加如/etc/salt/minion.d/grains.conf文件中添加以下配置，但是这种需要重新minions才能生效。

grains:
  deployment: datacenter4
  cabinet: 14
  switch_port: 4
  roles:
    - web
    - app1
    - dev

通过自定义grains进行主机匹配

salt -G 'roles:app1' test.ping

grains可以是任何常见的数据结构:字符串、整型、列表、布尔或字典。

系统自带的核心grains可以被改写，优先级从低到高为：

1.默认salt定义的核心grains。
2在/etc/salt/grains中自定义grains。
3.在/etc/salt/minion中自定义。
4.在master服务器的_grains目录中自定义grain模块，并同步到从属服务器。

1.5grains的状态

#grains字典使minion的grains直接可用：
{{ grains['os'] }}
#grains.get函数可以编译更深的grains并且设置默认值
{{ salt['grains.get']('os') }}
{{ salt['grains.get']('os', ‘Debian’) }}

2.幕后的状态系统

2.1状态系统处理

salt状态执行的阶段包括：渲染，编译，运行时

2.2渲染状态

渲染时间就是在渲染引擎使用的时间，顶层文件和SLS文件被转换成原始的未被定义的高数据，状态执行的过程从执行高状态开始。

2.2.1高状态

直接调用SLS从逻辑上分配应该从调用minions的上下文中执行的状态。高状态层用于允许将要执行的内容与来自主服务器的一个或多个仆从绑定在一起的完整上下文分配。这意味着minions的环境以及与该minions相关的所有相关执行数据都可以从master服务器分配，而无需在目标minions上执行或配置任何内容。这也意味着minions可以独立地从master那里获取有关其完整配置的信息

2.2.2top文件

在Salt中，包含网络上机器组之间的映射以及应该应用于它们的配置角色的文件称为top文件。top文件都从master服务器进行下载。

来自各个环境的top文件被下载然后通过渲染接口，topfile被渲染，topfile可以被多种渲染器渲染如Jinja和YAML。

调用maste_tops函数。这个函数需要来自master的top插件接口。master评估所有配置的master top插件接口。

这个插件接口允许在数据库或者通过工具来存储top文件信息。启动状态过程需要这个top文件生成的第一个例程。

2.2.3匹配测试

匹配字典包含开始收集SLS索引的所有必须数据，原始匹配字典会是下面这个格式的变体

{'base': ['dns', 'dns.bind-utils','core', 'httpd', 'edit']}

当调用state.sls，根据SLS引用和作为参数发送给函数的环境名生成匹配字典。如上文base为环境名。

2.2.4SLS渲染和模板

1.任何一个SLS文件被渲染，并返回单个文件的原始的高数据。默认的渲染器是Jinja + YAML渲染器。

2.此时，文件渲染序列中的模板都被执行。这意味着在任何状态开始执行之前，所有对Salt函数的引用都被解析了。

3.在SLS索引被下载和渲染时，各自的数据被整合在一个单独的Python字典中，这个字典将会被进一步被处理。

一个SLS文件或top文件被渲染成jinja+yaml格式的高数据，然后经过编译成低数据，然后通过进行时变成低数据块。

下面的状态片段是用YAML编写的，使用Jinja模板表达式来获得os_family的grain:

named_conf:
  file.managed:
    - source: salt://dns/files/{{grains['os_family']}}-named.conf
    - name: /etc/named.conf

如果以下状态呈现在RedHat minion上，那么它将被转换为:

named_conf:
  file.managed:
    - source: salt://dns/files/RedHat-named.conf
    - name: /etc/named.conf

2.2.5高数据

高数据是通过SLS文件在YAML中表示的数据结构，大数据结构是通过合并在SLS文件中的渲染数据元组来创建的。

高数据可以通过执行state.show_highstate 或者 state.show_sls函数来看，由于这是一个有点复杂的数据结构，可以通过json, yaml或者pprint输出来更容易阅读。

salt '*' state.show_highstate --out yaml

salt '*' state.show_sls edit.vim --out pprint

2.2.6评估include语句

如果单个SLS文件包含include声明，则需要渲染include SLS的引用。对于每个带有include渲染的SLS文件，将读取include列表并解析定义的SLS引用。

被引用的includes下载和渲染；渲染序列维护已经下载了哪些SLS引用，以确保不会渲染相同的SLS文件两次。

2.2.7注入数据

在编译器中的许多地方，数据被注入到结构中，以满足排序和跟踪需求。这些注入启用了运行时的许多特性，并用于帮助将正确的调试数据向上传递。

2.2.8注入状态自动顺序

在将高位数据编译为低位数据时，虽然这里插入了顺序标志，但它还没有被计算。YAML渲染器已被修改为使用有序字典而不是标准的无序字典。

这意味着在渲染文件时保持顺序，并且可以将顺序标志插入到状态声明中。
自动状态排序的顺序从include语句的末尾开始。
因此，第一个被推入高数据字典的SLS文件是第一个被排序的文件。
更简单地说，顺序首先在包含链的末尾声明。
所以，如果SLS文件a包含文件b，而文件b又包含文件c，那么c中的状态将首先被求值，然后是b，然后是a。

如果声明了顺序，那么它将被执行，否则，将注入一个值:

named_conf:
  file.managed:
    - name: /etc/named.conf
    - order: 10002  # <- order injected

start_bind:
  service.running:
    - name: named
    - order: last  # <- explicitly declared, not evaluated till later

2.2.9注入__sls__和__env__值

此时，对加载文件的SLS引用和文件来自的环境都被加载到状态声明中。这些键被称为:

__sls__为SLS引用

__env__为环境着

这些值由多个状态读入，以确保用于下载源文件的环境与检索SLS文件的环境相同

named_conf:
  __env__: base # <- injected
  __sls__: dns  # <- injected
  file.managed:
    - source: salt://dns/files/RedHat-named.conf
    - name: /etc/named.conf
    - order: 10002

Start_bind:
  __env__: base  # <- injected
  __sls__: dns   # <- injected
  service.running:
    - name: named
    - order: last

2.2.10隐藏扩展和排除语句

在渲染每个文件时，所有的extend和exclude语句都被存储到高级数据结构中:

__extend__用于扩展状态

__exclude__表示被排除的状态

这些结构维护这些数据，以便在渲染所有SLS引用后进行协调。这意味着在文件的初始渲染期间，所有的“top级”声明都被取出并组合起来

2.2.11未经提炼的数据

一旦渲染了所有SLS引用，生成的数据结构就是未细化的high数据。未提炼的高数据需要提炼、协调，再进行编译。

清理了数据结构的快捷方式，并准备好了标准的高数据。这包括处理“短decs”，或者用点分隔的引用。这个清理会改变所有的引用，如下所示:

named_conf:
  __env__: base
  __sls__: dns
  file.managed:
    - source: salt://dns/files/RedHat-named.conf
    - name: /etc/named.conf
    - order: 10002

start_bind:
  __env__: base
  __sls__: dns
  service.running:
    - name: named
    - order: last

到删除了点分隔的短dec的结构中：

named_conf:
  __env__: base
  __sls__: dns
  file:
    - managed  # <- function moved here
    - source: salt://dns/files/RedHat-named.conf
    - name: /etc/named.conf
    - order: 10002

start_bind:
  __env__: base
  __sls__: dns
  service:
    - running  # <- function moved here
    - name: named
    - order: last

所有的排除顶级声明现在开始计算。

2.3状态编译

读取数据以查找排除匹配，并提取相应的排除项。

此时执行排除的主要警告是，此计算在包含之后。

结果是，当状态从一个文件包含而从另一个文件排除时，排除将覆盖包含

2.3.1状态编译

状态已经渲染，就可以编译了。Salt状态编译器包括对复杂的原始高级数据结构的协调：

_in声明到对应声明的转换
评估use声明
处理preeq声明
调整extend 语句
处理name引用
编译为低数据(低块)

下图显示了状态编译器例程:

2.3.2Reconciliation 一致性比较

状态一致性比较包括:

一致性复杂的原始高数据

将requisite_in声明转换为必需品

使用一致性

预分fork一致性

处理一致性

2.3.3一致性requisite_in语句

扫描原始high数据以查找requisite_in语句。找到的requisite_in语句被转换成__extend__结构中的数据，然后进行计算。

requisite_in的一个例子是require_in或watch_in

require_in和watch_in必备条件是最简单的。

它们转换为应用各自的require和watch语句的扩展数据。
use和use_in必需在高数据中搜索重定向数据，并设置扩展字典以应用将要使用的变量

2.3.4一致性前置语句
preeq系统创建一个fork。
问题是preeq需要将必要条件应用于它所要求的事物，同时也需要对它进行软要求。
因此，prereq系统创建了一个带有退出条件的必要条件的递归循环。
preeq用前置条件设置所有前置条件，同时保持前置条件。
由于不再需要requisite_in语句，其他requisite_in语句会被处理掉，但是prereq语句会在运行时使用。