1、salt經常使用命令html
salt 該命令執行salt的執行模塊，一般在master端運行，也是咱們最經常使用到的命令node
salt [options] '<target>' <function> [arguments]python
如: salt '*' test.pingmysql
salt-run 該命令執行runner(salt帶的或者自定義的，runner之後會講)，一般在master端執行，好比常常用到的managereact
salt-run [options] [runner.func]
salt-run manage.status #查看全部minion狀態
salt-run manage.down #查看全部沒在線minion
salt-run manged.up #查看全部在線minion
salt-key #密鑰管理，一般在master端執行
salt-key [options]
salt-key -L #查看全部minion-key
salt-key -a <key-name> #接受某個minion-key
salt-key -d <key-name> #刪除某個minion-key
salt-key -A #接受全部的minion-key
salt-key -D #刪除全部的minion-key
salt-call #該命令一般在minion上執行，minion本身執行可執行模塊，不是經過master下發job
salt-call [options] <function> [arguments]
salt-call test.ping #本身執行test.ping命令
salt-call cmd.run 'ifconfig' #本身執行cmd.run函數
salt-cp #分發文件到minion上,不支持目錄分發，一般在master運行
salt-cp [options] '<target>' SOURCE DEST
salt-cp '*' testfile.html /tmp
salt-cp 'test*' index.html /tmp/a.html
salt-ssh 0.17.1版本加入的salt-ssh
salt-master master運行命令
salt-master [options]
salt-master #前臺運行master
salt-master -d #後臺運行master
salt-master -l debug #前臺debug輸出
salt-minion minion運行命令
salt-minion [options]
salt-minion #前臺運行
salt-minion -d #後臺運行
salt-minion -l debug #前臺debug輸出
salt-syndic #syndic是salt的代理，之後會說到
2、普通用戶執行saltnginx
普通用戶執行salt兩種方案:1,salt ACL 2.salt external_authgit
1.ACLgithub
1) 設置master配置文件web
client_acl:
monitor:
- test*:
- test.*
dev:
- service.*
sa:
- .*
2) 重啓Master正則表達式
service salt-master restart
3) 目錄和文件權限
chmod +r /etc/salt/master
chmod +x /var/run/salt
chmod +x /var/cache/salt
4) 測試
# su - monitor
# salt 'test*' test.ping
# exit; su - sa
# salt '*' test.ping
# salt '*' cmd.run 'uptime'
# exit;
2.external_auth
1) 修改master配置文件
external_auth:
pam: monitor: – ‘test‘: – test. sa: – .* – 2) 3)與ACL相同
4) 測試
# salt -a pam 'test*' test.ping ##會提示輸入帳號密碼，因此external_auth與當前用戶無關
username: monitor
password:
# su - monitor
# salt -a pam '*' cmd.run 'uptime'
username: sa
password:
5) 使用Token沒必要每次都輸入帳號密碼，使用external_auth每次都是須要密碼的，這樣多麻煩，這裏引入了Token，它會保存一串字符到在當前用戶家目錄下.salt_token中，在有效時間內使用external_auth是不須要輸入密碼的，默認時間12hour，能夠經過master配置文件修改
# salt -T -a pam '*' test.ping
username: sa
password:
#salt -a pam '*' test.ping #不會提示輸入密碼了
3、target
指定你的命令或者模塊應用哪寫Minion上
1.globbing 默認
salt 'test*' test.ping
2.RE 正則
salt -E 'web1-(pro|devel)' test.ping
3.List 列表
salt -L '127.0.0.1, test*' test.ping
4.grains
salt -G 'os:CentOS' test.ping #查看全部grains鍵/值
salt 'test*' grains.items #查看全部grains項
salt 'test*' grains.ls #查看某個grains的值
salt 'test*' grains.item num_cpus
在top file中匹配grains
'node_type:web':
- match: grain #沒有s
- webserver
top file中使用jinja模板
{% set self = grains['node_type'] %}
- match: grain
- {{ self }}
5.nodegroups 其實就是對Minion分組
首先在master的配置文件中對其分組,推薦寫到/etc/salt/master.d/中一個獨立的配置文件中，好比nodegroup.conf
vim /etc/salt/master.d/nodegroup.conf
#寫到master中也是這個格式，master.d中*.conf是默認動態加載的
nodegroups:
test1: 'L@test1,test2 or test3*'
test2: ‘G@os:CenOS or test2'
salt -N test1 test.ping #-N指定groupname
在top file中使用nodegroups
'test1':
- match: nodegroup ##意沒s
- webserver
6.混合指定,就是將以上的混合起來用
G Grains glob G@os:Ubuntu
E PCRE Minion ID E@web\d+\.(dev|qa|prod)\.loc
P Grains PCRE P@os:(RedHat|Fedora|CentOS)
L List of minions L@minion1.example.com,minion3.domain.com or bl*.domain.com
I Pillar glob I@pdata:foobar
S Subnet/IP address S@192.168.1.0/24 or S@192.168.1.100
R Range cluster R@%foo.bar
salt -C 'G@os:CentOS and L@127.0.0.1,192.168.1.12' test.ping
top file 指定:
'webserver* and G:CentOS or L@127.0.0.1,test1':
- match: compound
- webserver
7.一次在n個minion上執行
-b n
--batch-size n
示例：
salt '*' -b 5 test.ping 5個5個的ping
4、遠程批量執行
格式：
salt '<target>' <function> [argument]
注： function是salt帶的或本身寫的可執行模塊裏面的function，自帶的全部列表http://docs.saltstack.com/ref/modules/all/index.html?highlight=full%20list%20builtin 實例：
salt '*' at.at 10.10am 'uptime'
salt '*' test.ping
5、多Master
1.在另外一臺機器上安裝salt-master
yum -y install salt-master
2.將原來master上的master密鑰拷貝到新的master是一份
scp /etc/salt/pki/master/master* newmaster:/etc/salt/pki/master/
3.啓動新的Master
service salt-master start
4.修改minion配置文件/etc/salt/minion設置兩個master
master:
- master1
- master2
5.重啓minion
service salt-minion restart
6.在新的master上接受全部key
salt-key -L
salt-key -A
注意:
1.2個master並不會共享Minion keys，一個master刪除了一個key不會影響另外一個
2.不會自動同步File_roots,因此須要手動去維護，若是用git就沒問題了
3.不會自動同步Pillar_Roots，因此須要手工去維護，也能夠用git
4.Master的配置文件也是獨立的
6、pillar
Pillar在salt中是很是重要的組成部分，利用它能夠完成很強大的功能，它能夠指定一些信息到指定的minion上，不像grains同樣是分發到全部Minion上的，它保存的數據能夠是動態的,Pillar以sls來寫的，格式是鍵值對
適用情景：
1.比較敏感的數據，好比密碼，key等
2.特殊數據到特定Minion上
3.動態的內容
4.其餘數據類型
查看Minion的Pillar信息
salt '*' pillar.items
查看某個Pillar值
salt '*' pillar.item <key> #只能看到頂級的
salt '*' pillar.get <key>:<key> #能夠取到更小粒度的
編寫pillar數據
1.指定pillar_roots，默認是/srv/pillar(可經過修改master配置文件修改),創建目錄
mkdir /srv/pillar
cd /srv/pillar
2.編輯一個pillar數據文件
vim test1.sls
name: 'salt'
users:
hadoop: 1000
redhat: 2000
ubuntu: 2001
3.創建top file指定minion到pillar數據文件
vim top.sls
base:
'*':
- test1
4.刷新Pillar數據
salt '*' saltutil.refresh_pillar
5.測試
salt '*' pillar.get name
salt '*' pillar.item name
在state中經過jinja使用pillar數據
vim /srv/salt/user.sls
{% for user, uid in pillar.get(’users’, {}).items() %} ##pillar.get('users',{})可用pillar['users']代替，前者在沒有獲得值的狀況下，賦默認值
{{user}}:
user.present:
- uid: {{uid}}
{% endfor %}
固然也能夠不使用jinja模板
vim /srv/salt/user2.sls
{{ pillar.get('name','') }}:
user.present:
- uid: 2002
經過jinja模板配合grains指定pillar數據
/srv/pillar/pkg.sls
pkgs:
{% if grains[’os_family’] == ’RedHat’ %}
apache: httpd
vim: vim-enhanced
{% elif grains[’os_family’] == ’Debian’ %}
apache: apache2
vim: vim
{% elif grains[’os’] == ’Arch’ %}
apache: apache
vim: vim
{% endif %}
7、grains
服務器的一些靜態信息，這裏強調的是靜態，就是不會變的東西，好比說os是centos，若是不會變化，除非從新安裝系統
定義minion的grains能夠寫在/etc/salt/minion中格式以下
grains:
roles:
- webserver
- memcache
deployment: datacenter4
cabinet: 13
cab_u: 14-15
或者寫在/etc/salt/grains中，格式以下
roles:
- webserver
- memcache
deployment: datacenter4
cabinet: 13
cab_u: 14-15
也能夠在master中編寫grains的模塊，同步到minion中，用Python來寫很簡單的
1.在/srv/salt中創建_grains目錄
2.編寫grains文件，須要返回一個字典
vim test1.py
def hello(): ##函數名字無所謂，應該是全部函數都會運行
agrain = {}
agrain['hello'] = 'saltstack'
return agrain ##返回這個字典
3.同步到各個minion中去
salt '*' saltutil.sync_grains
salt '*' saltutil.sync_all
salt '*' state.highstate
4.驗證
salt '*' grains.item hello
8、使用 salt state
它的核心是寫sls(SaLt State file)文件,sls文件默認格式是YAML格式(之後會支持XML)，並默認使用jinja模板，YAML與XML相似，是一種簡單的適合用來傳輸數據的格式，而jinja是根據django的模板語言發展而來的語言，簡單並強大，支持for if 等循環判斷。salt state主要用來描述系統，軟性，服務，配置文件應該出於的狀態，經常被稱爲配置管理！
一般state，pillar,top file會用sls文件來編寫。state文件默認是放在/srv/salt中，它與你的master配置文件中的file_roots設置有關
示例： apache.sls文件內容 ##/srv/salt/apahce.sls，之後沒有用絕對路徑意思就是在/srv/salt下
apache: ##state ID，全文件惟一,若是模塊沒跟-name默認用的ID做爲-name
pkg: ##模塊
- installed ##函數
#- name: apache ##函數參數，能夠省略
service: ##模塊
- running ##函數
#- name: apache ##函數參數，這個是省略的，也能夠寫上
- require: ##依賴系統
- pkg: apache ##表示依賴id爲apache的pkg狀態
下面來解釋上面示例的意思：
聲明一個叫apache的狀態id,該id能夠隨意，最好能表示必定意思
pkg表明的是pkg模塊
installed是pkg模塊下的一個函數，描述的是狀態，該函數表示apache是否部署，返回值爲True或者False，爲真時，表示狀態OK，不然會去知足該狀態(下載安裝apache)，若是知足不了會提示error,在該模塊上面省略了參數-name: apache,由於ID爲apache,這些參數是模塊函數須要的（能夠去查看源碼）
service是指的service模塊，這個模塊下主要是描述service狀態的函數，running狀態函數表示apache在運行，省略-name不在表述，-require表示依賴系統，依賴系統是state system的重要組成部分，在該處描述了apache服務的運行須要依賴apache軟件的部署，這裏就要牽涉到sls文件的執行，sls文件在salt中執行時無序(若是沒有指定順序，後面會講到order)，假如先執行了service這個狀態，它發現依賴pkg包的安裝，會去先驗證pkg的狀態有沒有知足，若是沒有依賴關係的話，咱們能夠想象，若是沒有安裝apache，apache 的service確定運行會失敗的，咱們來看看怎麼執行這個sls文件:
salt '*' state.sls apache
在命令行裏這樣執行就ok了，.sls不要寫，若是在目錄下，將目錄與文件用’.’隔開，如： httpd/apache.sls –> httpd.apache
或者
這須要咱們配置top file執定哪一個minion應用哪一個狀態文件
top.sls內容
base:
'*':
- apache
下面咱們繼續看一些比較複雜的:
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
ssh/init.sls,學過Python的都知道目錄下面的init文件是特殊文件，它怎麼特殊呢，它特殊在當咱們應用目錄時會應用該文件的內容，如咱們執行 salt ‘*’ state.sls ssh時應用的就是init.sls文件，明白了嗎？再看裏面的內容，前兩行咱們已經看過了，是描述某個rpm包有沒有安裝的，第三行是ID，也能夠用來表示-name，以省略-name，file.managed是file模塊與函數managed的快捷寫法，看server.sls下最後就知道了，managed它描述了某個文件的狀態，後面跟的是managed的參數，user,group,mode大家一看就知道什麼意思了，關於這個source是指從哪下載源文件，salt://ssh/sshd_config是指的從salt的文件服務器裏面下載，salt文件服務器其實就是file_roots默認/srv/salt/明白了嗎，因此salt://ssh/sshd_config指的就是 /srv/salt/ssh/sshd_config,出來用salt的文件服務器，也能夠用http,ftp服務器。- require是依賴系統不表，之後會詳細說它的。再往下是server.sls文件，include表示包含意思，就是把ssh/init.sls直接包含進來
這時你會看到/srv/salt的目錄樹是:
ssh/init.sls
ssh/server.sls
ssh/banner
ssh/ssh_config
ssh/sshd_config
下面再來看一個官方樣例：
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
首先咱們include的別的文件，可是裏面的內容並非所有符合咱們的要求，這時咱們就須要用extend來重寫部份內容，特殊的是依賴關係都是追加。custom-server.sls文件意思是包含ssh/server.sls,擴展/etc/ssh/banner，從新其source而其它的如user,group等不變，與include一致。 mode_python.sls文件意思是把apache.sls包含進來，想apache-service是追加了依賴關係(watch也是依賴系統的函數).
經常使用狀態配置 salt-states-master.zip
9、關於渲染器render system
咱們上面也提過salt默認的渲染器是yaml_jinja,salt處理咱們的sls文件時，會先把文件用jinja2處理，而後傳給ymal處理器在處理，而後生成的是salt須要的python數據類型。除了yaml_jinja還有yaml_mako,yaml_wempy,py,pydsl,我比較感興趣的就是yaml_jinja,還有py，yaml_jinja是默認的，而py是用純python來寫的。下面來看個樣例吧，
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
這個樣例很簡單，就是加了個判斷，若是Minion的grains的os是RedHat那麼apache的包名是httpd，默認是apache,咱們知道在別的Linux發行版上，如ubuntu，suse他們的apache的包名就是叫apache，而在redhat繫上則叫httpd,因此纔有了這個判斷寫法，下面的service也是如此。咱們着重說語法，jinja中判斷，循環等標籤是放在{% %}中的，一般也會有結束標籤{% end** %},而變量是放在 {{ }}中的，salt,grains,pillar是salt中jinja裏面的三個特殊字典，salt是包含全部salt函數對象的字典，grains是包含minion上grains的字典，pillar是包含minion上pillar的字典。
示例：for user/init.sls文件內容
{% set users = ['jerry','tom','gaga'] %}
{% for user in users %}
{{ user }}:
user.present:
- shell: /bin/bash
- home: /home/{{ user }}
{% endfor %}
示例；salt字典 user/init.sls文件內容
{% if salt['cmd.run']('uname -i') == 'x86_64' %}
hadoop:
user.present:
- shell: /bin/bash
- home: /home/hadoop
{% elif salt['cmd.run']('uname -i') == 'i386' %}
openstack:
user.present:
- shell: /bin/bash
- home: /home/openstack
{% else %}
django:
user.present:
- shell: /sbin/nologin
{% endif %}
py渲染器 說明:py渲染器是用純python寫的sls文件，它返回的數據與yaml_jinja通過jinja處理通過yaml處理後的數據相似 ，用其餘渲染器須要在sls文件頭行聲明用的渲染器類型，#!py就是聲明用的py渲染器,py中可用的變量有salt,grains,pillar,opts,env,sls,前三個分別對應jinja裏的salt,grains,pillar,opts是minion的配置文件的字典，env對應的是環境如base,sls對應的是sls的文件名
示例： user/init.sls
#!py
import os
def run():
'''add user hadoop'''
platform = os.popen('uname -a').read().strip()
if platform == 'x86_64':
return {'hadoop': {'user': ['present',{'shell': '/bin/bash'}, {'home': '/home/hadoop'}]}}
elif platform == 'i386':
return {'openstack': {'user': ['present', {'shell': '/bin/bash'}, {'home': '/home/openstack'}]}}
else:
return {'django': {'user': ['present', {'shell': '/sbin/nologin'}]}}
說明: 首行聲明瞭使用py做爲渲染器，導入了os模塊，聲明run函數，py渲染sls文件是從run函數開始的，其它的就是python的語法了，注意的是return的數據結構{ID: {module: [func, arg1,arg2,...,]}} 或 {ID: {module.func: [arg1,arg2,..,]}} 。表示的內容與「示例；salt字典」表達的相同
10、state的執行順序
之前咱們說過，state的執行時無序，那個無序是指執行咱們寫的那個sls是無序的，正是由於那個無序，salt保證每次執行的順序是同樣的，就加入了state order，在說它以前看看High Data(高級數據？)和Low Data(低級數據？)，高級數據我理解的就是咱們編寫sls文件的數據，低級數據就是通過render和parser編譯過的數據。
查看highdata
salt '*' state.show_highstate
查看lowdata
salt '*' state.show_lowstate
經過查看lowdata咱們發現裏面有一個字段order,由於salt默認會自動設置order，從10000開始。能夠經過設置master配置文件參數state_auto_order: False來關閉
Order的設定：
1.include 被include的文件Order靠前，先執行
2.手動定義order字段，如
apache:
pkg:
- installed
- order: 1
order的數字越小越先執行從1開始，-1是最後執行
3.依賴關係系統
11、依賴關係系統requisite system
前面咱們已經用過了依賴關係系統，就是定義狀態與狀態之間的依賴關係的，常常遇到的依賴系統的函數有’require’和’watch’和它們的變種’require_in’,’watch_in’,require和watch有什麼區別嗎？
1.不是全部的state都支持watch,比較經常使用的是service
2.watch定義的依賴條件發生變化時會執行一些動做，如當配置文件改變時，service會重啓
示例: apache/init.sls文件內容
/etc/httpd/httpd.conf:
file:
- managed
- source: salt://httpd/httpd.conf
httpd:
pkg:
- installed
service:
- running
- require:
- pkg: httpd
- watch:
- file: /etc/httpd/httpd.conf ##當httpd.conf改變時，重啓httpd服務
require與require_in, watch與watch_in
require,watch是指依賴，require_in,watch_in是指被依賴
a reuire b 那麼就是b require_in a
a watch b 那麼就是b watch_in a
示例: apache/init.sls文件內容
/etc/httpd/httpd.conf:
file:
- managed
- source: salt://httpd/httpd.conf
- watch_in:
- service: httpd
httpd:
pkg:
- installed
- require_in:
- service: httpd
service:
- running
12、salt state環境
針對不用環境，應用不一樣的state的file，salt支持多環境，好比開發，測試，生產等環境，咱們經過修改Master配置文件對不一樣的環境應用不一樣的目錄！
file_roots:
base:
- /srv/salt/prod ##生產環境
qa:
- /srv/salt/qa ##測試環境，若是沒發現去prod裏面找
- /srv/salt/prod
dev:
- /srv/salt/dev ##開發環境，若是找不到，先去qa裏找，若是找不到再去prod裏面找
- /srv/salt/qa
- /srv/salt/prod
/srv/salt/prod/top.sls文件內容
base:
'web*prod*':
- webserver.foobarcom
qa:
'web*qa*':
- webserver.foobarcom
dev:
'web*dev':
- webserver.foobarcom
pillar的目錄與file_roots無關，因此Pillar的目錄默認仍是/srv/salt，pillar只是Minion的一些信息，不會對系統有什麼改變，因此不須要區分環境，一般base便可。
/srv/pillar/top.sls文件內容
base:
'web*prod*':
- webserver.prod
'web*qa*':
- webserver.qa
'web*dev*':
- webserver.dev
/srv/pillar/webserver/prod.sls文件內容
webserver_role: prod
/srv/pillar/webserver/qa.sls文件內容
webserver_role: qa
/srv/pillar/webserver/dev文件內容
webserver_root: dev
最後sls文件/srv/salt/prod/webserver/foobarcom.sls(該文件會被全部環境訪問到)的內容：
{% if pillar.get('webserver_role', '') %}
/var/www/foobarcom:
file.recurse:
- source: salt://webserver/src/foobarcom
- env: {{ pillar['webserver_role'] }}
- user: www
- group: www
- dir_mode: 755
- file_mode: 644
{% endif %}
開發完成後，應用sls文件
1.如今開發環境
salt -I ‘webserver_role:dev’ state.sls webserver.foobarcom
十3、salt schedule
schedule是salt中的crontab，就是週期性執行一些函數，須要注意的是在minion上執行的函數是salt的可執行模塊裏的函數，在master上執行的是runner模塊的函數，下面看看如何設置: master是修改master配置文件/etc/salt/master:
schedule:
overstate: ##這個是ID，能夠隨意起，全文件惟一
function: state.over ##對於master，function就是runner
seconds: 35 ##間隔秒數
minutes: 30 ##間隔分數
hours: 3 ##間隔小時數
這時每隔3小時30分35秒，master就會運行一個state.over這個runner
minion的schedule定義有兩種方式
1.經過修改minion的配置文件,這種方式須要修改全部Minion的配置文件略麻煩
schedule:
highstate:
function: state.highstate
seconds: 30
minutes: 5
hours: 1
2.爲Minion指定pillar
/srv/pillar/schedule.sls文件內容
schedule:
highstate:
function: state.highstate
seconds: 30
minutes: 5
hours: 1
經過top file指定到Minion
/srv/pillar/top.sls文件內容
base:
*:
- schedule
十4、YAML語法風格
1.空格和Tabs
在YAML中不要使用Tab
2.縮進
YAML推薦縮進爲2個空格，’:’,’-’後面縮進1個空格再寫
3.數字會解析成數字
如mode: 0644會解析成mode: 644,可用’括住防止mode: ’0644′此狀況
4.YAML不容許雙簡寫
vim:
pkg.installed ##第一個簡寫，單一個簡寫沒問題
user.present ##第二個簡寫，加上它是不支持的
不要偷懶寫成下面這樣吧。
vim: pkg：
- installed user: – present –
5.YAML只支持ASCII
其它字符集最好不要使用，若是非要使用用如下格式:
6.下劃線_將會被刪除
date: 2013_05_13 --> date: 20130513
經過’括住防止出現該問題
十5、salt事件系統與反應系統 event and reacter system
咱們知道Master與Minion是基於ZMQ通訊的，他們通訊咱們看來是消息隊列，對它們來講這些消息就是一些事件，什麼事件應該作什麼，是salt基本已經預設好了。咱們學習它的事件系統來完成一些自定義的行爲，後面的反應系統就是基於事件系統的。一條消息其實就是一個事件，事件一般是一個字典數據，這個字典數據一般包含tag,這個tag是用來區分用途過濾消息的，詳見綠大-https://groups.google.com/forum/#!topic/saltstack-users-cn/wXVE4ydnnzc ,讓咱們來看看這些事件。
捕捉事件(listen event)
1.下載官方給的事件捕捉程序eventlisten
https://github.com/saltstack/salt/blob/develop/tests/eventlisten.py 打開網址，複製下載，不要直接wget
2.運行該程序
Master: python2.6 eventlisten.py ##捕捉master端的event直接運行便可
Minion: python2.6 eventlisten.py -n minion <minion-id> ##捕捉minion端的須要額外參數，minion-id是該Minion的id
發送事件(fire event)
Master發給minion
salt '*' event.fire "{'data': 'some message'}" "tag" ##前面必須是字符串包住的字典，後面是tag,若是你的minion在監聽event，你會看到這條event的
Minion發給minion
salt-call event.fire_master 'some message' 'tag' ##前面數據類型沒有要求，後面是tag,去master那看看收到了沒有
Minion發給本身
salt-call event.fire "{'data': 'some message'}" 'tag' ##前面必須是字符串包住的字典，後面是tag
用code來捕捉，併發送event
捕捉事件 Master:
# python2.6
>>> import salt.utils.event
>>> event = salt.utils.event.SaltEvent('master', '/var/run/salt/master')
##master代表是在master端監聽，/var/run/salt/master是你master的sock_dir
>>> data = event.get_event()
>>> print(data) ##查看內容
>>> data = event.get_event(wait=10, tag='auth') ##wait是指timeout時間，默認5s,用tag來過濾事件，可省略
>>> print(data)
>>> for data in event.iter_events(tag='auth'): ##用迭代器一直查看事件
>>> print(data)
Minion:
#python2.6
>>> import salt.utils.event
>>> event = salt.utils.event.SaltEvent('minion', '/var/run/salt/minion',id='minion_id')
##minion表明是在minion端監聽，/var/run/salt/minion是minion端的sock_dir,minion_id是該Minion的id
>>> data = event.get_event()
>>> print(data)
>>> for data in event.iter_events(tag='auth'): ##用迭代器一直查看事件
>>> print(data)
—————–先這樣吧 發送事件:
Master:
>>> import salt.utils.event
>>> event = salt.utils.event.SaltEvent('master', '/var/run/salt/minion')
>>> event.fire_event({'hello': 'world'}, 'hello')
—————–先這樣
反應系統(reacter system)
反應系統是基於事件系統的，它的做用是當master收到來自minion的特殊事件後就觸發某些動做，好比minion上線後發送一個init事件，master收到後，對其應用init的狀態文件，minion沒有反應系統，事情就是這樣的。
配置reactor
1.修改master配置文件或者在/etc/salt/master.d/中創建reactor.conf,內容
reactor:
- 'testtag': ##接收到的tag
- /srv/reactor/start.sls
- /srv/reactor/monitor.sls
- 'test1*tag': ##接收到的tag，支持通配符
- /srv/reactor/other.sls
2.創建reactor響應sls文件
/srv/reacter/start.sls文件內容
{% if data['id'] == 'mysql1' %}
delete_file:
cmd.cmd.run:
- tgt: 'G@os:CentOS'
- expr_form: compound
- arg:
- rm -rf /tmp/*
{% endif %}
/srv/reactor/other.sls文件內容
{% if data['data']['state'] == 'refresh' %}
overstate_run:
runner.state.over
{% endif %}
下面來解釋一下這兩個文件，reacter的sls文件是支持jinja的，因此第一行是經過jinja來判斷，reacter的sls支持兩個變量data和tag, data是接受事件的那個字典，tag就是事件的tag，因此第一行的判斷就很好理解了，第二行是id，能夠隨意起，第三行是要運行的執行模塊或者runner，若是是執行模塊，以cmd.開始，若是是runner則以runner.開始，可執行模塊執行須要target，因此- tat:後面跟的就是可執行模塊的target,- expr_form指的target的匹配方式，- arg是隻執行模塊函數的參數，runner通常不須要這些。因此第一個示例至關於執行了salt -C 'G@mysql1' cmd.run 'rm -rf /tmp/*' 第二個至關於執行了 salt-run state.over
十6、salt Mine
salt的用的詞都過高明，像Grains,Pillar,Mine真心沒一個合適的詞去翻譯，Mine是作什麼的呢？Mine的做用是在靜態數據和動態數據創建起一座橋樑(官方文檔如是說),Mine從minon收集數據而後發送給Master，並緩存在Master端，全部Minion均可以輕易的共享到，Master一般會維護比較新的數據，若是須要維護長期數據，就要考慮retruner或外部的工做緩存了。 mine的出現是用來解決必定問題的. 在Salt的網絡體系中,各個minion是毫無關係,相互獨立的. 可是在實際應用中,minion之間實際上是有必定關聯的,好比一臺機器須要獲取到另外一臺機器的一些信息或者執行一些命令. 後來Salt加入了peer系統(http://docs.saltstack.com/ref/peer.html)使其成爲可能. 可是peer系統每次使用的時候都會從新執行一遍, 顯然不少不常變化的信息重複執行效率較低,性能開銷較大. 因此就有了後來的mine(peer和mine的關係是我杜撰出來的,若有雷同,純屬巧合). mine系統存儲在master端, minion想獲取的時候, 經過mine.get獲取下就能夠了,簡單方便
修改minion配置文件，配置Mine
mine_functions:
network.interfaces: []
test.ping: []
mine_interval: 1
重啓Minion，在master端測試
salt '*' mine_get '*' network.interfaces
salt '*' mine_get '*' test.ping
salt 'test1' mine_get '*' test.ping ##查看test1上能獲得mine數據
十7、salt ssh
從0.17.0開始salt加入salt ssh，salt ssh不須要在客戶端安裝salt-minion包了，是經過ssh協議來完成運城命令執行，狀態管理等任務的。它是做爲master-minion形式的補充出現的，原理是有一個花名冊的文件，裏面記錄了各個minion的信息，ip,帳號，密碼，等，須要遠程執行命令時，直接經過ssh來執行，速度與master-minion形式慢不少。
使用： 1.配置/etc/salt/roster格式以下
test1:
host: 192.168.1.133
user: salt
passwd: redhat
sudo: True
port: 22
timeout: 5
test2:
host: 192.168.1.134
user: root
passwd: redhat
test3:
host: 192.168.1.135
user: sa
sudo: True
說明: test1咱們定義了全部常見的選項，test2咱們用了超級用戶，使用帳號密碼，test3咱們使用普通用戶，沒有寫密碼，就是經過key來認證了，而且以sudo方式執行的，須要注意的是1.key認證用的是/etc/salt/pki/master/ssh/目錄下的密鑰。2.若是普通用戶的話，須要有sudo權限，由於一些功能，包括test.ping都須要sudo權限。
測試:
salt-ssh '*' test.ping
salt-ssh '*' -r 'ls /' ##執行shell命令
salt-ssh '*' cmd.run 'ls /' ##用模塊來執行也是能夠的
salt-ssh '*' state.sls ##執行狀態，state.sls在0.71.0中還存在bug,0.72.0中已解決
十8、Returners
默認全部minion返回的值都會發送到master端，咱們能夠看到，returner就是讓Minion把返回的值發給其它地方，如redis,MySQL,或者一個文本 下面咱們來自定義一個returner：
1.創建自定義returner
mkdir -p /srv/salt/_returners;
vim mysql.py ##就用官方給的例子吧，修改其中mysql的Host,user和pass
內容見https://github.com/saltstack/salt/blob/develop/salt/returners/mysql.py
2.創建須要的數據庫
見https://github.com/saltstack/salt/blob/develop/salt/returners/mysql.py註釋裏的見表語句
3.受權其餘主機用戶可寫該表
>grant all on salt.* to 'user_in_returner'@'%' identified by 'passwd_in_returner';
4.同步
salt '*' saltutil.sync_all ##同步到minion上去
5.測試
salt '*' test.ping --return mysql ##數據返回到mysql上去，打開mysql查看
十9、擴展salt
經過自定義各個模塊來擴展salt，常見自定義模塊有:
1.可執行模塊 Execution Modules
如咱們經常使用的cmd.run , test.ping這樣的可執行模塊
2.Grains
擴展grains，grains是一些靜態信息，可能好多咱們須要的沒有，咱們能夠經過編寫grains模塊自定義grains
3.狀態模塊 State Module
如咱們經常使用的pkg.install,file.managed
4.Returners
咱們能夠自定義returner，將返回的數據發送到其餘存儲，只要符合固定的格式就好了
5.Runner
Runner是在master端快速執行的模塊，自定義很方便
二10、自定義可執行模塊
全部可執行module見https://github.com/saltstack/salt/tree/develop/salt/modules，或http://docs.saltstack.com/ref/modules/all/index.html?highlight=full%20list%20builtin
1.創建自定義模塊目錄,一般全部自定義模塊放在該目錄下
mkdir /srv/salt/_modules
2.編寫模塊
vim test.py
-*- coding: utf-8 -*-
'''
support for yum of RedHat family!
'''
def __virtual__():
'''
Only RedHat family os can use it.
'''
if __grains__.get('os_family', 'unkown') == 'RedHat':
return 'yum'
else:
return False
def install(rpm):
cmd = 'yum -y install {0}'.format(rpm)
ret = __salt__['cmd.run'](cmd)
return ret
說明：__virtual__函數一般用來匹配是否知足該模塊的環境，若是知足return出來的字符串做爲該模塊的名字而不是文件名，若是return的是False表明的此模塊無效，不能使用。在自定義模塊中能夠中__grains__是一個包含了minion 全部grains的字典，__pillar__是包含了全部Pillar的grains字典,__salt__是全部可執行函數對象的字典，一般最常使用的就是這三個變量了。再往下面是定義了函數install,在salt中通常不用’%s’ % var這種格式化形式，而是使用字符串的format方法，具體使用見百度。下面就是經過__salt__執行了cmd.run這個函數來運行yum命令，很簡單吧，最後把結果返回回去。
3.測試
salt '*' yum.install ftp ##查看返回值
二11、自定義grains
自定義的grains也是由Python寫成的，一般放在/srv/salt/_grains下，grains須要返回一個字典，__salt__,__grains__,__pillar__也是能夠在grains中使用的。前面已經介紹過寫簡單自定義grains了，複雜就就參照https://github.com/saltstack/salt/blob/develop/salt/grains/core.py官方這個吧
二12、自定義returner
前面已經看過官方的mysql的returner了，今天來講說自定義returner須要注意的，來個例子吧。 /srv/salt/_returners/file.py內容
def __virtual__():
return 'file'
def returner(ret):
'''
Return information to /tmp/returns.txt.
'''
# open a file
result_file = '/tmp/returns.txt'
f = open(result_file, 'a+')
f.write(str(ret))
f.close()
salt '*' saltutil.sync_all ##同步模塊
salt '*' test.ping --return file ##測試
cat /tmp/returns.txt ##在minion上查看
{'jid': '20131227153001246117', 'return': True, 'retcode': 0, 'success': True, 'fun': 'test.ping', 'id': 'test1'}
說明： 經過這個簡單的例子咱們瞭解返回的值是個字典，字典包括的項就是上面咱們看到的，之後寫其它returner時，也就是把這個字典的值寫到不一樣的地方而已。這個returner的意思就是把返回的值寫到各個minion的/tmp/returns.txt中。
二十3、file state backup
來例子看看吧。 /srv/salt/test.sls文件內容
/tmp/test.txt:
file.managed:
- source: salt://test.txt
- backup: minion
其中多了一個參數backup，後面跟的值minion，意思是說這個文件在minion中備份一份，文件名帶着時間戳，備份位置在/var/cache/salt/minion/file_backup
執行並測試：
salt '*' state.sls test ##注，多修改幾回test.txt，多運行幾回該state
salt '*' file.list_backups /tmp/test.txt ##這是會返回備份序號，時間，位置，大小
回退 當文件改錯後，咱們能夠用備份文件回退
salt '*' file.restore_backup /tmp/test.txt 2 ##回退的文件，與想要回退的序列號
刪除 刪除不須要的備份文件
salt '*' file.delete_backup /tmp/test.txt 3
二十4、應用實例
saltstack 遠程觸發文件備份、回滾
一、建立模塊方法文件
mkdir /srv/salt/_modules
默認沒有此文件，本身生成一個
下面的py文件本身定義，下面是我寫的兩個方法：
#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys,string,shutil
import os,tarfile
import datetime,time
tn=datetime.datetime.today()
time_now=tn.strftime("%Y-%m-%d")
data_bak='/data/databak'
data_tmp='/data/databak/tmp/%s' % time_now
com_f="%s/%s" % (data_bak,time_now)
if not os.path.exists(com_f):
os.makedirs(com_f)
def CpFile():
id = sys.argv[1]
dir = sys.argv[2] #傳入兩個變量，任務自動生成的id與要替換的文件
filename = '%s/%s.tar' % (com_f, id)
mode = 'w:tar'
os.chdir(data_bak)
w_file=open("/tmp/tmp.list",'w')
w_file.write(id+" "+dir) #記錄每次備份的id與相對應的備份目錄或文件的路徑
w_file.close()
file = tarfile.open( filename, mode )
file.add( '/tmp/tmp.list' )
file.add( dir )
file.close()
return 'ok' #測試過程，就先讓返回ok吧，以後再作判斷
def RollBack():
id = sys.argv[1] #想要回滾到的版本id
if not os.path.exists(data_tmp):
os.makedirs(data_tmp)
filename = '%s/%s.tar' % (com_f, id)
tar = tarfile.open("%s" % filename)
for b in tar:
tar.extract(b,path="%s" % data_tmp)
tar.close()
for line in open('%s/tmp/tmp.list' % data_tmp):
id = line.split(" ")[:1][0]
dir = line.split(" ")[1:][0] #讀取備份時的路徑
backup_dir='%s/%s' % (data_tmp,dir)
os.system('\cp -rp %s %s' % (backup_dir,dir))
return 'ok'
二、測試：
master上同步方法腳本到節點
salt '*' saltutil.sync_all
而後先測試備份 方法
saltstack
salt ‘*’ cp_bakfile.CpFile 1234 /tmp/test #id + 路徑
上節點服務器上查看，存在
把/tmp/test下內容刪除，測試回滾操做
salt '*' cp_bakfile.RollBack 1234
使用gitfs作fileserver
用gitfs後，master會從git服務器取回文件緩存，minion不會直接聯繫git服務器 修改master配置文件/etc/salt/master(注:之後說master配置文件就是指該文件)
fileserver_backend:
- git
gitfs_remotes:
- git://github.com/saltstack/saltstack.git
- git://github.com/example/test1.git ##能夠多個git
- file:///root/td ##可使用本地git
須要:python的模塊GitPython >= 0.3.0
saltstack的目錄結構
.
|-- bfile
|-- edit
| `-- vim.sls
`-- top.sls
vim.sls
/tmp/a.txt:
file.managed:
- source: salt://bfile
ftp:
pkg:
- installed
也可使用git下的子目錄做爲文件服務器根目錄
gitfs_root: somefolder/otherfolder
也能夠混合使用git和本地磁盤做爲文件服務器
fileserver_backend:
- roots
- git
-
使用ssh協議的GitFS,私鑰爲~/.ssh/id_rsa
gitfs_remotes:
- git+ssh://git@github.com/example/salt-states.git
推薦閱讀：
saltstack經常使用管理命令
saltstack使用event機制來監控salt運行
saltstack 中pillar和grains的區別
saltstack master和minion認證機制
saltstack自定義模塊示例
使用salt state執行一個複製文件並執行的任務
saltstack pillar設置
saltstack的nodegroups配置
saltstack grains配置
併發之痛 Thread，Goroutine，Actor
requestAnimationFrame最佳實踐
grains：存儲在minion端，用於保存minion端的數據信息，當minion啓動時才加載grains信息，因此grains信息是靜態的，grains可用於minion信息查詢、target配置管理模板等；
存儲在master端，存放須要提供給minion的信息，應用場景：敏感信息（每一個minion只能訪問master分配給本身的pillar信息）、變量（差別化的信息）、其它任何數據、可在target、state中使用）；
1、修改配置文件
vim /etc/salt/master
pillar_roots:
base:
– /srv/pillar
2、建立top文件
vim /srv/pillar/top.sls
base:
'*':
- packages
3、建立pillar文件
vim /srv/pillar/packages.sls
{% if grains['os'] == 'RedHat' %} ##判斷系統時候是redhat,是的話Apache名是httpd
apache: httpd
git: git
{% elif grains['os'] == 'Debian' %}
apache: apache2
git: git-core
{% endif %}
4、測試
salt '*' pillar.get master:interface ## 查看master配置的ip地址
salt '*' saltutil.refresh_pillar ## 刷新
salt '*' pillar.data ## 命令查看pillar信息
salt '*' pillar.get schedule ## pillar取某個值
salt '*' pillar.get master:interface
grains VS pillar：
用途不一樣：grains用於存儲minion的基本數據信息，這些信息是批量的不可變的；pillar用於存儲master分配給minion的數據信息；
存儲區域不一樣：grains的元數據存儲在minion端；pillar的元數據存儲在master端；
更新方式不一樣：grains是在minion啓動時進行更新，也可經過saltutil.sync_grains進行刷新；pillar的元數據在master端，要用saltutil.refresh_pillar進行刷新，相較於grains，pillar效率更高、更靈活；
salt遠程執行
執行的格式 salt 【target】 【commond】
Targeting：
支持：Globing、正則、List、Grains、Pillar、Node Group、混搭、Batch Size
Globing : '*',
正則: 指定-E參數，salt -E 'web1-(prod|devel)' test.ping
List： 指定-L參數，salt -L 'node01,node02' test.ping
Grains： 指定-G參數，salt -G 'os:CentOS' test.ping
pillar: 指定-I參數，salt -I 'apache:httpd' pkg.install httpd
node groups: 指定-N參數，salt -N 'web-cluster' test.ping
混搭（compound） 指定-C參數，salt -C 'G@os:CentOS and *02*' test.ping
batch size -b參數，指定同時運行的minion數目 salt '*' -b 1 test.ping
salt '*' -b 10 test.ping 分10個minion一批進行執行，直到執行完畢
salt -G 'os:RedHat' --batch-size 25% apache.signal restart 分紅25%一批進行執行，直到執行完畢
爲了是master文件更加整潔,能夠將分組的文件放到/etc/salt/master.d/下面,會自動加載
遠程執行實例
一、salt '*' test.ping #測試minion是否能夠連通（非icmp協議）
二、salt '*' pkg.install httpd #在全部的minion機器上安裝httpd服務
三、salt '*' cp.get_file salt://apache/files/httpd.conf /opt/httpd.conf
salt-cp '*' /srv/salt/apache/files/httpd.conf /opt/httpd2.conf
#拷貝master上的配置文件到minion機器上，用於下發配置文件 通常用第一種
四、salt '*' service.start httpd ###啓動minion機器上的httpd服務
配置管理
salt 默認使用YAML做爲sls文件描述格式
1、使用空白字符爲文件縮排表示結構，不能使用TAB
2、註釋用#號
3、字符串日常不使用引號，若是有須要，可使用單引號或雙引號。使用雙引號表示字符串時，特殊字符能夠經過倒斜線（\）來進行定義
yaml用法：
1,列表：短槓（-）+ 空白字符
- henry
- sina
等價於：['henry','sina']
2,字典：key和value經過冒號(:)+空白字符隔開
name: henry
site: http://www.saltstack.cn/
等價於：{'name':'henry','site':'http://www.saltstack.cn/'}
3,多層結構：經過縮進來表示層級
- henry:
- sites:
- blog: http://www.saltstack.cn/
等價於：[{'henry':[{'sites':[{'blog':'http://www.saltstack.cn/'}]}]}]
官網地址：http://docs.saltstack.cn/topics/yaml/index.html
jinja
Salt默認使用Jinja2模板系統來生成YAML，是python語言開發的一個模板引擎，相似於Djingo模板系統
jinja模塊的用法：
變量：{{ foo }},變量屬性可使用{{ foo.bar }}或{{ foo['bar'] }}
註釋：{# comment #}
for: ##可使用for循環取值
{% for eachitem in items %}
{{ eachitem }}
{% endfor %}
if: ##能夠作if條件判斷
{% if GFW %}
welcome to China!
{% elif not Internet %}
welcome to North korea!
{% else %}
Freedom
{% endif %}
State Tree
Top file:配置管理入口文件，和pillar相似，指定minions須要完成那些配置管理，默認爲top.sls
注：在定義top.sls時,會先找apache/init.sls,若是沒有的話，會找apache.sls
base:
'*':
- apache
sls模塊使用點(.)來分割，如apache.install等於salt://apache/install.sls或salt://apache/install/init.sls
Include/Extend:sls文件間能夠經過include及extend來引用和擴展
sls中ID必須惟一，且在該ID下的同一類的狀態管理模塊只能有一個，所謂的slsID 就是定義sls文件時最開始定義在開頭的名字。
0.17.0 salt增長了state_auto_order參數(默認值爲True),使state在沒有Requisites的狀況下按照從上而下的順序進行執行
http://docs.saltstack.com/en/lastst/ref/states/highstate.html
Requisites（至關於sls流程控制，那個先執行，那個後執行等）
require:本state執行時須要先執行那些state
require_in:與require位置相反
watch：除了require外，也會監測依賴的state的狀態，若是狀態發生變化，作出反應（例如監控文件變化，發生變化後當即重啓服務）
watch_in： 與watch位置相反
prereq:0.16.0 新增的功能，會經過test=True接口檢查所依賴的state的狀態，若是狀態發生變化，執行
prereq_in：相反
http://docs.saltstack.com/en/lastst/ref/states/requisites.html
下面介紹三個模塊的用法，更多模塊用法請參考官網
官網地址：https://docs.saltstack.com/en/latest/ref/states/all/
軟件包狀態管理模塊：
模塊名：pkg
功能：管理軟件包狀態，會根據操做系統不一樣，選擇對應安裝方式
基本操做：
pkg.installed: #確保軟件包已安裝，若是沒有安裝進行安裝
pkg.latest: #確保軟件包是最新版本，若是不是，進行升級
pkg.remove: #確保軟件包已卸載，若是以前已安裝，進行卸載
pkg.purge: #除remove外，也會刪除其配置文件
文件狀態管理模塊：
模塊名：file
功能：管理文件狀態
基本用法：
file.managed： #保證文件存在而且爲對應的狀態
file.recurse: #保證目錄存在而且爲對應的狀態
file.absent: #確保文件不存在，若是存在則進行刪除操做
服務狀態管理模塊：
模塊名：service
功能： 管理服務狀態
基本用法：
service.running #確保服務處於運行狀態
service.enabled #確保服務會開機自動啓動
service.disabled #確保服務不會開機自啓動
service.dead #確保服務當前沒有運行
實例操做：
一、安裝apache
top.sls
base:
'*':
- apache
init.sls
apache: ##slsID
pkg.installed: ##安裝httpd
- name: httpd
file.managed:
- name: /etc/httpd/conf/httpd.conf ##拷貝/srv/salt/apache/httpd.conf到minion的/etc/httpd/conf/httpd.conf
- source: salt://apache/httpd.conf
- require: ##檢查apache有沒有安裝成功
- pkg: apache
service.running:
- enable: True
- name: httpd
- watch: ##watch檢測配置文件，若是發生變化會重啓服務
- pkg: apache
- file: apache
運行配置管理：salt '*' state.sls apache
salt '*' salt.highstate test=True #test=True用於測試語法
二、apache須要監控8080端口，代碼以下：
首先修改apache的主配置文件，修改配置文件爲 listen {{ port }}，修改完成後能夠直接在sls文件裏定義
apache:
pkg.installed:
- name: httpd
file.managed:
- name: /etc/httpd/conf/httpd.conf
- source: salt://apache/httpd.conf
- require:
- pkg: apache
- template: jinja ##調用jinja模板渲染
- context: ##這裏能夠是context或default效果同樣
port: 8080
service.running:
- enable: True
- name: httpd
- watch:
- pkg: apache
- file: apache
若是多臺主機監聽的端口不同，具體修改以下：
apache:
pkg.installed:
- name: httpd
file.managed:
- name: /etc/httpd/conf/httpd.conf
- source: salt://apache/httpd.conf
- require: #先同步配置文件，後重啓服務
- pkg: apache
- template: jinja
- defaults:
{% if grains.id == "10.13.41.80" %}
port: 8080
{% elif grais.id == "10.13.41.81" %}
port: 8081
{% else %}
port: 80
{% endif %}
service.running:
- enable: True
- name: httpd
- watch:
- pkg: apache
- file: apache
爲了讓sls文件不參雜業務數據，業務數據應該獨立存放，到了該pillar登臺的時候了。
/srv/pillar/apache/init.sls
apache:
{% if grains.id == "test" %}
port: 8081
{% elif grains.id == "test1" %}
port: 8082
{% else %}
port: 80
{% endif %}
/srv/pillar/top.sls
base:
'*':
- apache
salt '*' saltutil.regresh_pillar ##刷新pillar
salt '*' pillar.get apache:port ##取minion的pillar信息
/srv/salt/apache/deploy.sls
- template: jinja
- defaults:
port:{{salt['pillar.get']('apaceh:port',80)}}
saltstack官方參考樣例：
saltstack官方提供的解決方案：
Job管理
job簡介
jid：job id ,格式爲%Y%m%d%H%M%S%f
master 在下發指令消息時，會附帶上產生的jid。minion在接受到指令開始執行時，會在本地的cachedir（默認是/var/cache/salt/minion/）下的proc目錄產生以該jid命名的文件，
用於在執行過程當中master查看當前任務的執行狀況，指令執行完畢將結果傳送給master後，刪除該臨時文件
master將minion的執行結果存放在本地/var/cache/salt/master/jobs目錄，默認緩存24小時（能夠經過修改master配置文件keep jobs選項調整）
salt '*' test.ping -v ##能夠顯示任務的Jid，-v 顯示命令執行的詳細過程
https://github.com/saltstack/salt/pull/12365 ##salt-master -v時顯示詳細的執行結果
wrapper returns summary to a function ##點擊這個將代碼加入到master中
Job基本管理
saltutil模塊中的job管理方法
1、saltutil.running ##查看minion當前正在運行的jobs
salt '* saltutil.running
2、saltutil.find_job <jid> ##查看指定jid的job(minion正在運行的jobs)
salt '*' saltutil.find_job 20160422114120923967 ##首先執行saltutil.running 查看jid
3、saltutil.signal_job <jid> <single> ##給指定的jid進程發送信號
salt '*' saltutil.signal_job 20160422114328898570 9
4、saltutil.term_job <jid> ##終止指定的jid進程(信號爲15)
salt '*' saltutil.term_job 20160422114528346315
5、saltutil.kill_job <jid> ##終止指定的jid進程(信號爲9)同上,不在演示
salt runner中的job管理方法：
1、salt-run jobs.active ##查看全部minion當前正在運行的jobs(在全部minion上運行saltutil.running)
salt-run jobs.active
2、salt-run jobs.lookup_jid <jid> ##從master jobs cache 中查詢指定jid的運行結果
salt-run jobs.lookup_jid 20160421215616643464
3、salt-run jobs.list_jobs ##列出當前master jobs cache 中的全部job
更多job管理請訪問：
Schedule
簡介
用於master/minion按期執行schedule中配置的任務； schedule可配置在master配置文件或minion的配置文件或pillar中； master端配置schedule運行runner； minion端配置schedule爲遠程執行； schedule系統並不會將運行結果發送給master或產生event； schedule支持returner，可將schedule執行結果發送到指定的returner中；
每30分鐘minion執行一次highstate（配置在minion配置文件或pillar中）
# cat top.sls
base:
'*':
- schedule
# cat schedule.sls 這個只要是sls結尾就OK
schedule: ####這個健必須是schedule，只能有一個，不能在其它的.sls文件中再使用，全部任務計劃都放在這
highstate: #每30min執行一次state.highstate
function: state.highstate
minutes: 30
--------------------------------------------------------------------
schedule:
helloword:
function: cmd.run
args:
- date >> /tmp/test.log
minutes: 1
每分鐘查詢一次loadaverage，並將結果輸出到mysql returner中
schedule
uptime:
function: status.uptime
seconds: 60
returner: mysql
#salt '*' saltutil.refresh_pillar 刷新
#salt '*' pillar.get schedule 查看
salt syndic
在syndic server上安裝salt-master和salt-syndic，被syndic管理的minion要改/etc/salt/minion中master: syndic_server_IP；
Master 端的配置（/etc/salt/master）：
order_masters: True
syndic 端的配置（/etc/salt/master）：
syndic_master: Maste _IP
#syndic_master_port: MasterOfMaster_PORT
#syndic_pidfile: /var/run/salt-syndic.pid
#syndic_log_file: /var/log/salt/syndic.log
minion 端的配置（/etc/salt/minion）：
master：syndic_master_IP
salt-ssh：
salt ssh基於ssh，無需zeromq和agent，支持sudo；
salt ssh的最終目標是可以和標準的salt完成相同的功能；
當前salt ssh只支持target端的glob和re，當前salt ssh依然爲alpha狀態，尚不能徹底替代標準的salt應用於生產環境中；
salt roster系統隨salt ssh系統加入到salt代碼中，主要爲saltssh提供須要鏈接的主機和權限信息，默認/etc/salt/roster；
1、安裝並修改配置文件
# yum -y install salt-ssh
# vim /etc/salt/roster
minion1:
host: 10.96.20.117
user: root
passwd: chai
另optional parameters有：
port: #（the target system's ssh port number）
sudo: #（boolean to run command via sudo）
priv: #（file path to ssh private key,defaults to salt-ssh.rsa）
timeout: #（number of seconds to wait for response）
2、測試
# service salt-master stop
salt-ssh '*' test.ping #（有以下報錯，解決辦法：嚴格檢查禁用或者先用ssh鏈接minion）
vim .ssh/config
host 10.96.20.117
StrictHostKeyChecking no
salt-ssh '*' -r 'echo hello' 直接執行shell命令
############################################################################################
SaltStack的一個比較突出的優點是具有執行遠程命令的功能，操做及方法與func類似，能夠幫助運維人員完成集中化的操做平臺。
命令格式: salt '<操做目標>' <方法> [參數]
示例：查看被控主機的內存使用狀況.以下.
|
1
2
3
4
5
6
7
8
|
[root@locaohost~]# salt
'SN100-128'
cmd.run
"free -m"
SN100-128:
total used free shared buffers cached
Mem: 8001 6230 1770 0 222 2057
-/+ buffers/cache: 3950 4051
Swap: 5119 0 5119
#查看SN100-128主機內存使用狀況.
|
其中針對<操做目標>，SaltStack提供了多種方法對被控端主機(ID)進行過濾，下面列舉經常使用的具體參數。
1.) -E，--pcre,經過正則表達式進行匹配。示例：查詢SN100-字符開頭的主機id名是否連通，命令: salt -E '^SN100-*' test.ping,運行結果以下.
|
1
2
3
4
5
6
7
8
9
|
[root@localhost ~]# salt -E
'^SN100-*'
test.ping
SN100-128:
True
SN100-129:
True
SN100-130:
True
#正則匹配主機的連通性.
|
2.) -L, --list，以主機id名列表的形式進行過濾，格式與python的列表類似，即不一樣主機id名稱使用逗號分隔。示例：獲取主機id名爲SN100-128，SN100-129；獲取完整操做系統發行版名稱，命令：salt -L 'SN100-128,SN100-129' grains.item osfullname,以下：
|
1
2
3
4
5
6
7
8
9
10
11
|
[root@localhost~]# salt -L
'SN100-128,SN100-129'
grains.item osfullname
SN100-128:
----------
osfullname:
CentOS
SN100-129:
----------
osfullname:
CentOS
#列表形式匹配主機的操做系統類型
|
3.)-G --grain，根據被控主機的grains信息進行匹配過濾，格式爲'<grain value>:<glob expression>'，例如，過濾內核爲Linux的主機能夠寫成'kernel:Linux',若是同時須要正則表達式的支持可切換成--grain-pcre參數來執行。示例：獲取主機發行版本號爲6.4的python版本號，命令：salt -G 'osrelease:6.4' cmd.run 'python -V',運行結果以下。
|
1
2
3
4
5
6
7
8
9
|
[root@localhost ~]# salt -G
'osrelease:6.4'
cmd.run
'python -V'
SN100-128:
Python 2.6.6
SN100-129:
Python 2.6.6
SN100-130:
Python 2.6.6
#grain形式匹配主機的python版本
|
匹配操做系統發行版本爲CentOS的被控端能夠經過-G參數來過濾。
|
1
2
3
4
5
6
7
8
9
|
[root@localhost~]# salt -G
'os:CentOS'
test.ping
SN100-130:
True
SN100-128:
True
SN100-129:
True
#返回True，則表示都是CentOS系統
|
4) -I --pillar,根據被控主機的pillar信息進行匹配過濾，格式爲"對象名稱：對象值"，例如，過濾全部具有'apache:httpd' pillar值的主機。示例：探測具備'nginx:root:/data' 信息的主機連通性，命令：salt -I 'nginx:root:/data' test.ping ,運行結果以下。
|
1
2
3
4
5
6
7
8
9
|
[root@localhost~]# salt -I
'nginx:root:/data'
test.ping
SN100-128:
True
SN100-129:
True
SN100-130:
True
#pillar形式匹配主機的連通性
|
其中pillar屬性配置文件以下:
5.) -N --nodegroup,根據主控端master配置文件中的分組名稱進行過濾，(主機信息支持正則表達式、grain、條件運算符等)，一般根據業務類型劃分，不一樣業務具有相同的特色，包括部署環境、應用平臺、配置文件等。舉例分組配置信息以下：
【/etc/salt/master】
nodegroups:
group1: 'L@SN100-128,SN100-129,SN100-130'
group2: 'L@SN200-131'
其中，L@表示後面的主機id格式爲列表，即主機id以逗號分隔；G@表示已grain格式描述；S@表示已IP子網或地址格式描述。
示例：探測group2被控主機的連通性，其命令爲：salt -N group2 test.ping .
6.) -C --compound,根據條件運算符not、and、or去匹配不一樣規則的主機信息。示例：探測SN100開頭而且操做系統版本爲CentOS的主機連通性，命令以下：
|
1
|
salt -C
'E@^SN100-* and G@os:Centos'
test.ping
|
其中，not語句不能做爲第一個條件執行，不過能夠經過如下方法來規避，示例：探測非SN100開頭的主機連通性，其命令爲：salt -C '* and not E@^SN100-*' test.ping。
7) -S --ipcidr,根據被控主機的IP地址或IP子網進行匹配，示例以下：
|
1
2
|
salt -S 192.168.0.0/16 test.ping
salt -S 192.168.1.10 test.ping
|
salt-run命令：
判斷minion端是否鏈接到master端
|
1
2
3
4
5
6
|
語法：salt-run [options] [runner.func]
salt-run manage.status #查看全部minion狀態
salt-run manage.down #查看全部沒在線minion
salt-run manged.up #查看全部在線minion
salt-run manage.versions #查看版本
|
Salt job id管理
|
1
2
3
4
5
|
salt
'*'
test.ping -v
salt
'*'
saltutl.running #顯示minion當前正在運行的job
salt
'*'
saltutl.kill_job jid #強制退出遠程執行的job進程.
|
1、ZeroMQ描述
咱們進行自動化運維大多數狀況下，是咱們的服務器數量已經遠遠超過人工SSH維護的範圍，SaltStack能夠支數以千計，甚至更多的服務器，這些性能的提供主要來自於ZeroMQ，由於SaltStack地城是基於ZeroMQ進行高效的網絡通訊，ZMQ用於node與node間的通訊，node能夠是主機也能夠能夠是進程。
2、ZeroMQ簡介
ZeroMQ（咱們一般還會OMQ，Zmq等來表示）是一個簡單好用的傳輸層，像框架同樣的一個套接字庫，他使用的socket編程更加簡單、簡潔和性能更高，它仍是一個消息處理隊列庫，可在多個線程、內核和主機核之間彈性伸縮。
發佈與訂閱
ZeroMQ支持Publish/Subscribe，即發佈與訂閱模式，咱們常常簡稱Pub/Sub
如圖：
Salt Master運行兩個網絡服務，其中一個是ZeroMQ Pub系統，默認監聽4505端口，能夠經過修改/etc/salt/master配置文件的publish_port參數設置，它是salt的消息發佈系統，若是查看4505端口，會發現全部Minion鏈接到Master的4505端口，TCP狀態持續保持爲ESTABLISHED
[root@salt-client ~]# lsof -i :4505
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
salt-mini 2630 root 24u IPv4 41122 0t0 TCP 172.16.17.12:41314->salt:4505 (ESTABLISHED)
這樣Salt Master發佈一個消息，全部鏈接到4505這個Pub端口上的Minion都會接受到這個消息，而後每一個Minion會再判斷本身是否須要執行這個消息。
請求與響應
ZeroMQ支持Request-Reply，即請求與響應模式，咱們常常簡稱REQ/REP
如圖：
Salt Master運行的第二個網絡服務就是ZeroMQ REP系統，默認監聽4506端口，能夠經過修改/etc/salt/master配置文件的ret_port參數設置，他是salt客戶端與服務端通訊的端口，好比說Minion執行某個命令後的返回值就是發送Master的4506這個REP端口。
因爲咱們在最初安裝了python-setproctitle軟件包，因此咱們能夠直接看到Salt Master啓動的進程的名稱。
[root@ops-node1 ~]# ps aux | grep salt
/usr/bin/salt-master -d ProcessManager #中心進程管理器
/usr/bin/salt-master -d _clear_old_jobs #清除舊的Jobs文件及更新fileserver
/usr/bin/salt-master -d Publisher #將任務PUB到Minion端
/usr/bin/salt-master -d EventPublisher #Event Publisher進程
/usr/bin/salt-master -d ReqServer_ProcessManager #ReqServer進程管理器
/usr/bin/salt-master -d MWorker #工做進程
/usr/bin/salt-master -d MWorker #工做進程
/usr/bin/salt-master -d MWorker #工做進程
/usr/bin/salt-master -d MWorker #工做進程
/usr/bin/salt-master -d MWorker #工做進程
/usr/bin/salt-master -d MWorkerQueue #將Ret接口(ROUTER)數據轉發到Worker(DEALER)