虛擬化技術日益普及，基於行業標准的服務器功能越來越強大，加上雲計算的出現，這些因素共同導致了企業內外需要加以管理的服務器數量大幅增長。過去我們只要管理內部數據中心里面的物理服務器機架，而現在我們要管理多得多的服務器，它們有可能遍布全球各地。
這時候，數據中心協調和配置管理工具就派得上用場。在許多情況下，我們管理大批同樣的服務器，它們運行同樣的應用程序和服務。這些服務器部署在企業內部的虛擬化框架上，或者作為雲計算或托管實例在遠程數據中心運行。在一些情況下，我們可能談論的是完全為了支持超大應用系統而存在的大型環境，或者是支持無數小型服務的大型環境。不管怎么樣，讓它們都乖乖聽從管理員的指揮這種能力不可小視。這是管理這些越來越龐大的基礎設施的唯一方式。
Puppet、Chef、Ansible和Salt都是為了實現這個目標而開發的：讓用戶極容易配置和維護數十台、數百台、乃至數千台服務器。這倒不是說小公司就不會得益於這些工具，因為自動化和協調技術通常可以簡化任何規模的基礎設施的正常運行。
深入測評這四款工具中的每一款，探究各自的設計和功能，可以發現：雖然一些工具的得分更高，但每款工具都有一席之地，這取決於部署的目的。
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非常適合注重開發的基礎設施。
AnsibleWorks Ansible
Ansible極其類似Salt，而不太類似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企業版
Salt類似Ansible，因為它也是基於CLI的工具，采用了推送方法實現客戶端通信。它可以通過Git或通過程序包管理系統安裝到主服務器和客戶端上。客戶端會向主服務器提出請求，請求在主服務器上得到接受后，就可以控制該客戶端了。
Salt可以通過普通的SSH與客戶端進行通信，但如果使用名為minion的客戶端代理軟件，可以大大增強可擴展性。此外，Salt含有一個異步文件服務器，可以為客戶端加快文件服務速度，這完全是Salt注重高擴展性的一個體現。
與Ansible一樣，你可以直接通過CLI，向客戶端發出命令，比如啟動服務或安裝程序包;你也可以使用名為state的YAML配置文件，處理比較復雜的任務。還有“pillar”，這些是放在集中地方的數據集，YAML配置文件可以在運行期間訪問它們。
你可以直接通過CLI，向客戶端請求配置信息，比如內核版本或網絡接口方面的詳細信息。只要使用名為“grain”的庫存元素，就可以描述客戶端;這樣一來，管理員可以輕松向某一種類型的服務器發出命令，不需要依賴已配置群組。比如說，只要使用一個CLI命令，你就可以向運行某個內核版本的每個客戶端發送命令。
與Puppet、Chef和Ansible一樣，Salt也提供了大量的模塊，以處理特定的軟件、操作系統和雲服務。自定義模塊可以用Python或PyDSL來編寫。除了Unix管理外，Salt的確提供Windows管理功能，但它還是更擅長管理Unix和Linux系統。
Salt的Web用戶界面Halite非常新，功能不如其他系統的Web用戶界面來得全面。它提供了事件日志和客戶端狀態的視圖，能夠在客戶端上運行命令，但除此之外乏善可陳。
Salt的最大優點在於可擴展性和彈性。你可以有多個級別的主服務器。上游主服務器可以控制下游主服務器及其客戶端。另一個優點在於對等系統，讓客戶端可以向主服務器提出問題，然后主服務器從其他服務器得到答案，提供全面信息。如果需要在實時數據庫中查詢數據，以便完成客戶端的配置，這個優點就很方便。
選用Puppet、Chef、Ansible還是Salt?
Puppet和Chef會吸引廣大開發人員和注重開發的公司，而Salt和Ansible極其適合系統管理員的要求。Ansible的簡潔界面和可用性非常迎合系統管理員的想法;而在擁有許多Linux和Unix系統的公司，Ansible運行起來一開始就快速又輕松。
Salt是四款工具中最漂亮最穩健的;與Ansible一樣，它也會博得系統管理員的芳心。Salt擁有高擴展性和強大功能，唯一的軟肋就是Web用戶界面。
Puppet是這四款工具中最成熟的，從可用性的角度來看恐怕也最容易上手，不過竭力建議你對Ruby要有深入了解。Puppet不如Ansible或Salt來得精簡，配置起來有時會變得錯綜復雜。對異構環境來說，Puppet是最穩妥的選擇，但是你可能會發覺Ansible或Salt比較適合更龐大或更一致的基礎設施。
Chef擁有穩定的、精心設計的布局，雖然它在原始功能方面遠未達到Puppet的水平，但這是款功能非常強大的解決方案。要是管理員缺乏豐富的編程經驗，Chef學起來可能最困難，但它也許最適合注重開發的管理員和開發部門。