隨著服務器集群規模越來越大，自動化配置和部署這些服務器能夠使管理變得非常容易并大大減小管理部署成本，因而得到 IT 公司的高度重視。

目前，市場上主流的四大開源自動化配置管理工具有：Puppet、Chef、Ansible、SaltStack。

1 . 如何駕馭這些工具為己所用？

2 . 如何根據不同的應用環境來選用不同的工具？

3 . 如何根據應用來組合使用工具？

以下對這四款工具逐一剖析：

Puppet??

Puppet 也許是四款工具中最深入人心的。就可用操作、模塊和用戶界面而言，它是最全面的。Puppet 呈現了數據中心協調的全貌，幾乎涵蓋每一個運行系統，為各大操作系統提供了深入的工具。初始設置比較簡單，只需要在需要加以管理的每個系統上安裝主服務器和客戶端代理軟件。

命令行接口 ( CLI ) 簡單直觀，允許通過 Puppet 命令下載和安裝模塊。然后，需要對配置文件進行更改，好讓模塊適合所需的任務；應接到指令的客戶端與主服務器聯系時，會更改配置文件，或者客戶端通過立即觸發更改配置文件的推送 ( push ) 來進行更改。

還有一些模塊可以提供和配置云服務器實例和虛擬服務器實例。所有模塊和配置都使用基于 Ruby 的 Puppet 專屬語言或者 Ruby 本身構建而成，因而除了系統管理技能外，還需要編程專業知識。

Puppet 企業版擁有最全面的 Web 用戶界面，允許使用主服務器上的預制模塊和菜譜 ( cookbook )，實時控制被管理的節點。Web 用戶界面很適合用于管理，但是不允許對模塊進行諸多配置。報告工具非常完善，提供了詳細信息，以便了解代理軟件運行如何、已做出什么樣的變更。

Chef??

Chef 的總體概念類似 Puppet，因為在被管理的節點上安裝有主服務器和代理軟件，但實際部署又不一樣。除了主服務器外，安裝的 Chef 環境還需要工作站來控制主服務器。代理軟件可以借助使用 SSH 來部署的 knife 工具從工作站加以安裝，減輕了安裝負擔。之后，被管理的節點通過使用證書，完成與主服務器之間的驗證。

Chef 的配置離不開 Git，所以對 Chef 運作而言，了解 Git 如何工作是先決條件。與 Puppet 一樣，Chef 同樣基于 Ruby，所以還需要了解 Ruby。與 Puppet 一樣，模塊可以下載，也可以從頭開始編寫，可以在所需配置之后部署到被管理的節點。

與 Puppet 不一樣，Chef 還沒有一項完善的推送功能，不過提供了測試版代碼。這意味著需要配置代理軟件，以便與主服務器進行聯系，實際上不可能立即應用變更的內容。

企業版 Chef 的 Web 用戶界面很實用，但不提供更改配置的功能。這個 Web 用戶界面不如 Puppet 企業版來得全面，缺少報告及其他功能，但允許庫存控制和節點組織。

與 Puppet 一樣，Chef 得益于一大批的模塊和配置菜譜，那些模塊和配置菜譜又高度依賴 Ruby。由于這個原因，Chef 非常適合注重開發的基礎設施。

Ansible??

Ansible 極其類似 SaltStack ，而不太類似 Puppet 或 Chef 。Ansible 關注的重點是力求精簡和快速，而且不需要在節點上安裝代理軟件。因此，Ansible 通過 SSH 執行所有功能。Ansible 基于 Python；相比之下，Puppet 和 Chef 基于 Ruby。

Ansible 可以通過 Git 軟件庫克隆，安裝到 Ansible 主服務器上。安裝完畢后，需要管理的節點被添加到 Ansible 配置環境，SSH 授權密鑰被附加到每個節點上，這與運行 Ansible 的用戶有關。一旦完成了這步，Ansible 主服務器可以通過 SSH 與節點進行通信，執行所有必要的任務。為了與默認情況下不允許根 SSH 訪問的操作系統或發行版協同運行，Ansible 接受 sudo 登錄信息，以便在那些系統上以根用戶的身份運行命令。

Ansible 可以使用 Paramiko (基于 SSH2 協議的 Python 實現) 或標準 SSH 用于通信，不過還有一種加速模式，允許更快速、更大規模的通信。

針對確保服務在運行，或者觸發更新和重新啟動之類的簡單任務，Ansible 可以從命令行來運行，不需要使用配置文件。至于比較復雜的任務，Ansible 配置通過名為 Playbook 的配置文件中的 YAML 語法來加以處理。Playbook 還可以使用模板來擴展其功能。

Ansible 有一大批模塊，可用于管理各種系統以及亞馬遜彈性計算云 ( EC2 ) 和 OpenStack 等云計算基礎設施。可以用幾乎任何一種語言來編寫自定義 Ansible 模塊，只要模塊輸出是有效的 JSON。

Ansible 的 Web 用戶界面以 AnsibleWorks AWX 的形式出現，但 AWX 與 CLI 并不直接聯系在一起。這意味著，除非進行了同步過程，否則 CLI 里面的配置元素不會出現在 Web 用戶界面中。你可以使用那個內置的同步工具，讓兩者保持一致，但需要按照預定計劃運行同步工具。

SaltStack??

SaltStack 類似 Ansible，因為它也是基于 CLI 的工具，采用了推送方法實現客戶端通信。它可以通過 Git 或通過程序包管理系統安裝到主服務器和客戶端上。客戶端會向主服務器提出請求，請求在主服務器上得到接受后，就可以控制該客戶端了。

SaltStack 可以通過普通的 SSH 與客戶端進行通信，但如果使用名為 minion 的客戶端代理軟件，可以大大增強可擴展性。此外，SaltStack 含有一個異步文件服務器，可以為客戶端加快文件服務速度，這完全是 SaltStack 注重高擴展性的一個體現。

SaltStack 與 Ansible 一樣，你可以直接通過 CLI，向客戶端發出命令，比如啟動服務或安裝程序包 ; 你也可以使用名為 state 的 YAML 配置文件，處理比較復雜的任務。還有“ pillar ”，這些是放在集中地方的數據集，YAML 配置文件可以在運行期間訪問它們。

你可以直接通過 CLI，向客戶端請求配置信息，比如內核版本或網絡接口方面的詳細信息。只要使用名為“ grain ”的庫存元素，就可以描述客戶端 ; 這樣一來，管理員可以輕松向某一種類型的服務器發出命令，不需要依賴已配置群組。比如說，只要使用一個 CLI 命令，你就可以向運行某個內核版本的每個客戶端發送命令。

與 Puppet、Chef 和 Ansible 一樣，SaltStack 也提供了大量的模塊，以處理特定的軟件、操作系統和云服務。自定義模塊可以用 Python 或 PyDSL 來編寫。除了 Unix 管理外，SaltStack 的確提供 Windows 管理功能，但它還是更擅長管理 Unix 和 Linux 系統。

SaltStack 的 Web 用戶界面 Halite 非常新，功能不如其他系統的 Web 用戶界面來得全面。它提供了事件日志和客戶端狀態的視圖，能夠在客戶端上運行命令，但除此之外乏善可陳。

SaltStack 的較大優點在于可擴展性和彈性。你可以有多個級別的主服務器。上游主服務器可以控制下游主服務器及其客戶端。另一個優點在于對等系統，讓客戶端可以向主服務器提出問題，然后主服務器從其他服務器得到答案，提供全面信息。如果需要在實時數據庫中查詢數據，以便完成客戶端的配置，這個優點就很方便。

工具只是輔助人進行運維的，這中間還需要人的干預和決策，工具并不能完全代替全部運維工作，還需要結合實際業務邏輯和業務場景，就像架構一樣，并不是淘寶、百度等大公司的架構，一定適合任何公司和業務。

寫在最后：??

自動化的實現不是單純學習幾個工具就能夠做好的，甚至于規劃不好的情況，自動化不僅沒有節省人力，反而帶來了更多的問題。

所以運維人員在考慮自動化流程的過程中應該注重以下幾點：

1 . 根據應用選擇工具。

2 . 對于關鍵應用，選擇成熟度高的工具。

3 . 不能過分依賴一種工具，需要進行對比和分析。

4 . 對工具的特性做到精通。

5 . 是人駕馭工具，人要監督工具，而不是工具來駕馭人。

6 . 善于利用腳本實現定制化場景。

總結

以上是生活随笔為你收集整理的Puppet SaltStack Chef Ansible的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。