ansiable和saltstack優劣勢,在百台伺服器規模下碰到的坑？

前來聽聽大牛對這兩個自動化工具的講解,,使用過程中碰到的坑以及解決的辦法,,

---

利益相關 ansible-shell維護者之一

Saltstack的優點是可以很方便的將執行結果保存到資料庫或者redis等存儲中，對於二次開發來說很順暢，缺點是每台機器上都需要裝客戶端，登錄認證體系和系統的ssh沒關係，然而執行許可權又那麼大，這就代表著，他其實已經是另外一個後門了。

由於使用了pubsub的理念，批量執行的效率相比ansible要好一些，不過執行中如果客戶機器在pub階段超時或者key認證出錯，會出現漏執行的問題，並且並不會提示你，批量執行完還需要自己人工核對一遍是不是有機器遺漏，也是操碎了心啊。反過來如果你指定要他等待所有機器的返回的話，速度反而比ansible還慢。

Ansible的好處在於默認是利用系統ssh來登錄客戶機的，如果你之前的系統許可權控制做好了，ansible必然不會超過這個紅線，connect plugin特性也允許你通過其他任何定製的連接機制與客戶端通訊，相對來說安全方向顧慮更少。

缺點是因為沒有ssh執行超時機制，很容易因為客戶端原因導致整個批量執行過程hang住，對於超過500台大集群管理並不推薦使用。另外官方對輸出的存儲和webui需求沒有做(對的，在商業版有←_←），如果你想給他做個屌屌的webui，貌似工作量還不小。

1.8以後加入了大量valut對hostvar groupvar,globalvar的支持，看起來屌屌的功能，但作為一個腳本程序，每次執行都要初始化一遍這一坨，真的是過了，我200多機器，800多個group,初始化過程等了幾分鐘都沒過去，效率真的差到家了。如果你是奔著他這個特性來的，想用它做cmdb，趁早撤。

我覺得兩個都差點意思還，哈哈哈

---

之前某些時候我需要評估配置管理系統。結合從他人得到的意見，我認為Puppet及Chef在配置和運行方面過於複雜。由於我是Python粉，所以我時常關注Ansible及Salt。Ruby目前不是我感冒的語言，當然我也不想在這裡引起語言之爭。

去年我花了6個月美好的時光用Ansible來配置伺服器。從而對這個工具變得很熟悉。在那個項目中Ansible可以說是最佳選擇，因為它易於使用，還有完整的文檔。我所工作的團隊盡量遵循文檔中指示的最佳實踐，從而使我們快速上手，而且我們可以借鑒已經被驗證過可以工作的結構。

幾周前我去日本開始為期10天的休假，在一個完全沒人認識我的地方，我有充足的時間來閱讀一些電腦雜誌和文檔。享受了美味的壽司，觀賞了東京美景，玩耍了滑雪之餘，我發現閱讀Salt PDF文檔是一個很棒的休閑。

當然我花了一些時間來試用Salt並使用了States系統。現在我認為我對兩個系統有了一個粗略的背景，我義無返顧的進行了一個具有個人色彩的測評。

術語

Salt及Ansible創建之初都被作為執行引擎。即，它們都可以在一台或多台遠程系統中執行命令，並且可以並行執行。

Ansible支持在多個機器上執行任意的命令行命令。它也支持執行模塊。一個Ansible模塊基本上是以對Ansible友好的方式編寫的Python模塊。大多數標準的Ansible模塊是冪等的。這意味著你只需告訴你的系統想要的狀態，那麼該模塊就會嘗試將你的系統調整為該狀態。

Unusable也有Playbook的概念。一個playbook是為一組主機定義了一系列模塊執行順序的文件。playbook可通過執行模塊來改變主機准櫃檯。這使得我們可以精準控制多台機器，比如在升級一個應用程序之前把機器從負載均衡器中剔除出去。

Salt有兩種模塊：執行模塊和狀態模塊。執行模塊可以簡單的執行一些命令，比如執行命令行命令，或者下載一個文件。狀態模塊與Ansible模塊更相似，通過參數定義一個狀態，而模塊則嘗試滿足該最終狀態。通常狀態模塊調用執行模塊來完成工作。

狀態模塊執行時使用state執行模塊。狀態模塊支持通過文件定義狀態，該文件被稱為SLS文件。而狀態與主機的映射關係被定義在top.sls文件中。

playbook及SLS文件（通常）都是使用YAML格式。

另外，我想指出當任務需要使用inventory,或者需要在多台機器上運行時，使用遠程執行引擎是非常有用的。

架構

Salt有一個Salt master，而很多Salt minon在初始化時會連接到該master上。通常，命令起始於master的命令行中。master然後將命令分發到minion上。初始化時，minion會交換一個秘鑰建立握手，然後建立一個持久的加密的TCP連接。我可以喋喋不休的闡述Salt如何藉助ZeroMQ庫來通訊，但簡短的來說，Salt master可以同時連接很多minion而無需擔心過載，這歸功於ZeroMQ。

由於minion和Salt master之間建立了持久化連接，所以Salt master上的命令能很快的到達minion上。minion也可以緩存多種數據，以便加速執行。

Ansible無需master，它使用SSH作為主要的通訊層。這意味著它比較慢，但無需master意味著它在設置及測試Ansible playbook上更加容易。有人也聲稱它更安全，因為它不需要額外的伺服器程序。你可以在「安全」章節獲取更多信息。

Ansible也有支持ZeroMQ的版本，但需要一個初始的SSH連接來設置。我嘗試了這個，但說實話我並沒感到速度有所提升。我猜如果playbook更大，主機更多時才會感受到速度的提升。

Ansible推薦使用inventory文件來追蹤機器。inentory文件基本上包含了一組主機，可以對其分類為組，可以對一組主機或單個主機指定屬性。你可以建立多個inventory文件，比如一個作為階段環境，另一個作為產品環境。

Salt也支持使用SSH替代ZeroMQ，即Salt SSH。但請注意目前還是試用版本（而且我還沒嘗試用過）

社區

對於這兩個項目我都有使用IRC及郵件列表的經歷。我也給它們發過補丁包，包括Python代碼及一些文檔修正。以下是我的經歷的總結：

Ansible：IRC上反饋非常快，並且很友好。但該項目貌似缺少社區影響，更像是一個人在領導，即Michael DeHaan。抱歉我這樣說，其實我很喜歡社區，因為對於改進更加開放和友好。Ansible一些改進問題還未修復就關閉了，讓我感覺它把問題隱藏了起來。好在所有的問題都有回答。

Salt需要繼續證明其歡迎社區貢獻。IRC反饋已經變得及時和友好。有時我需要藉助於郵件列表。我有一些郵件，直到4天以後才得到響應，但看起來每個郵件最終都會有跟進。

我的印象是Salt有更成熟的社區，更歡迎協作。我說這句話時可能會得罪很多人，當然這是我個人觀點！

速度

如果你以為你的伺服器比較少，速度無所謂時，我相信你是錯的。能夠快速迭代永遠是非常重要的。長期來說，配置緩慢會拖慢你的整個節奏。如果有些東西需要花費30秒以上來編譯，我會在編譯時去玩Twitter，而這意味著該編譯會其實會花掉至少120秒。部署時也會這樣。

Ansible始終使用SSH來初始化連接。這很慢。也許Ansible的ZeroMQ實現（之前提到過）會改善這點，但初始化依然會很慢。Salt默認使用ZeroMQ，所以很快。

之前說過，Salt擁有持久的minion進程。這使得Salt可以緩存文件，從而加速執行。

代碼結構

我最不能忍受的是Ansible模塊不能被導入（因為導入就會執行代碼）。這意味著測試模塊時會引入一些魔法。因為你無法導入任何一個模塊。我不喜歡魔法，而喜歡純粹簡單的代碼。這更像Salt的風格。

少用魔法意味著給Salt模塊寫測試更清晰。Salt完全可測。我很高興Salt關於測試有三個章節，包括鼓勵你mock一些你不具備的基礎設施來增加可測性，比如mock一個MySQL實例。

以上說明Ansible通常擁有簡潔乾淨的代碼。我在其中可以快速跳轉。然而，提升代碼結構不是「Ansiable社區」的關注點。

Ansible和Salt都可以通過PyPi來安裝。

Vagrant支持

當討論測試時，DevOps人喜歡Vagrant。直到現在我還沒用過它。Vagrant可以使用Slat和Ansible提供的模塊來初始化機器。這意味著在初始化機器時，Vagrant可以輕而易舉的使用master+minion模式，或者執行一個playbook。

任務編排

Ansible和Salt都支持編排，我認為Ansible中編排規則更容易理解和使用。基本上，playbook可以分割為多個任務組，每組匹配一組主機（或主機組）。每組按順序來依次執行。這與任務的執行順序相同。

Salt支持事件和反應器。這意味Salt執行可能會觸發另一個機器上的東西。Salt的執行引擎也支持監控。所以未來這塊前景比較廣闊。你可以使用Overstate在集群中以特定順序設置多種角色來實現基礎編排。

Ansible比Salt在編排方面更好，因為它簡單。Salt將來會更好，因為在集群變化中它更具持續反應性。

Salt及Ansible都支持通過機器窗口執行任務。這對於保證服務始終可用（比如升級時）是非常有用的。

安全

Ansible使用SSH來傳輸數據。SSH是經歷過考驗的協議。一旦SSH伺服器被正確配置（使用一個良好的隨機數生成器），我相信大多數人會認為SSH客戶端是安全的。

Ansible也可以輕鬆的建立多個非root用戶與單個主機的連接。如果你非常反對有進程以root許可權運行，那麼你可以考慮使用Ansible。Ansible支持使用sudo來以root方式執行模塊。所以你可以無需使用root來建立SSH連接。

Salt使用「自己」的AES實現及key管理。我想指出這裡的「自己」其實是使用PyCrypto包。Salt以前有安全問題，但同時我認為Salt架構很簡單，所以安全問題可以輕鬆的維護。

有點需要指出，Salt運行master及minion時默認以root方式。這個配置可以改，但顯而易見會導致一些新問題，比如非root模式下很難安裝Debian包。在master上你可以配置salt命令為非root模式。我極力推薦這樣做。

敏感數據

所有敏感數據應當單獨存放，然後在需要時存放在配置機器上。如果配置機器是系統管理員的機器（現在通常是筆記本電腦），那麼會有數據被盜用的風險。

經過深入的長時間思考後，我認為認證master方式是更好的選擇。這意味著敏感數據可以強制存放在一個受保護的地方（當然需要加密的備份）。Salt可以把安全證書存放在」Pillar」里。當然，破解master會是個毀滅性打擊，但是同時我們只需要安全保護一台機器。不是所有的開發者電腦都是安全的，尤其在火車上或飛機場時。

顯然，Ansible用戶可以選擇始終通過一個絕對安全的存放敏感數據的電腦上執行playbook。但人們通常會這樣做嗎？

審計能力

當討論安全時我認為審計是相當重要的。Salt在這方面比Ansible做的要好。Salt的每次執行都會在master上存放X天。這樣我們更容易調試，也容易發現可疑的事情。

部署

Ansible顯然更容易些。因為它無需部署。當然，Salt支持SSH，但文檔中大多數情況下假設我們使用ZeroMQ的方式。當然，SSH要慢些。

初始化minion的好處是這些minion都會連接到master。這使得我們可以快速初始化很多新機器。如果你想使用類似於亞馬遜的自動化彈性擴展功能時，minion-連接架構很有用。每一個自動化彈性擴展的機器將自動變為一個minion。

Salt 初始化腳本非常好用，而且執行很快。可以處理不多種分發，文檔也很豐富。

學習曲線

Ansible這方面更好。Ansible更容易學習及提高。因為我們只需拷貝一份Ansible GIT代碼庫，然後設置一些環境變數就可以執行playbook了。

Salt可以以非master模式運行。這樣可以更容易設置和運行salt。然而，對於產品環境（以及階段環境）我推薦使用master模式來運行Salt。

通體來說，Salt功能更花哨，代價是學習曲線陡峭。Salt更加模塊化。這易於組織代碼結構，但是完全精通Salt需要更多學習。

升級

升級Salt取決於當時是如何安裝Salt的。基於Debian的分發的話，有一個apt代碼庫來存放最新的Debian包。所以升級的話可以使用apt-getupgrade。對於Ubuntu機器，有PPA。這些代碼庫的維護很活躍。最新發布的2014.1.0版本一周內（時間有點長）就有了Debian/Ubuntu包。

升級Ansible更簡單。你只需簡單執行git fetch git checkout 即可。

文檔

兩個項目都有詳盡的文檔供你設置和運行，以及開發模塊及配置。過去Ansible比Salt有更好的文檔結構。最近Salt花了大力氣來重整文檔。我也貢獻了自己的力量來幫助完善這些文檔。

結語

對於我來說，Ansible是個極好的工具來自動化伺服器配置及自動化部署。設置Ansible並運行起來很簡單，而且文檔也很豐富。

進一步說，Salt具有可伸縮性，速度快，架構合理。我發現Salt的結構更適合雲端部署。將來我會毫不猶豫的使用Salt。

總的來說，你在做出選擇之前最好在你的項目中都試用下它們。反正配置及測試Ansible及Salt都非常快。

---

你想更深入了解學習Linux知識體系，你可以看一下我們花費了一個多月整理了上百小時的幾百個知識點體系內容：

【超全整理】《Linux雲計算從入門到精通》linux學習入門教程系列實戰筆記全放送

---

身邊有很多運維工程師，做了幾年的運維自動化，但依然不能確定選擇哪個工自動化工作？還有，怎樣更優雅的實施運維自動化和避免事實當中的坑？

——————

首先，我們來看一看自動化工具的比較：

Puppet也許是四款工具中最深入人心的。就可用操作、模塊和用戶界面而言，它是最全面的。Puppet呈現了數據中心協調的全貌，幾乎涵蓋每一個運行系統，為各大操作系統提供了深入的工具。初始設置比較簡單，只需要在需要加以管理的每個系統上安裝主伺服器和客戶端代理軟體。命令行介面(CLI)簡單直觀，允許通過puppet命令下載和安裝模塊。然後，需要對配置文件進行更改，好讓模塊適合所需的任務;應接到指令的客戶端與主伺服器聯繫時，會更改配置文件，或者客戶端通過立即觸發更改配置文件的推送(push)來進行更改。

Ansible關注的重點是力求精簡和快速，而且不需要在節點上安裝代理軟體。因此，Ansible通過SSH執行所有功能。需要管理的節點被添加到Ansible配置環境，SSH授權密鑰被附加到每個節點上，這與運行Ansible的用戶有關。一旦完成了這步，Ansible主伺服器可以通過SSH與節點進行通信，執行所有必要的任務。Ansible可以使用Paramiko(基於SSH2協議的Python實現)或標準SSH用於通信，不過還有一種加速模式，允許更快速、更大規模的通信。

Salt類似Ansible，因為它也是基於CLI的工具，採用了推送方法實現客戶端通信。它可以通過Git或通過程序包管理系統安裝到主伺服器和客戶端上。客戶端會向主伺服器提出請求，請求在主伺服器上得到接受後，就可以控制該客戶端了。Salt可以通過普通的SSH與客戶端進行通信，但如果使用名為minion的客戶端代理軟體，可以大大增強可擴展性。此外，Salt含有一個非同步文件伺服器，可以為客戶端加快文件服務速度，這完全是Salt注重高擴展性的一個體現。與Ansible一樣，你可以直接通過CLI，向客戶端發出命令，比如啟動服務或安裝程序包;你也可以使用名為state的YAML配置文件，處理比較複雜的任務。還有「pillar」，這些是放在集中地方的數據集，YAML配置文件可以在運行期間訪問它們。

總結：個人觀點puppet最大缺點就是默認情況下Agent每隔30分鐘向master同步狀態，master主動推送功能比較薄弱(2.7版本），ansible基於SSH服務執行，如果伺服器過多不建議使用，他是使用輪訓的方式。Salt基於消息隊列。性能相當好，適合大量生產環境。

SaltStack簡介與特性

SaltStack 是一種基於 C/S 架構的伺服器基礎架構集中化管理平台，管理端稱為 Master，客戶端稱為 Minion。SaltStack 具備配置管理、遠程執行、監控等功能，一般可以理解為是簡化版的 Puppet 和加強版的 Func。SaltStack 本身是基於 Python 語言開發實現，結合了輕量級的消息隊列軟體 ZeroMQ 與 Python 第三方模塊（Pyzmq、PyCrypto、Pyjinjia2、python-msgpack 和 PyYAML 等）構建。

通過部署 SaltStack 環境，運維人員可以在成千上萬台伺服器上做到批量執行命令，根據不同的業務特性進行配置集中化管理、分發文件、採集系統數據及軟體包的安裝與管理等。

SaltStack 具有以下特性：

1、部署簡單、方便；

2、支持大部分UNIX/Linux及Windows環境；

3、主從集中化管理；

4、配置簡單、功能強大、擴展性強；

5、主控端（master）和被控端（minion）基於證書認證，安全可靠。

6、支持API及自定義模塊，可通過Python輕鬆擴展。

SaltStack 的工作原理

SaltStack 採用 C/S 結構來對雲環境內的伺服器操作管理及配置管理。為了更好的理解它的工作方式及管理模型，將通過圖形方式對其原理進行闡述。

SaltStack 客戶端（Minion）在啟動時，會自動生成一套密鑰，包含私鑰和公鑰。之後將公鑰發送給伺服器端，伺服器端驗證並接受公鑰，以此來建立可靠且加密的通信連接。同時通過消息隊列 ZeroMQ 在客戶端與服務端之間建立消息發布連接。具體通信原理圖，如圖 1 所示，命令執行如圖 2 所示：

專業術語說明：

Minion 是 SaltStack 需要管理的客戶端安裝組件，會主動去連接 Master 端，並從 Master 端得到資源狀態信息，同步資源管理信息。

Master 作為控制中心運行在主機伺服器上，負責 Salt 命令運行和資源狀態的管理。

ZeroMQ 是一款開源的消息隊列軟體，用於在 Minion 端與 Master 端建立系統通信橋樑。

Daemon 是運行於每一個成員內的守護進程，承擔著發布消息及通信埠監聽的功能。

原理圖說明：

Minion 是 SaltStack 需要管理的客戶端安裝組件，會主動去連接 Master 端，並從 Master 端得到資源狀態信息，同步資源管理信息。

Master 作為控制中心運行在主機伺服器上，負責 Salt 命令運行和資源狀態的管理。

Master 上執行某條指令通過隊列下發到各個 Minions 去執行，並返回結果。

SaltStack 的架構設計

為了讓大家更好的理解 SaltStack 集中化管理方面的優勢，因此，根據項目的實際情況繪製了部署架構圖，並在文中對架構圖進行了詳細說明。如圖 3 所示：

說明：

SaltStack 的所有被管理客戶端節點（如圖 3 所示 DB 和 Web），都是通過密鑰進行加密通信，使用埠為 4506。客戶端與伺服器端的內容傳輸，是通過消息隊列完成，使用埠為 4505。Master 可以發送任何指令讓 Minion 執行，salt 有很多可執行模塊，比如說 CMD 模塊，在安裝 minion 的時候已經自帶了，它們通常位於你的 python 庫中，locate salt | grep /usr/ 可以看到 salt 自帶的所有東西。

為了更好的理解架構用意，以下將展示主要的命令發布過程：

SaltStack 的 Master 與 Minion 之間通過 ZeroMq 進行消息傳遞，使用了 ZeroMq 的發布訂閱模式，連接方式包括 TCP 和 IPC。

Salt 命令，將 cmd.run ls 命令從 salt.client.LocalClient.cmd_cli 發布到 Master，獲取一個 Jodid，根據 jobid 獲取命令執行結果。

Master 接收到命令後，將要執行的命令發送給客戶端 minion。

Minion 從消息匯流排上接收到要處理的命令，交給 minion._handle_aes 處理。

Minion._handle_aes 發起一個本地線程調用 cmdmod 執行 ls 命令。線程執行完 ls 後，調用 Minion._return_pub 方法，將執行結果通過消息匯流排返回給 master。

Master 接收到客戶端返回的結果，調用 master.handle_aes 方法將結果寫的文件中。

Salt.client.LocalClient.cmd_cli 通過輪詢獲取 Job 執行結果，將結果輸出到終端。

SaltStack 的安裝與配置

對 SaltStack 有了一個初步的了解之後，通過實際案例操作進一步了解 SaltStack。

一、安裝Salt

Salt需要epel源支持，所有安裝前需要先安裝epel源包。

1、salt-master

# yum -y install salt-master

2、salt-minion

# yum -y install salt-minion

二、配置Salt

1、master(/etc/salt/master)

# salt運行的用戶，影響到salt的執行許可權

user: root

#salt的運行線程，開的線程越多一般處理的速度越快，但一般不要超過CPU的個數

worker_threads: 10

# master的管理埠

publish_port : 4505

# master跟minion的通訊埠，用於文件服務，認證，接受返回結果等

ret_port : 4506

# 如果這個master運行的salt-syndic連接到了一個更高層級的master,那麼這個參數需要配置成連接到的這個高層級master的監聽埠

syndic_master_port : 4506

# 指定pid文件位置

pidfile: /var/run/salt-master.pid

# saltstack 可以控制的文件系統的開始位置

root_dir: /

# 日誌文件地址

log_file: /var/log/salt_master.log

# 分組設置

nodegroups:

group_all: "*"

# salt state執行時候的根目錄

file_roots:

base:

- /etc/salt/

# 設置pillar 的根目錄

pillar_roots:

base:

- /etc/pillar

2、配置minion(/etc/salt/minion)

master: mail #這塊的mail指的是在/etc/hosts文件中所定義的主機名

id: node1

3、啟動salt

service salt-master start

service salt-minion start

# saltstack 是使用python2的語言編寫，對python3的兼容性不好，請使用python2的環境

4、認證命令介紹

salt-key #證書管理

# salt-key –L #查看所有minion-key

# salt-key –a #接受某個minion-key

# salt-key –A #接受所有minion-key

# salt-key –d #刪除某個minion-key

# salt-key –D #刪除所有minion-key

5、salt命令介紹

命令格式：salt [options] [arguments]

例：salt * cmd.run "uptime"

SaltStack minion匹配方式

1、 Glob（salt默認的target類型，使用shell的通配符來指定一個或多個Minion ID）

# salt * test.ping 或 salt 『*』 test.ping

2、pcre兼容正則表達式

# salt –E 『^[m|M]in.[e|o|u]n$』 test.ping

3、Subnet(通過指定一個IPv4地址或一個CIDR的IPv4子網)

# salt –S 192.168.0.42 test.ping

# salt –s 192.168.0.0/16 test.ping

4、Grains(salt可以通過操作系統、CPU架構及自定義信息等機器特徵進行target Minion)

# salt –G 『os:Ubuntu』 test.ping

# Salt –G 『os_family:Debian』 test.ping

5、pillar（salt支持通過pillar數據進行匹配）

# Salt –I 『my_val:my_val』 test.ping

6、混合（compound)

# Salt –C 『web* or G@os:Arch』 test.ping

7、節點組（Nodegroup）

節點組需要事先定義，配置方法如下：

# vim /etc/salt/master

nodegroups:

node: "L@node1,node2』

# salt -N node test.ping

SaltStack常用模塊

1、status模塊（查看系統信息）

# salt "*" status.diskstats #查看磁碟信息

# salt "*" status.meminfo #查看內存信息

# salt "*" status.w #w命令返回信息

2、查看所有module列表

3、查看指定module的所有function方法

4、查看指定module用法

5、具體模塊的使用（例子）

同時到指定機器查看

cmd.run模塊的使用

Grains

Static bits of information that a minion collects about the system when the minion first starts.

The grains interface is made available to Salt modules and components so that the right salt minion commands are automatically available on the right systems.

以上是官方的解釋，大致意思是說grains是minion第一次啟動的時候採集的靜態數據，可以用在salt的模塊和其他組件中。例如，當os_family的Grain數據為Centos時，則會使用yum工具組件來進行軟體包管理。Grains會在Minion進程啟動時載入，並緩存在內存中。這樣salt-minion進程就無須每次操作都重新檢索系統來獲取Grain，極大的提高了Minion的性能。

1、我們這裡簡單做一個輸出測試，可以看到minion節點的一些信息如下：

查看具體每一項信息

2、應用場景：

grains的特性–每次啟動彙報、靜態決定了它沒有pillar靈活，要知道pillar是隨時可變的，只要在master端修改了那一般都會立刻生效的。所以grains更適合做一些靜態的屬性值的採集，例如設備的角色(role)，磁碟個數(disk_num），操作系統版本等諸如此類非常固定的屬性。簡單總結起來grains的用途如下：

（1），grains可以在state系統應用中，用戶配置管理模塊。

（2），grains可以在target中使用，用來匹配minion，比如os，用-G。

（3），grains可以用於信息查詢，grains保存著收集到的客戶端的信息。

那麼我們就可以得到一個大致的判斷，如果你想定義的屬性值是經常變化的，那請採用pillar，如果是很固定、不易變的那請用grains。

3、grains優先順序

grains可以保持在minion端、通過master端下發等多個方式來分發。但不同的方法有不同的優先順序的(由低到高)：

（1）. /etc/salt/grains

（2） /etc/salt/minion

（3）./srv/salt/_grains/ master端_grains目錄下

優先順序順序依次為存在在minion端/etc/salt/minion配置文件中的同名grains會覆蓋/etc/salt/grains文件中的值，而通過master端_grains目錄下grains文件下發的值可以會覆蓋minion端的所有同名值。比較拗口，總之記得，通過master下發的grains優先順序是最高的可，/etc/salt/minion次之，/etc/salt/grains最低（core grains不大懂，就不討論了，這個比/etc/salt/grains還低）。

4、grains的下發

grains的下發大致可以分為兩個思路：

(1)自定義的（_grains）可以通過state.highstate、saltutil.sync_grains、saltutil.sync_all 等方法批量下發，切記所有在_grains目錄下的所有自定義grains值都會下發到minion，這是血的教訓。

(2)固定存放在minion端配置文件中，如grains、minion文件中，可以通過file manager的方法去批量下發/etc/salt/grains等配置文件實現grains的批量下發，當然了也通過別的方式把這個文件批量下發下去，都是ok的。

對比：

（1）通過state.highstate 下發的grains好處是無須重啟minion即可生效，但通過下發/etc/salt/grains文件下發的grains值則必須重啟minion端服務才可以生效。

（2）自定義的_grains每次在highstate調用的時候就會自動下發、刷新，而/etc/salt/grains文件的則不會。

Pillar

在大多數場景中，Pillar的表現行為和Grain一致，但有個很大的區別是：Pillar在Master上進行定義，存在於一個集中化的路徑。Pillar數據是與特定minion關聯的，也就是說每一個minion都只能看到自己的數據，所以Pillar可以用來傳遞敏感數據（在Salt的設計中，Pillar使用獨立的加密session，也是為了保證敏感數據的安全性）。

Pillar可以用在那些地方：

1、敏感數據

例如ssh key，加密證書等，由於Pillar使用獨立的加密session，可以確保這些敏感數據不被其他minion看到。

2、變數

可以在Pillar中處理平台差異性，比如針對不同的操作系統設置軟體包的名字，然後在State中引用。

3、其他任何數據

可以在Pillar中添加任何需要用到的數據。比如定義用戶和UID的對應關係，mnion的角色等。

4、用在Targetting中

Pillar可以用來選擇minion，使用-I選項。

定義Pillar：

master配置文件中定義：

默認情況下，master配置文件中的所有數據都添加到Pillar中，且對所有minion可用。如果要禁用這一默認值，可以在master配置文件中添加如下數據，重啟服務後生效：

pillar_opts: False

使用SLS文件定義Pillar

Pillar使用與State相似的SLS文件。Pillar文件放在master配置文件中pillar_roots定義的目錄下。示例如下：

pillar_roots:

base:

- /srv/pillar

下面這段代碼定義了base環境下的Pillar文件保存在/srv/pillar/目錄下。與State相似，Pillar也有top file，也使用相同的匹配方式將數據應用到minion上。示例如下：

# cat /srv/pillar/top.sls:

base:

"*":

- packages

# cat /srv/pillar/packages.sls:

{% if grains["os"] == "RedHat" %}

apache: httpd

git: git

{% elif grains["os"] == "Debian" %}

apache: apache2

git: git-core

{% endif %}

base環境中所有的minion都具有packages中定義的數據。Pillar採用與file server相同的文件映射方式，在本例中，packages映射到文件/srv/pillar/packages.sls。注意key與value要用冒號加空格分隔，沒有空格的話將解析失敗。

如何知道minion擁有那些Pillar數據？

在Master上修改pillar文件後，需要用以下命令刷新minion上的數據：

使用Pillar獲取自定義數據：

State

簡述：SLS（代表SaLt State文件）是Salt State系統的核心。SLS描述了系統的目標狀態，由格式簡單的數據構成。這經常被稱作配置管理

top.sls是配置管理的入口文件，一切都是從這裡開始，在master 主機上，默認存放在/srv/salt/目錄.

top.sls 默認從 base 標籤開始解析執行,下一級是操作的目標，可以通過正則，grain模塊,或分組名,來進行匹配,再下一級是要執行的state文件，不包換擴展名。

創建/srv/salt/top.sls

以上內容是前兩天我們一個Linux運維的社群組織了一場微信的講座，恰好說到這個問題，可以供大家參考，本次分享邀請的是一個一線的運維工程師，他叫張強，馬哥教育Linux大咖講堂金牌講師，現就職於夥伴智慧運維工程師，負責主線業務平台，3年linux一線經驗，擅長shell腳本、自動化_發布、web應用等，現在關注自動化運維、分散式資料庫，虛擬化技術。

內容基於一線分享的體驗，每個人體驗不同，歡迎大家交流。

最後給一個實戰結尾：

state實戰

---

轉我在另外一個問題下的答案供參考。

這兩個工具大致的對比如下：

1、是否需要每台機器部署agent（客戶端）

很多選用ansible的朋友，都是因為agentless這個原因，覺得要維護agent很麻煩。

而一些使用saltstack比較順的朋友，覺得這個問題無所謂，agent出問題的概率有，但不高。

其實ansible也支持agent的方式，即所謂的「pull」的模式，就是通過一個客戶端去拉取要執行的任務。

2、大規模並發的能力

這方面的對比已經比較多了，因為實現機制的差異，也導致saltstack在這方面是佔優的。

不過對於幾十台-200台規模的兄弟來講，ansible的性能也可接受。

註：我前期調研的大多數都是中下企業，伺服器規模一般不超過200台，所以對這個問題不算太看重。如果一次操作的機器過千台，可能還是用saltstack效率更高一些。

補充-20161114：我們正在改造ansible的執行架構，採用基於MQ的agent機制，以支持比較大規模（1000-10000台）的伺服器的批量自動化運維。這樣，在這種存在大規模運維的需求的客戶這裡，也可以應用豐富的ansible的Playbook了。

3、二次開發擴展的能力

ansible和saltstack都是基於python的，而python在運維開發這個圈子裡接受度還是非常高的，二次開發的人員相對也好招。

這也是這兩個工具相對於puppet和chef更容易被接受度原因，這兩個曾經的主流工具都是基於ruby，而現在ruby的活躍度越來越低了，要招人也不容易。

ansible和saltstack都具備很好的二次開發擴展能力，可以寫YAML編排。

4、開源社區的對接

在github上，ansbile有18300多顆星，salt有6700多顆星。

直接按關鍵字搜索，ansible的相關項目也更多一些。

這些指標雖然不能直接說明什麼，但很多技術人員會關注自己所使用的技術的活躍度。

一般來說，越活躍的開源項目，得到的關注會更高些，功能完善和問題解決的效率也會更高。

5、學習的門檻

從第一次使用來講，ansible的部署配置會更簡單一些。

從官方文檔的質量來看，saltstack就比ansible要好一些。

從國內的中文資料來說，ansbile和saltstack好像各有2-3本中文書。

這兩家的國內用戶組也分別在做一些技術資料翻譯的工作。

6、操作界面的友好程度

試用過Ansible的Tower，但實在是不喜歡這種操作習慣，只能說勉強可用。

saltstack的沒仔細用過，但看過朋友搭建的環境，感覺官方的UI還可以，基本夠用了。

Ansible的最初設計定位就不是一個完整的運維管理系統，因此官方UI粗糙些也在預料之中。

7、第三方工具的豐富程度

ansibe有一個galaxy站點：Ansible Galaxy

這個站點集合了3000多個第三方開發的Role/Playbook。

salt也有一些預先寫好的Formulas（Formulas are pre-written Salt States）

官方地址：Salt Formulas

github地址：Salt Stack Formulas · GitHub

目前已有的Formulas大概在200個左右，比ansible galaxy少了一個數量級，不過大部分常用軟體也覆蓋到了。

8、現有用戶使用的規模

根據rightscale的調研報告：

Ansible在2015年有10%的用戶選用，而2016年有20%的用戶選用。

Saltstack在2015年有6%的用戶選用，而2016年有9%的用戶選用。

9、對Windows支持的友好程度

這一方面我沒有直接的經驗，感謝 @小菘Barry 提供的如下反饋：

「ansible對windows的支持簡直不忍直視，agentless只是對於linux的，windows要安裝bug修復補丁，powershell還要3.0，還要安裝python。還不如salt方便。」

這一點供大家參考。

我們自己目前是用的Ansible，但正在結合我們自己的DevOps平台，重新給Ansible開發一套WEB UI。

---

用過ansible-2.1和salt-2016.03

1. ansible，salt在並發多的時候都會出現部分任務執行失敗的情況

2. Salt針對多個區域網環境有分級控制（syndic）的概念，但是實際上還是需要把對應的sls傳到對應的syndic上面，感覺有點雞肋。而ansible需要控制機與被控制機能夠ssh直連，可以用proxycommand通過跳板機假裝直連。

3. ansible通過控制ssh來實現賬號許可權管理，Salt自帶帳號許可權機制。

4. ansible沒有守護進程，平台化基本上就是二次開發，或者調用exec。Salt有http介面開放。

5. ansible沒有agent，只需要對應賬號的ssh許可權。Salt需要開放額外埠

建議：

機器少，自己玩，用ansible

機器多，平台化，上Salt

---

百台規模而已，兩種都用過，並沒有太大的坑，千台和萬台才是挑戰

---

然而我哪個都不會用……

我又不是 SA …… 看個手冊寫個 example 的時間都超過了我自己裸寫一套的時間...

於是我就自己寫了一個- -

要我說啊，非 SSH 系的最蛋疼的就是可控性，SSH 系的蛋疼的在於，都是 paramiko 這個項目衍生出來的，有必要搞那麼複雜和那麼重么……

---

ansible的坑在於執行流程。比如你想在一台機器上操作3個步驟。那麼這3個步驟不是同時在一台機器上執行完畢再去執行下一台的。而是第1步驟在所有機器上執行完成了，然後才執行第2步驟所有機器，第3步驟所有機器。況且ansible太依賴於網路的穩定性了，稍有抖動即斷連，所以我每次指操作都要執行好幾次。

總體來說ansible算是比較輕量級的批量管理工具了，相對於puppet、saltstack不用安裝客戶端。只需配置個ssh互信即可，安全性得到比較好的掌控。

目前我只在200+的機器上使用ansible，對於500+以上的未有機會嘗試。

---

3千到4千的規模 用salt嘗嘗出現莫名慢的問題 非常不好定位

另外 自帶的超時 完全不管用啊！！

現在考慮換其他了

---

適合自己就是最好的、

---

standalone puppet

---

初用ansible，還沒發現坑

---

推薦閱讀：