SaltStack；以及與AnsibleWorks,Chef-solo,puppet等等等的比較！

時間 2019-11-06

標籤 saltstack 以及 ansibleworks chef solo puppet 等等比較简体版

原文原文鏈接

SaltStack；以及與AnsibleWorks,Chef-solo,puppet等等等的比較！

...html

　　　　　　http://www.vpsee.com/2013/08/a-system-configuration-management-and-orchestration-tool-saltstack/java

系統自動化配置和管理工具 SaltStack

2013年08月22日 | 標籤: devops, puppet, salt, saltstack | 做者：vpseenode

咱們的服務器由 Puppet 配置管理工具來管理，服務器上線後由 puppet 完成初始化和配置等一系列工做（好比，靜態 IP 配置，DNS 設置，NFS/SAN 掛載，LDAP/Kerberos 登陸，安全加固配置，內核參數優化，防火牆規則配置等等），等初始化完成後開始運行，運行一段時間後有一些須要自動和手動操做的任務（好比升級、重啓、備份等），這時候咱們使用 Fabric 來批量執行這些臨時任務。python

因此從這裏能夠看到 Puppet 和 Fabric 實際上是兩個不一樣性質的工具，看下面的歸類可能會更清楚一些。Puppet 和 Fabric 兩個的工做其實能夠由一個工具 SaltStack（或 AnsibleWorks）完成，減小一個工具的使用會減輕一點負擔（學習工具的人力成本、安裝和配置工具的時間成本等等）。react

操做系統和軟件的安裝、配置、初始化等；
（Puppet, Chef, CFEngine, AnsibleWorks, SaltStack, …）linux

自動執行任務，好比按期備份、清除日誌等；
（Fabric, AnsibleWorks, SaltStack, …）git

手動執行任務，好比部署應用、升級、重啓、檢查和校驗文件系統、增長用戶等。
（Fabric, Rake, Func, Rundeck, AnsibleWorks, SaltStack, …）github

SaltStack 採用 zeromq 消息隊列進行通訊，和 Puppet/Chef 比起來，SaltStack 速度快得多。還有一點咱們喜歡 SaltStack 的地方是它是 Python 寫的，比 Puppet/Chef 這些 Ruby 工具更接近咱們的能力圈。web

安裝主控服務器（salt master）

和大多數相似工具同樣，SaltStack 須要在一臺機器（主控）上安裝服務器端軟件（SaltStack 稱之爲 salt master），在多臺機器（受控）上安裝客戶端軟件（SaltStack 稱之爲 salt minion）。在主控機器上給下屬（受控）發命令，在受控機器上接受和執行上級（主控）的命令。redis

在 Ubuntu 上安裝 salt master：

$ sudo add-apt-repository ppa:saltstack/salt
$ sudo apt-get update
$ sudo apt-get install salt-master

在 CentOS 6.x 上安裝 salt master：

# rpm -Uvh http://ftp.linux.ncsu.edu/pub/epel/6/i386/epel-release-6-8.noarch.rpm
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
# yum update
# yum install salt-master

安裝受控客戶端（salt minion）

在 Ubuntu 上安裝 salt minion：

$ sudo add-apt-repository ppa:saltstack/salt
$ sudo apt-get update
$ sudo apt-get install salt-minion

在 CentOS 6.x 上安裝 salt minion：

# rpm -Uvh http://ftp.linux.ncsu.edu/pub/epel/6/i386/epel-release-6-8.noarch.rpm
# yum update
# yum install salt-minion

安裝完 salt minion 後記得修改配置文件，讓 salt minion 指向 salt master 服務器地址：

$ sudo vi /etc/salt/minion
...
# Set the location of the salt master server, if the master server cannot be
# resolved, then the minion will fail to start.
master: saltmaster.vpsee.com
...

$ sudo restart salt-minion

在 master 上執行 salt-key list 就會看到有個 minion1.vpsee.com 請求加入受控，執行 -a 接受請求後，主控和受控之間的信任關係就創建起來了，主控就能夠任意「擺佈」受控了：

# salt-key list
Accepted Keys:
Unaccepted Keys:
minion1.vpsee.com
Rejected Keys:

# salt-key -a minion1.vpsee.com
The following keys are going to be accepted:
Unaccepted Keys:
minion1.vpsee.com
Proceed? [n/Y]

執行命令的例子

在主控機器上執行一個命令，讓全部受控機器執行 hostname 命令：

# salt '*' cmd.run "hostname"
minion1.vpsee.com:
    minion1.vpsee.com

在主控機器上執行一個命令，讓全部受控機器上執行內建 test.ping 命令：

# salt '*' test.ping
minion1.vpsee.com:
    True

還有一些內建命令能夠嘗試：

# salt '*' disk.usage
# salt '*' network.interfaces

執行狀態的例子

開頭的時候咱們說了 SaltStack = Fabric + Puppet，上面「執行命令的例子」演示了 Fabric 相似的功能，這裏要演示的是 Puppet 相似的功能，在主控上定義好系統配置應該有的狀態，而後受控自動完成相應的操做和配置。

首先肯定狀態定義的文件應該放在什麼地方，如下操做都在主控（salt master）上執行。檢查 /etc/salt/master 文件的 file_roots 條目，默認是在 /srv/salt 下，若是沒有這個目錄還須要手動建立一個：

# vi /etc/salt/master
...
#file_roots:
#  base:
#    - /srv/salt
...

# mkdir /srv/salt

好比咱們想在全部受控機器上安裝 vim 軟件包，並使用本身定義的 vimrc 文件：

# vi /srv/salt/vim.sls
vim:
  pkg.installed

/etc/vimrc:
  file.managed:
    - source: salt://vimrc
    - mode: 644
    - user: root
    - group: root

# vi /srv/salt/vimrc
syntax enable
set textwidth=79
set shiftwidth=4
set tabstop=4
set expandtab
set softtabstop=4
set shiftround
set fileencodings=utf-8
set encoding=utf8
set tenc=utf8

強制執行這個狀態：

# salt '*' state.sls vim

再來一個例子，參考「安裝和使用系統監控工具 Glances」一文，咱們想在全部受控機器上安裝 Glances，如何實現呢？

# vi /srv/salt/glances.sls
python-pip:
  pkg.installed

build-essential:
  pkg.installed

python-dev:
  pkg.installed

glances:
  pip.installed:
    - require:
      - pkg: python-pip

強制執行這個狀態：

# salt '*' state.sls glances
...
minion1.vpsee.com:
----------
    State: - pip
    Name:      glances
    Function:  installed
        Result:    True
        Comment:   Package was successfully installed
        Changes:   Glances==1.7.1: Installed
...

YC - August 24th, 2013 3:11 pm

前一段時間調研過saltstack，ansible，chef-solo三個自動化部署工具，最後決定用ansible。看來有空要試試saltOwnLinux - August 28th, 2013 1:34 pm有個地方須要更正一下。
1. 默認是在 /srv/salt 下，若是沒有這個目錄還須要手動建立一個：
  
  # vi /etc/salt/master ... #file_roots: # base: # - /srv/salt ...
  
  # mkdir /srt/salt
  
  應該是 mkdir /srv/salt,後還有幾個筆誤的地方。

#########################################################################################################

http://blog.halfss.com/blog/2013/09/06/ge-ren-dui-yun-wei-ji-yun-wei-zi-dong-hua-de-li-jie/

我的對運維及運維自動化的理解

如下內容爲我的理解,若有不對,請及時指出,謝謝

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

1:對狀態的配置及管理(最基本的)
2:能夠及時的對系統狀態進行調整並能看到結果(實時性和反饋性)
3:能夠對其自己作方便的第三方管理(方便的將運維與其餘管理作整合)

加分項:

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

下面是現有比較有表明性的自動化配置管理工具:

附:如下僅基於開源版本進行介紹

基本屬性(每項5分)      加分項目(每項1分)   總分
        狀態管理 實時管理      架構簡單,靈活 開發語言單一 有API  有反饋系統
puppet  5        3.5            1                1          0      0         10.5
chef    5        1             -1               -1          1      0          5
salt    4        5              1                1          1      1          13

附:

1:puppet的實時管理,我給了3.5是由於moc的緣由,這個moc,我感受就是硬生生的加在puppet上的,只不過整合的比較好,因此用起來沒那麼大的違和感;這就至關於爲了給puppet加入一個新的功能徹底引入一個新的系統;你喜歡這樣嗎? 我不喜歡
2:我對chef的架構和開發語言方面基本是懷有敵意,我在用chef的時候,我想改個功能,結果發現有3門語言:ruby,java,erlang並且我一個都不會(大家有誰能本身搞定這3門語言嗎?),架構方便更是引入了各類東西;都數不過來;我只能說chef的理念很好(cookbook的管理及編寫,節點的管理,role,environment的的設定,這些東西真的很好);可是被他們實現的我感受很很差;並且chef的安全問題和對安全的態度;chef客戶端基本能夠獲取當前chef環境中的全部信息,基本上意爲這一個chef-client被黑了(架構如此複雜被黑的可能性很高),你的全部chef-client+chef-server就悲劇了;chef官方git的代碼被微薄上的木人該了2次後(僅僅是我知道的);官方也沒什麼反應,請問,你敢用嗎?
3:salt的狀態不比puppet和chef的差多少,因此我給了4分

到這裏,若是你如今正要選擇一個運維自動化的工具的時候,毋庸置疑,就是salt了

最近也出來一個比較新的運維自動化的工具: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是都是很是優秀的工具.

Sep 6th, 2013 ops

　　　　http://blog.halfss.com/blog/2013/05/22/yun-wei-zi-dong-hua-zhi-saltxue-xi-bi-ji/

運維自動化之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-saltstack
2：salt官網http://saltstack.com/
     官網文檔：http://docs.saltstack.com/

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。