saltstack学习笔记

targeting minion

glob

  1.     salt '*' test.ping
  2.     salt \* test.ping

perl语言兼容正则表达式：

  1.     短选项： -E
  2.     长选项： --pcre
  4.     salt -E '^[mM]in.[eou]n' test.ping

list

  1.     短选项：-L
  2.     长选项：--list
  4.     salt -L web1,web2,db1,proxy1 test.ping

Subnet

  1.     短选项：-S
  2.     长选项： --ipcidr
  3.     匹配整个网段的
  4.     salt -S 192.168.0.42 test.ping
  5.     salt -S 192.168.0.0/16 test.ping

Grain

  1.     短选项：-G
  2.     长选项：--grain
  3.     salt可以通过操作系统、CPU架构以及自定义的信息等机器特征进行target Minion。
  4.     Grain是键值对的方式，所以需要制定键值，通过冒号分隔
  5.     salt -G 'os:Ubuntu' test.ping
  6.     salt -G 'os_family:Debian' test.ping
  7.     一些Grain是多级字典，可以通过冒号进行分隔字典中的每一级键名
  8.     salt -G 'ip_interface:eth0:192.168.1.11'

Grain PCRE

  1.     长选项：--grain-pcre
  2.     基于grain的pcre匹配
  3.     salt --grain-pcre 'os:red(hat|flag)' test.ping

Pillar

  1.     短选项：-I
  2.     长选项： --pillar
  3.     salt支持通过pillar数据进行匹配
  4.     salt -I 'my_var:my_val' test.ping

混合（Compound）

  1.     短选项：-C
  2.     长选项：--compound
  3.     混合target允许用户在一个shell命令中指定多种target类型。默认使用glob，想指定其他target类型，则需要再前面追加上类型简写和@符号。
  5.     如想匹配的系统是ubuntu，pillar中role的设置是web，且属于192.168.100.0/24子网的Minion。
  6.     salt -C 'G@os:Ubuntu,I@role:web,S@192.168.100.0/24' test.ping
  8.     布尔符号中的与（and）、或（or）及非（not）也可以在target类型中使用，如：
  9.     salt -C 'min* or *ion' test.ping
  10.     salt -C 'web* or *qa,G@os:Arch' test.ping

节点组(Nodegroup)

  1.     短选项：-N
  2.     长选项：--nodegroup
  3.     节点组是在salt内部使用的（所有的targeting终将创建一个动态节点组），从命令行中显式地指定节点组十分常用。在命令行使用前必须先再salt master的配置文件中以target列表进行定义（使用混合匹配语法），如在配置文件中进行如下定义：
  4.     nodegroups:
  5.         webdev: 'I@role:web,G@cluster:dev'
  6.         webqa: 'I@role:web,G@cluster:qa'
  7.         webprod: 'I@role:web,G@cluster:prod'
  8.     节点组定义完毕并重载master配置文件后，可以通过salt进行target：
  9.     salt -N webdev test.ping

运行模块方法

pkg.install 安装软件包
pkg.remove 卸载软件包
file.replace 类似于sed的功能

SLS文件树

top文件

  1. base:
  2.   '*':
  3.     - common
  4.     - vim
  5. qa:
  6.   '*_qa':
  7.     - jenkins
  8. web:
  9.   'web_*':
  10.     - apache2

声明了三个环境，分别是base、qa和web，base环境指定所有minion执行common和vim State，qa环境指定所有以_qa结尾的ID的Minion执行jenkins State。web环境指定所有以web_开头的ID的Minion执行apache2 State。

SLS目录组织

apache2.sls写法对应两种格式:

  • apache2/sls/init.sls
  • apache2.sls
    执行时会先找apache2.sls如果不存在，再找apache2/sls/init.sls，SLS文件可以有多层深度，每一层中间用句点表示.，最好是目录少一些，方便SLS快速查找。

使用State进行配置管理

/srv/salt目录下的文件用于定义Salt State。这是配置管理格式，用来强制Minion处于某一状态（State）：X软件包（package）需要安装，文件（file）Y格式正确，服务（service）Z开机自启并处于运行状态等。如下

  1.     apache2:
  2.       pkg:
  3.         - installed
  4.       service:
  5.         - running
  6.       file:
  7.         - managed
  8.         - name: /etc/apache2/apache2.conf

include块:

通过include可以在一个SLS文件引用其他SLS文件：

  1. include:
  2.   - base
  3.   - emacs

这个例子中，SLS文件将会把include块内容替换为base.sls（或base/init.sls）和emacs.sls(emacs/init.sls)
SLS文件中不能包含已经存在于include的SLS文件中的ID。

include本身作为一个顶级声明，只能在一个文件中出现一次。

require:

  1.     webservice:
  2.         service.running:
  3.             - name: apache2
  4.             - require:
  5.                 - pkg: web_package
  6.     web_package:
  7.         pkg.installed:
  8.             - name: apache2

正常情况，State SLS都是按顺序从前到后执行的，除非在声明时指定了require，如果指定了require，则会首先执行require指定的内容，再执行这个。

reuire:

require是最基本的requisite，它表示state会等待列表中定义的每一项state都成功执行后才会执行。

  1.     apache2:
  2.       pkg:
  3.         - installed
  4.         - require
  5.           - file: apache2
  6.       service:
  7.         - running
  8.         - require:
  9.           - pkg: apache2
  10.       file:
  11.         - managed
  12.         - name: /etc/apache2/apache2.conf
  13.         - source: salt://apache2/apache2.conf

在上边例子中，文件会首先复制到minion上，然后进行软件包的安装，之后再进行服务的启动。

watch

当配置文件发生了变更，apache2服务需要重启才行，这时需要watch，强制State在发现它watch的项目发生了变更时执行一个指定的动作。

  1.     apache2:
  2.       ..SNIP...
  3.       service:
  4.         - running
  5.         - require:
  6.           - pkg: apache2
  7.         - watch:
  8.           - file: apache2
  9.       ...SNIP...

当一个服务通过watch触发时，如果服务此时是关闭的，则Salt会尝试启动它。如果服务已经在运行中，则Salt会根据情况尝试service.reload,service.full_restart service.restart

use:

salt中是可以在一个State中声明一些默认值的，然后其他的State可以继承(inherit)这些默认值。最常见的就是一个State文件通过include去引用其它文件。如果State中使用的项已经被重新声明了，那么就会被新值覆盖。否则该项在使用时并不会进行任何修改。use类似于include，也是从其他SLS文件中继承过来，但是不会继承requisite部分。

  1.     apache2_conf:
  2.       file:
  3.         - managed
  4.         - name: /etc/apache2/apache2.conf
  5.         - user: root
  6.         - group: root
  7.         - mode: 755
  8.         - watch_in:
  9.           - service: apache2
  10.     mysql_conf:
  11.       file:
  12.         - managed
  13.           - name: /etc/mysql/my.cnf
  14.           - use:
  15.             - file: apache2_conf
  16.           - watch_in:
  17.             - service: mysql

mysql_conf State会安全地从apache2_conf State中继承user、group及mode，并且不会触发apache重启。

prereq

在某些情况下，有可能State并不需要运行，只有在另一个State预计会变更时才需要运行。例如一个web应用使用apache来提供服务，当产品服务器上的代码库需要变更时，Apache应该先关闭，以免代码没部署完时会有错误。
prereq requisite，就是针对这样的需求设计的。当一个State使用prereq时，Salt会先对prereq中指定关联的项目运行test模式来预计是否会进行变更。如果预计有变更，则Salt会用prereg标记该State需要执行。

  1.     apache2:
  2.       service:
  3.         - running
  4.         - watch:
  5.           - file: codebase
  6.     codebase:
  7.       file:
  8.         - recurse
  9.     ...SNIP...
  10.     shutdown_apache:
  11.       service:
  12.         - dead
  13.         - name: apache2
  14.         - prereq:
  15.           - file: codebase

扩展SLS文件

除了include块之外，State SLS文件还可以使用extend块来修改include块引入的SLS文件的内容。使用extend代码块和使用requisite类似，但是还有一些明显的不同。use或use_in requisite会复制默认值到另外的State中或从其他State上复制默认值到本State中，extend块则只能对引入的State进行修改。

  1. # cat /srv/generic_apache/init.sls
  2. apache2_conf:
  3.   file:
  4.   - managed:
  5.     - name: /etc/apache2/apache2.conf
  6.     - source: salt://apache2/apache2.conf
  8. 另一个文件中：
  9. include:
  10.   - generic_apache
  11. extend:
  12.   apache2_conf:
  13.     - file:
  14.     - source: salt://django/apache2.conf
  16. 另一个文件：
  17. include:
  18.   - generic_apache
  19. extend:
  20.   apache2_conf:
  21.     - file:
  22.       - source: salt://django/apache2.conf

Grain、Pillar及模板

Grain定义在指定的Minion上，Pillar定义在Master上。Grain常用于提供静态数据，Pillar更倾向于动态数据。

Pillar

pillar的top.sls文件在配置和功能上和State的top.sls文件一致，首先声明一个环境，然后是一个target，最后target需要使用的SLS文件列表。

  1.     base:
  2.       '*':
  3.         - bash

pillar只存储一些静态数据，因此文件内容相对简单一些。

例：

  1.     skel_dir: /etc/skel/
  2.     role: web
  3.     web_content:
  4.       images:
  5.         - jpg
  6.         - png
  7.         - gif
  8.       scripts:
  9.         - css
  10.         - js

模板

默认先用jinja渲染，再使用yaml。如果想改变渲染方式，可以在模板文件首行指定#!py #!mako|json先用mako渲染，在用json渲染

/etc/salt/master中默认配置 renderer： yaml_jinja，如果想修改默认配置，可以在此修改。

也可以在State中使用模板时指定渲染引擎：

  1.     apache2_conf:
  2.       file:
  3.         - managed
  4.         - name: /etc/apache2/apache2.conf
  5.         - source: salt://apache2/apache2.conf
  6.         - template: jinja

Jinja快速入门

变量可以通过闭合的双大括号来引用。如有一个叫做user的Grain:

```shell
The user {{ grains['user'] }} is referred to here. 

  2. Pillar也可以用这种方式：
  4. ```shell
  5. The user {{ pillar['user'] }} is referred to here.

以上例子如果user没有被定义，模板则无法正确渲染。更安全的办法是使用内置的salt交叉调用执行模块：

  1. The user {{ salt['grains.get']('user', 'larry') }} is referred to here.
  2. The user {{ salt['pillar.get']('user', 'larry') }} is referred to here.

如果user没有定义，则默认会使用larry这个值。

通过set设置模板中的局部变量：

  1. {% set myvar = 'My Value' %}

由于jinja基于Python，因此大多数Python的数据类型都是支持的，比如列表和字典

  1. {% set mylist = ['apples', 'oranges', 'bananas'] %}
  2. {% set mydict = {'favorite pie': 'key lime', 'favorite cake': 'saccher torte'} %}

逻辑判断：

  1. {% if grains['os_family'] == 'Debian' %}
  2. apache2:
  3. {% elif grains['os_family'] == 'RedHat' %}
  4. httpd:
  5. {% endif %}
  6.   pkg:
  7.     - installed
  8.   service:
  9.     - running

根据不同的系统，定义apache软件包的名叫做apache2还是httpd。state的其他部分则是相同的。

循环：

  1. {% set berries = ['blue', 'rasp', 'straw'] %}
  2. {% for berry in berries %}
  3. {{ berry }} berry
  4. {% endfor %}
posted @ 2018-01-29 10:56  yangrz  阅读(282)  评论(0)  编辑  收藏  举报