又研究了一天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 1 base: 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 -n apache2/init.sls 1 apache2: 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;doneconf2.sls 1 include: 2 - conf.sls 3 4 extend: 5 /etc/mysql/my.cnf: 6 - file.managed: 7 - source: salt://mysql/files/my.cnf1conf.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 7 mysql: 8 service: 9 - running 10 - require: 11 - pkg: mysql-server 12 - watch: 13 - file: /etc/mysql/my.cnfinstall.sls 1 mysql-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-call state.highstate
好了，这个是个啥原理呢，原理是minion执行salt-call state.highstate操作的时候，minion会主动到
master上面把/srv/salt/top.sls里面定义的东西下载到本地，然后执行。 根据minion这么个特点，当然我们也可以salt-call highstate放到crontab里面去，这样客户端就可以主动的定期检查master上的state是否有更新了。
哈哈，先到这里吧