saltstack（三）state
又研究了一天saltstack，这东西干什么用的，大概也可以说出个一二了。好了，saltstack这东西。大概能干这些活
[*] 远程执行命令，比如我看一下所有机器操作系统的version，用这东西就简单多了。
[*] 配置，配置apache,mysql等等都可以用它
[*] 软件安装
[*] 服务启动，重启
[*] 信息收集归档
下面说说，master和minion各自干了哪些活
master：
[*] 存放所有minion的公钥
[*] 监听mininon
[*] 发送命令给minion
[*] 存放一些为minion准备的配置文件，如state
[*] 存放一些为minion准备的files和数据，如apache2.cnf，pillar
minion：
[*] 连接master
[*] 监听master发送的commands
[*] 从master下载state并且执行state
[*] 可以执行在minion上执行state，用salt-call，当然这个一般多数用于调试
好了，总结了一下，下面开始写state这东西了。
state这玩意是个什么玩意呢？英文翻译一下是"状态"的意思。没错，就是状态，我们想象一下minions要达到什么样的状态，比如说：装什么软件，配置成什么样，服务是该运行还是该停止等等状态。。。。我们只要用state定义了，然后minions去执行，我们的客户端就会成为我们在state中定义的那个状态了。
另外一种理解是，其实master指导minions干活，无外乎两种方式一种是通过远程执行命令，另外一种方式就是state了。state也可以理解为按照一定的逻辑把命令组织成脚本。。就像linux里面的shell脚本一样。。。显而易见，有组织有纪律的state干起活来肯定比单枪匹马执行一个命令厉害多了。
下面说一下state的结构吧
默认存放的路径是/srv/salt,当然也可以改成别的路径，也可以添加多个路径。不过匹配state的时候会优先匹配上面的路径。比如：
/srv/salt/在 /home/salt/的上面设置，我们执行salt state.sls user的时候，会优先匹配/srv/salt/user.sls
此外：/srv/salt/这个路径也是salt默认的文件服务器的路径，比如说我们想用salt访问/srv/salt/files/mysql.cnf这个文件，需要这么去访问salt://files/mysql.cmf
楼主写了几个简单的小例子，记录了下state的用法。看一下楼主的目录结构吧
tree一下：
root@salt-master:/srv/salt# tree
.
├── apache2
│ ├── files
│ │ └── apache2.conf
│ └── init.sls
├── mysql
│ ├── conf2.sls
│ ├── conf.sls
│ ├── files
│ │ ├── my.cnf
│ │ └── my.cnf1
│ └── install.sls
├── top.sls
└── users
└── init.sls
└── init.sls 看看top.sls，比较一下内容和上面tree的目录结构，大概就应该知道top.sls的结构规则了。
当然第2行的target，满足上一篇讲的那些匹配规则
root@salt-master:/srv/salt# cat -n top.sls
1base:
2 'oscodename:Wheezy':
3 - match: grain
4 - users
5 - apache2
6 - mysql.install
7 - mysql.conf
看看apache2的state配置，第1行的apache2是下面这一系列内容作用的目标，2，4，10行是状态开始定义的行，3，5，14，15，16这些行是我们的目标将要达到的状态。 6行的require的意思是必须满足 -pkg: apache2这个状态，也就是说apache2安装之后service后面这一串才会起作用。
8行的watch除了require的功能外，还有的功能就是一旦apache2.conf这个被监控的文件发生改变，service这一串东西就会起作用。其它的应该都比较简单
root@salt-master:/srv/salt# cat -napache2/init.sls
1apache2:
2 pkg:
3 - installed
4 service:
5 - running
6 - require:
7 - pkg: apache2
8 - watch:
9 - file: /etc/apache2/apache2.conf
10 file:
11 - managed
12 - name: /etc/apache2/apache2.conf
13 - source: salt://apache2/files/apache2.conf
14 - owner: lixc
15 - group: lixc
16 - mode: 644
看看users这个state模块，这个模块使用了jinja2模板，可以实现更复杂的逻辑，比如说：变量，循环，条件选择等
root@salt-master:/srv/salt/users# cat -n init.sls
1{%for username in 'lxc','wwd','wxw','qhl'%}
2`username`:
3 user:
4 - present
5{%if username != 'lxc'%}
6 - shell: /usr/sbin/nologin
7{%endif%}
8{%endfor%}
看一下mysql目录先的三个文件。
其实install.sls和conf.sls合在一起。就是上面的apache2差不多了。。分开写执行为了测试，这种用法。conf2.sls中的1行include可以包涵其它的sls文件，4行的extend里的内容，将会覆盖conf.sls里面对应的内容
root@salt-master:/srv/salt/mysql# for filename in `ls *sls`;do echo -e "$filename\n" ;cat $filename;done
conf2.sls
1include:
2 - conf.sls
3
4extend:
5 /etc/mysql/my.cnf:
6 - file.managed:
7 - source: salt://mysql/files/my.cnf1
conf.sls
1/etc/mysql/my.cnf:
2 file.managed:
3 - source: salt://mysql/files/my.cnf
4 - owner: lixc
5 - group: lixc
6 - mode: 644
7mysql:
8 service:
9 - running
10 - require:
11 - pkg: mysql-server
12 - watch:
13 - file: /etc/mysql/my.cnf
install.sls
1mysql-server:
2 pkg:
3 - installed
4
好了，把这些个东西搞会，state算是初入门路了，离精通还十万八千里。最后说一下怎么执行state吧
执行某一个state，比如说apache2这个state吧
salt '*' state.sls apache2 执行这段的时候，salt首先会到/srv/salt目录下面找apache2.sls这个文件，有则执行。没有则找apache2目录下的init.sls这个文件，有则执行，没有就报错了。
再执行下mysql下面的state
salt '*' state.sls mysql.install 看到了没，mysql下面没有init.sls文件。我们只能指定具体的sls去执行了。注意那个.点号
上面说的两种方式，只执行某一个state。如果想执行所有state该咋办呢。
首先，要把我们需要执行的state在top.sls里面定义好，然后执行下面的命令
salt '*' state.highstate
执行这个命令的时候，salt会去找/srv/salt/目录下的top.sls文件，然后执行。
除了以上几种执行state的方式，还有别的方式吗，答案是肯定的。
其实在minion上面也可以执行。
咋执行呢？
首先要保证minion配置文件，file_client为remote(默认就是remote)
root@salt-minion:/var/cache/salt/minion# grep "#file_client" /etc/salt/minion
#file_client: remote
然后在minion上执行
salt-callstate.highstate
好了，这个是个啥原理呢，原理是minion执行salt-call state.highstate操作的时候，minion会主动到
master上面把/srv/salt/top.sls里面定义的东西下载到本地，然后执行。根据minion这么个特点，当然我们也可以salt-call highstate放到crontab里面去，这样客户端就可以主动的定期检查master上的state是否有更新了。
哈哈，先到这里吧
页:
[1]