運維自動化之salt筆記

1:saltstack的基本介紹

2:salt的安裝

1:服務端
1:安裝
2:配置文件
3:運行
4:注意事項
2:客戶端
1:安裝
2:配置文件
3:運行
4:注意事項 

3:salt的使用:

1:基礎知識
1：targeting
2：nodegroup
3：grains
4：pillar
2:狀態管理
1:state
1:state語法
2:state的邏輯關係
2:highstate
3:salt schedule
3:實時管理
1:cmd.run
2:module
4:其餘
1:無master
2:peer
3:runner
4:reactor

4:salt開發

1:saltclient管理salt
2:salt api

運維的工做主要在2方面:
1:狀態的管理
2:系統性能調優
這裏主要簡介下運維狀態的管理:

對於運維來講,基於狀態的配置管理已經向自動化邁進了一大步,以狀態爲核心的運維,讓狀態自己有了可管理性;在運維過程當中咱們會發現,一樣的一個配置,咱們會在不一樣的時間,不一樣的地點一次在一次的配置,這個時候,配置管理就有了重複性;有的甚至是原封不動的重複,而另一些則是按照必定的規律在發展,這些按照必定規律發展的配置,就是可預測的.綜上我認識的,咱們運維工做的自己是可管理,可重複,可預測的.基於這樣的理念,咱們就能夠更進一步的推動咱們的運維自動化,甚至到智能化.

看到這裏,我理想中的運維自動化的配置管理平臺應該有以下功能:
1:對狀態的配置及管理(最基本的)
2:能夠及時的對系統狀態進行調整並能看到結果(實時性和反饋性)
3:能夠對其自己作方便的第三方管理(方便的將運維與其餘管理作整合)

加分項:
1:開發語言單一
2:架構簡單,靈活
3:有不錯的安全性
4:沒有商業版(我的偏見)

下面是現有比較有表明性的自動化配置管理工具:
附:如下僅基於開源版本進行介紹

理念 優缺點
puppet 從運維的角度去作配置管理(運維人員作給運維用的) 架構簡單,系統比較成熟/不便於第三方管理
chef 從研發的角度去作配置管理(研發人員作給運維用的) 較便於第三方管理,對自身(節點,變量,cookbook)的管理較方便,有本身的dashboard,cookbook支持版本管理,自從cookbook的版本管理/架構複雜,開發語言較多,(安全問題)

以上2者都比較側重於狀態的管理,對單個或者多個狀態的臨時調整或者管理較差
2個都有商業版,讓我這個用開源版的很自卑

這裏咱們也能看到,2個配置功能都沒能達到我理想中的狀態,那就暫用chef吧,直到有一天,瞭解到了saltstack看到了這句話：「 系統配置的自動化不只可預測,可重複, 還具備可管理性」(http://wiki.saltstack.cn/reproduction/dive-into-saltstack),這尼瑪纔是運維自動化的將來啊，因而毫無節操的開始學習salt，並且發現越學越喜歡；在我使用puppet及chef的時候都沒有使用salt的感受，太爽了。因此我這裏僅僅介紹基本的語法不涉及實際用例，salt的安裝很是方便，因此你在看本文檔的時候但願你能真正的動手去作一下，而後你就會愛上salt了

附：：若是你會python，salt基本是不須要怎麼學的，而我正好了解一點py，不過這最多佔我選擇salt的20%。
最近也出來一個比較新的運維自動化的工具:ansible(http://www.ansibleworks.com/),對於ansible我研究的很少,簡單說下ansible與salt的狀況:
1:2者僅僅從大的功能上來講,區別不大
2:ansible:基於ssh(如今也能夠基於消息),免安裝(部分功能仍是須要安裝的,不過跟salt比安裝,配置方面就方便不少了),快捷方便,但也就限制在裏linix/unix平臺上;自帶完善是Web管理,API,數據存在基於數據庫; 總體看起來比較完整; 算是一個商業產品級
3:salt在產品這塊的總體佈局目前看起來不是很成熟(我感受salt在產品這塊的切入點很不錯),是一幫純粹工程師搞出來的東西;雖然簡單,靈活,強大,可是真實在實際使用過程當中,本身還會遇到很多的問題; 算是一個社區項目;不夠salt的迭代很是快,我相信很快就匯成熟
ansible是從商業目的出發,而後作開源
salt是從技術與應用目的出發,如今也算是在作部分商業產品
因此我跟趨向於salt

這裏有一個對比salt和ansible的文章:http://missingm.co/2013/06/ansible-and-salt-a-detailed-comparison/
我簡單的說下文章的內容:
在速度上通常狀況下salt比ansible快
在安全性上ansible略好於salt
安裝&部署&維護上ansible好於salt
在對狀態的管理的時候ansible也比salt優雅

最後做者更傾向於ansible;同時也說:也會使用salt;salt和ansible是都是很是優秀的工具.

1:saltstack的基本介紹

salt是一個新的基礎平臺管理工具。很短的時間便可運行並使用起來, 擴展性足以支撐管理上萬臺服務器，數秒鐘便可完成數據傳遞. 常常被描述爲 Func增強版+Puppet精簡版。 salt的整個架構都是基於消息來實現.因此可以提供很強的拓展性,靈活性,實時性; 不過salt仍是一個很年輕的東西，還有不少地方不夠完善，作的不夠好，不過我相信這些都只是時間問題。 注：如下文檔僅僅爲基本內容，相關知識點的深刻學習，請看相應文檔鏈接

2:salt的安裝

安裝有不少途徑,做爲一個CentOS的用戶,我選擇rpm
首先添加RPM源:

rpm -ivh http://mirrors.sohu.com/fedora-epel/6/x86_64/epel-release-6-8.noarch.rpm

附:實際生產中我是自建源

epel中關於salt的包:
salt-api.noarch : A web api for to access salt the parallel remote execution system
salt-master.noarch : Management component for salt, a parallel remote execution system
salt-minion.noarch : Client component for salt, a parallel remote execution system
salt.noarch : A parallel remote execution system
salt-cloud.noarch : Generic cloud provisioning tool
1:服務端
1:安裝
yum install salt-master -y
2:配置文件
/etc/salt/master
配置文件選項介紹: http://docs.saltstack.com/ref/configuration/master.html
最基本字段:
interface: 服務端監聽IP
3:運行
調試模式:
salt-master -l debug
後臺運行:
salt-master -d
做爲CentOS管理員,我選擇:
/etc/init.d/salt-master start
4:注意事項:
1:監聽端口
4505(publish_port):salt的消息發佈系統
4506(ret_port):salt客戶端與服務端通訊的端口,主要用來接受消息
因此確保客戶端能跟服務端的這2個端口通訊
2:客戶端
1:安裝
yum install salt-minion -y
2:配置文件
/etc/salt/minion
配置文件選項介紹: http://docs.saltstack.com/ref/configuration/minion.html
最基本字段:
master: 服務端主機名
id: 客戶端主機名(在服務端看到的客戶端的名字)
3:運行
調試模式:
salt-minion -l debug
後臺運行:
salt-minion -d
做爲CentOS管理員,我選擇:
/etc/init.d/salt-minion start
4:注意事項:
1：minion默認和主機名爲salt的主機通訊
2:關於配置文件
salt的配置文件均爲yaml風格
$key: $value #注意冒號後有一個空格
3:基礎知識
1：salt minion和master的認證過程：
(1) minion在第一次啓動時，會在/etc/salt/pki/minion/下自動生成minion.pem(private key), minion.pub(public key)，而後將minion.pub發送給master
(2) master在接收到minion的public key後，經過salt-key命令accept minion public key，這樣在master的/etc/salt/pki/master/minions下的將會存放以minion id命名的public key, 而後master就能對minion發送指令了

以下：
啓動服務端：
/etc/init.d/salt-minion restart
啓動客戶端：
/etc/init.d/salt-minion restart
服務端查看key：
salt-key
Accepted Keys:
Unaccepted Keys:
minion1
Rejected Keys:
服務端接受key
salt-key -a minion1
測試：
salt ‘minion1’ test.ping
minion1:
True
附：salt更多命令及手冊
salt ‘*’ sys.doc

3:salt的使用:

1:基礎知識
1：targeting
salt ‘*’ test.ping
引號中以實現很強大的minion的過濾與匹配技術
文檔:http://docs.saltstack.com/topics/targeting/compound.html

經常使用命令:
salt ‘shell正則’ 命令
salt -E ‘prel 正則’
salt -N $group 命令
salt -L ‘server_id1,server_id2,server_id3’ 命令

示例:
salt -C ‘webserv* and G@os:Debian or E@web-dc1-srv.*’ test.ping

2：nodegroup
對minion進行分組
文檔: http://docs.saltstack.com/topics/targeting/nodegroups.html
在master的配置文件中按以下格式定義:
nodegroups:
group1: ‘L@foo.domain.com,bar.domain.com,baz.domain.com or bl*.domain.com’
group2: ‘G@os:Debian and foo.domain.com’
在state或者pillar中引用的時候以下:
base:
group1:
– match: nodegroup
– webserver

3：grains
minion基本信息的管理
文檔:http://docs.saltstack.com/topics/targeting/grains.html
基本使用:
salt ‘*’ grains.ls 查看grains分類
salt ‘*’ grains.items 查看grains全部信息
salt ‘*’ grains.item osrelease 查看grains某個信息
示例：
salt ‘*’ grains.item osrelease
minoin1:
osrelease: 6.2
在用salt進行管理客戶端的時候或者寫state的時候均可以引用grains的變量

4：pillar
salt對敏感信息的管理,只有匹配到的節點才能獲取和使用
文檔:http://docs.saltstack.com/topics/tutorials/pillar.html
默認:pillar數據定義文件存儲路徑:/srv/pillar
入口文件:/srv/pillar/top.sls
格式:
base:
「targeting」:
– $pillar #名字爲pillar.sls的文件來存放對匹配到的minion的變量
$pillar.sls
基本:
$key: $value
state引用方式:

複雜:
users:
thatch: 1000
shouse: 1001
utahdave: 1002
redbeard: 1003
state引用方式:
查看節點的pillar數據：
salt ‘client2’ pillar.data
同步pillar：
salt ‘*’ saltutil.refresh_pillar

附：這裏咱們能夠看到，pallar中也可使用jinja（後面會提到）作一些處理

 

5：minion
即爲salt的客戶端

2:狀態管理
1:state
salt基於minion進行狀態的管理
1:state語法
文檔:http://docs.saltstack.com/ref/states/all/index.html
結構:
$ID: #state的名字
$state: #要管理的模塊類型
– $State states #該模塊的狀態
示例：
vim:
pkg:

– installed
若是是redhard系列的就安裝 vim-enhanced，若是系統是Debian或者Ubuntu就安裝vim-nox
附：state默認使用jinja（http://jinja.pocoo.org/）的模板語法，
文檔地址： http://jinja.pocoo.org/docs/templates/
2：state的邏輯關係：
文檔：http://docs.saltstack.com/ref/states/ordering.html

require：依賴某個state，在運行此state前，先運行依賴的state，依賴能夠有多個
httpd:
pkg:
– installed
file.managed:
– name: /etc/httpd/conf/httpd.conf
– source: salt://httpd/httpd.conf
– require:
– pkg: httpd

watch：在某個state變化時運行此模塊
redis:
pkg:
– latest
file.managed:
– source: salt://redis/redis.conf
– name: /etc/redis.conf
– require:
– pkg: redis
service.running:
– enable: True
– watch:
– file: /etc/redis.conf
– pkg: redis

 

附：watch除具有require功能外，還增了關注狀態的功能
還有與watch 和 require相反的watch_in,require_in

order：
優先級比require和watch低
有order指定的state比沒有order指定的優先級高
vim:
pkg.installed:
– order: 1 #讓當前狀態第一個運行,若是該狀態依賴其餘狀態,依賴的狀態會在這個狀態運行前運行

想讓某個state最後一個運行，能夠用last
3：state與minion
臨時給minoin部署個state
salt ‘minion1’ state.sls ‘vim’ #給minion1加一個vim的state
執行該命令後能夠當即看到輸出結果

2:highstate
給minion永久下添加狀態
文檔： http://docs.saltstack.com/ref/states/highstate.html
默認配置文件：/srv/salt/top.sls
語法：
‘*’:
– core
– wsproxy
/srv/salt/目錄結構：
.
├── core.sls
├── top.sls
└── wsproxy
├── init.sls
├── websocket.py
└── websockify

應用：
salt 「minion1」 state.highstate
測試模式：
salt 「minion1」 state.highstate -v test=True
3:salt schedule
默認的state只有在服務端調用的時候才執行，不少時候咱們但願minon自覺的去保持在某個狀態
文檔：http://docs.saltstack.com/topics/jobs/schedule.html
cat /srv/pillar/top.sls
base:
「*」:

– schedule
cat /srv/pillar/schedule.sls
schedule:
highstate:
function: state.highstate
minutes: 30
如上配置：
minion會每30分鐘從master拉去一次配置，進行自我配置
3:實時管理
有時候咱們須要臨時的查看一臺或多臺機器上的某個文件，或者執行某個命令
1:cmd.run
用法 salt ‘$targeting’ cmd.run ‘$cmd’
示例：salt ‘*’ cmd.run ‘hostname’
執行下這樣的命令，立刻就感覺到效果了，速度還賊快
2:module
同時，salt也將一些經常使用的命令作了集成
文檔：http://docs.saltstack.com/ref/modules/all/index.html
這裏幾乎涵蓋了咱們全部的經常使用命令
好比：
查看全部節點磁盤使用狀況
salt ‘*’ disk.usage
4：其餘
1:無master
文檔：http://docs.saltstack.com/topics/tutorials/quickstart.html
主要應該在測試和salt單機管理的時候
2:peer
文檔:http://docs.saltstack.com/ref/peer.html
提供了一種讓某個或者某些minion經過master管理其餘minoin的方法
既然minion均可以管理其餘minion了,確定要涉及到權限的問題,不然就亂了;peer的權限設置在master配置文件的peer塊
風格以下:
peer:
.*: #有管理權限的minion節點
– .* #可使用的module
例子:
peer:
.*example.com: #ID以example.com結尾的節點
– test.* #可使用test模塊
– ps.* #可使用ps模塊
– pkg.* #可使用pkg模塊
3:runner
官方的想法是提供了一種靈活的,快捷的調用salt的方式,經過salt-run就能夠直接在minion上運行本身的代碼,可是我感受有點多餘;我直接在master寫也能夠啊
定義runner代碼目錄:
master配置文件:
runner_dirs: [‘/srv/salt/_runner’,]
測試:
cat /srv/salt/_runner/foo.py
def test():
print 「True」
salt-run foo.test
True
固然這裏應該寫的是關於salt的調用
官方自帶的幾個runner:https://github.com/saltstack/salt/tree/develop/salt/runners
4:reactor
官方文檔: http://docs.saltstack.com/topics/reactor/index.html
這個模塊將消息中的部分標籤與部分sls綁定起來(綁定經過master的配置文件),sls定義了動做(作什麼操做)
1:定義tag與sls的關係
vim /etc/salt/master
reactor:
– ‘test’:
– /srv/reactor/test.sls
2:定義reactor的sls
vim /srv/reactor/test.sls
clean_tmp:
cmd.cmd.run:
– tgt: ‘*’
– arg:
– rm -rf /tmp/*

3: 發送消息
salt-call event.fire_master 」 ‘test’
這個時候就能夠看到 上面的哪一個reactor是執行了的,也就是說全部節點的tmp目錄都是空的了
這裏咱們注意到,第三步中執行的命令第一個參數是空的;這2個參數分佈是一個data和tag;這個data能夠在sls中作處理,tag就是用來觸發sls的哪一個標誌,和master中定義的哪一個須要同樣
好比這個命令:
salt-call event.fire_master ‘{「overstate」: 「refresh」}’ ‘foo’

首先:foo表明了觸發那個tag,而後執行相應的sls;而後在你的sls中能夠引用這個data,上面的哪一個overstate,在sls中引用的時候就須要這樣:data[‘data’][‘overstate’];
這個功能就提供了無限的可能性啊,好比一個服務器出現某種問題的時候讓另外一個服務器作某種操做等,反正我認識這事一個很是NB,實在的功能

4:salt開發

1:saltclient管理salt
只有master才能夠
salt所有用python，這裏也用python
文檔：http://docs.saltstack.com/ref/python-api.html
示例：
import salt.client
client = salt.client.LocalClient()
ret = client.cmd(‘*’, ‘cmd.run’, [‘ls -l’])
print ret
2:salt api
salt api我如今還沒用，不過我也沒搞定，若是你搞定了，我會很是感謝你能分享下的。

參考文檔：

1：salt中文wiki：http://wiki.saltstack.cn/很不錯的文章：http://wiki.saltstack.cn/reproduction/dive-into-saltstack2：salt官網http://saltstack.com/官網文檔：http://docs.saltstack.com/