我們發現分散式是一個發展的趨勢，無論是大型網站的負載均衡架構還是大資料框架部署，以及雲端儲存計算系統搭建都離不開多臺伺服器的連續部署和環境搭建。

當我們的基礎架構是分散式或者基於雲的，並且我們經常需要處理在大部分相同的伺服器上頻繁部署大致相同的服務時，我們就應該考慮自動化配置和維護了。

讓使用者極容易配置和維護數十臺、數百臺、乃至數千臺伺服器。
幸運的是，現在有很多運維管理工具是為此目的而設計的，它們能夠讓我們使用配方，模板，劇本（或者其他描述）來簡化環境搭建中的自動化和編排，以提供標準，一致的部署。

我們現在面臨的問題不是沒有選擇，而是選擇太多。

所以在選擇工具時，需要明確的是我們的需求，需要集中型的管理還是分散式的管理，還有環境的組成，一些工具以不同的語言編寫，並且對特定作業系統或設定的支援可以不同。 最後確保我們選擇的工具與我們的環境和我們的團隊的特殊技能很好地融合在一起可以為我們節省很多精力。

下面我們分別來簡單瞭解下這幾種工具並且做對比。
Ansible
簡介

官網https://www.ansible.com/
Ansible介紹視訊： https://www.youtube.com/watch?v=iVWmbStE1MM

Ansible是用於在可重複的方式將應用程式部署到遠端節點和配置伺服器的開源工具。 它為您提供了使用推送模型設定推送多層應用程式和應用程式工件的通用框架，但如果願意，您可以將其設定為主客戶端。 Ansible是建立在playbooks，你可以應用於各種各樣的系統部署你的應用程式。

這是Ansible Tower儀表板。

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使用者介面中。你可以使用那個內建的同步工具，讓兩者保持一致，但需要按照預定計劃運行同步工具。
何時使用

如果快速執行，方便對你很重要，我們不想把運維工具安裝在遠端節點或託管伺服器代理商那裡，那可以考慮Ansible。 Ansible專注於精簡和快速，所以如果這些是我們的關鍵問題，可以考慮一下Ansible。

ansible比較適合做“一次性”的工作，例如，系統部署、應用釋出、打補丁等等。
在企業中使用ansible，要注意以下幾點：
1. 安全控制，簡單來說就是避免用root使用者來執行。
2. 控制好依賴 在寫playbook的時候，控制好先後順序和依賴關係。
3. 結果的收集和分析 因為一下子幾百臺機器一起幹活，所以，就要自己寫外接指令碼，更好地收集ansible的操作結果，並且進行直觀的彙總和展現。
價格

有免費的開源版本支援10個節點以內的叢集，付費的Ansible Tower在$ 5,000每年（它給你多達100個節點）支付計劃。
優點

基於SSH，因此不需要在遠端節點上安裝任何代理。
使用YAML語法易於學習。
Playbook結構簡單，結構清晰。
具有可變註冊功能，可使任務為以後的任務註冊變數
比一些其他工具更加精簡的程式碼庫
缺點

不如基於其他程式語言的工具強大。
它的邏輯通過它的DSL，這意味著需要經常檢查文件
即使是基本功能，也需要變數註冊，這使得更簡單的任務更復雜
內省很差。 很難看到playbooks裡的變數的價值
輸入，輸出和配置檔案的格式之間不一致
效能和速度有待加強
chef
簡介

官網https://www.chef.io/
Chef介紹視訊：https://www.youtube.com/watch?v=kDeRHgnuDzc

Chef是配置管理的開源工具，專注於開發方為它的使用者群。 廚師作為主客戶端模型執行，具有控制主人所需的單獨的工作站。 它基於Ruby，用純Ruby編寫的大多數元素。 廚師的設計是透明的，並根據它給出的說明，這意味著你必須確保你的說明是清楚的。

Chef DashBoard

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

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

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

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

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

考慮使用Chef的時候需要保證你會使用Git/Ruby，因為書寫配置的時候你會用到的。 Chef非常適合以開發為中心的團隊和環境。 它對於尋找一個更加成熟的解決方案的企業非常適合異構環境。
價格

有免費的開源版本，超出限制數量的節點價格為6/節點/月或

6.75 /節點/月。
優點

豐富的模組和配置配方集合。
程式碼驅動的方法為您的配置提供更多的控制和靈活性。
圍繞Git提供強大的版本控制功能。
“Knife”工具（使用SSH從工作站部署代理）減輕了安裝負擔。
缺點

如果你還不熟悉Ruby和過程編碼，學習曲線是很陡峭的。
這不是一個簡單的工具，這可能導致大的程式碼庫和複雜的環境。
不支援推送功能。
Fabric
簡介

官網http://www.fabfile.org/
Fabric介紹視訊：https://www.youtube.com/watch?v=VmcGuKPpWH8

Fabric是在應用程式部署精簡SSH一個基於Python的工具。 它主要用於跨多個遠端系統執行任務，但也可以使用外掛擴充套件以提供更高階的功能。 Fabric將配置您的系統，執行系統/伺服器管理，並自動部署您的應用程式。
何時使用

如果你只是剛剛接觸部署自動化領域，Fabric是一個很好的起點。 如果你的環境涉及至少一點點Python，它是有幫助的。
價格

免費
優點

擅長部署以任何語言編寫的應用程式。 它不依賴於系統架構，而是OS和包管
理器。
比這個領域的其他工具更簡單，更容易部署
與SSH進行廣泛整合，實現基於指令碼的精簡
缺點

Fabric是單點故障設定（通常是您執行部署的機器）
雖然它是用於在大多數語言中部署應用程式的一個很好的工具，但它需要Python執行，因此您的Fabric環境中必須至少有一個Python。
Puppet
簡介

官網https://puppet.com/
Puppet介紹視訊：https://www.youtube.com/watch?v=j8ImF23jZAg

Puppet是在全面配置管理空間長期工具之一。 它是一個開源工具，但考慮到它已經存在多久，它已經被良好的審查和部署在一些最大和最苛刻的環境中。 Puppet基於Ruby，但是使用更接近JSON的定製的域指令碼語言（DSL）來在其中工作。 它作為主客戶端設定執行，並使用模型驅動方法。 Puppet程式碼設計作為依賴關係列表，這可以使事情更容易或更混亂，這取決於您的設定。

Puppet企業儀表板

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

命令列介面(CLI)簡單直觀，允許通過puppet命令下載和安裝模組。然後，需要對配置檔案進行更改，好讓模組適合所需的任務;應接到指令的客戶端與主伺服器聯絡時，會更改配置檔案，或者客戶端通過立即觸發更改配置檔案的推送(push)來進行更改。

還有一些模組可以提供和配置雲伺服器例項和虛擬伺服器例項。所有模組和配置都使用基於Ruby的Puppet專屬語言或者Ruby本身構建而成，因而除了系統管理技能外，還需要程式設計專業知識。

Puppet企業版擁有最全面的Web使用者介面，允許使用主伺服器上的預製模組和菜譜(cookbook)，實時控制被管理的節點。Web使用者介面很適合用於管理，但是不允許對模組進行諸多配置。報告工具非常完善，提供了詳細資訊，以便了解代理軟體執行如何、已做出什麼樣的變更。
何時使用

Puppet是一個不錯的選擇，穩定性和成熟是你選擇的關鍵因素。 它對於DevOps團隊具有異構環境和技能範圍的大型企業很有好處。
價格

Puppet可以使用免費開源版本，同時也提供收費企業版每年每節點$ 112與批量折扣付費商業企業版本。
優點

通過Puppet Labs建立良好的支援社群。
它有最成熟的介面，幾乎在每個作業系統上執行。
簡單的安裝和初始設定。
在這個空間中最完整的Web UI。
強大的報告功能。
缺點

對於更高階的任務，您將需要使用基於Ruby的CLI（這意味著您必須理解Ruby）。
支援純Ruby版本（而不是使用Puppet的定製DSL）正在縮減。
由於DSL和一個不專注於簡單性的設計，Puppet程式碼庫可能會變得龐大，笨重，難以在更高規模的組織中接納新使用者。
與程式碼驅動方法相比，模型驅動方法意味著更少的控制。
SaltStack
簡介

官網https://saltstack.com/

SaltStack（或Salt）是一個基於命令列的工具，可以設定一個主客戶端模式還是非集中模式。 Salt基於Python，提供了一種推送方法和一種與客戶端通訊的SSH方法。 Salt允許對客戶端和配置模板進行分組，以簡化對環境的控制。

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的最大優點在於可擴充套件性和彈性。你可以有多個級別的主伺服器。上游主伺服器可以控制下游主伺服器及其客戶端。另一個優點在於對等系統，讓客戶端可以向主伺服器提出問題，然後主伺服器從其他伺服器得到答案，提供全面資訊。如果需要在實時資料庫中查詢資料，以便完成客戶端的配置，這個優點就很方便。
何時使用

Salt是一種不錯的選擇，它對系統管理員很有好處，因為它的可用性比較好。
價格

免費的開源版本，這是基於每年每節點訂閱的基礎上SaltStack Enterprise版本。 具體定價不在他們的網站上列出（只有“聯絡我們”連結），但其他人報告每個節點每年150美元起。
優點

一旦您完成設定階段，即可輕鬆組織和使用。
他們的DSL是功能豐富，並不是邏輯和狀態所必需的。
輸入，輸出和配置非常一致 - 所有YAML。
內省是非常好的。 很容易看到Salt內發生了什麼。
強大的社群。
在主模型中具有minions和層級層次的高可擴充套件性和彈性。
缺點

很難設定和挑選新使用者。
文件在介紹層面很難理解。
Web UI比空間中的其他工具的Web UI更新，更不完整。
對非Linux作業系統不是很好的支援。
SaltStack介紹視訊：https://www.youtube.com/watch?v=TQjE2I8CrzQ
Ansible vs. Chef vs. Fabric vs. Puppet vs. SaltStack

使用哪種配置管理或部署自動化工具將取決於您的環境的需求和首選項。 Chef和Puppet是一些較老的，更成熟的選擇，使它們適合於那些重視成熟度和穩定性而不是簡單性的大型企業和環境。
Ansible和SaltStack是那些尋求快速和簡單的解決方案，而在不需要支援quirky功能或大量的作業系統的環境中工作的人的好選擇。
Fabric是小型環境和那些尋求更低人力和入門級解決方案的好工具。

Puppet和Chef會吸引廣大開發人員和注重開發的公司，而Salt和Ansible極其適合系統管理員的要求。Ansible的簡潔介面和可用性非常迎合系統管理員的想法;而在擁有許多Linux和Unix系統的公司，Ansible執行起來一開始就快速又輕鬆。

Salt是四款工具中最漂亮最穩健的;與Ansible一樣，它也會博得系統管理員的芳心。Salt擁有高擴充套件性和強大功能，唯一的軟肋就是Web使用者介面。

Puppet是這四款工具中最成熟的，因為web管理介面不錯從可用性的角度來看恐怕也最容易上手，不過竭力建議你對Ruby要有深入瞭解。Puppet不如Ansible或Salt來得精簡，配置起來有時會變得錯綜複雜。對異構環境來說，Puppet是最穩妥的選擇，但是你可能會發覺Ansible或Salt比較適合更龐大或更一致的基礎設施。

Chef擁有穩定的、精心設計的佈局，雖然它在原始功能方面遠未達到Puppet的水平，但這是款功能非常強大的解決方案。要是管理員缺乏豐富的程式設計經驗，Chef學起來可能最困難，但它也許最適合注重開發的管理員和開發部門。
Ansible或者Puppet
哪個最好

存在即是合理，起碼是存在3年以上的；沒有最好的，只有合適的，你說白菜和青菜哪個最好？

一般來說，有兩種配置管理：
1. 推模式
2. 拉模式

兩種模式有不同的擅長點，有不同的使用場景。
拉模式 (puppet)

這種模式主張去中心化的設計思路，典型代表 puppet。一般實現多為在每個節點上部署 agent，定時獲取該節點的配置資訊，根據配置資訊配置本節點。如果一次配置失敗了，那麼下次繼續嘗試，直到地老天荒。這個節點完全不管其他節點的執行情況，一心只顧做好自己的事情。

所以它比較適合這種場景：
對配置何時生效不敏感，不關心的。你知道它總是會生效的，可能是下一分鐘，也可能是下個小時，但是對你沒什麼影響。
節點和節點之間不需要協作的。比如這種 場景就不合適： A 先升級，然後 B 在升級。
即使某一次拉取資訊失敗了，下一次還能補上，所以比較適合跨地域的大規模部署。
推模式 (ansible)

推模式有一箇中心節點，用於將最新的配置資訊推到各個節點上，典型代表 ansible。很明顯，推模式的瓶頸就在中心節點，如果同一時間有 10000 個節點需要更新配置，那麼中心節點如何穩定的工作就比較有學問。

它比較適合這種場景：
對配置生效的時間敏感，十分關心。必須讓他們即可生效，如果不生效，立馬要採取行動讓他們生效。
配置生效的順序十分關心和敏感。比如需要這10個節點一起生效，或者按照依次生效。
執行順序的區別

配置生效順序在 puppet 和 ansible 之間有很大的不同，理解這些區別對於如何選擇配置管理至關重要。下面舉例說明兩者的區別：

假設現在有三個節點 host1，2，3，它們需要執行配置更新的三個步驟：1，2，3（圓圈表示），我們用圖來表示三個節點上的三個步驟執行順序是如何的。

puppet 的執行順序如圖所示，因為拉模式不管不顧其他節點的執行情況，專心致志完成自己的任務，所以節點之間的更新步驟完全隨機。這種更新方法很“分散式”，跑得快的節點可以很快地跑完全程，不用等其他慢的小夥伴，沒有短板，沒有瓶頸。

ansible 的執行順序如上圖所示。由於有一箇中心節點控制所有機器的配置更新。只有一個步驟在 所有 節點上完成後，才會繼續下一個步驟，所以三個節點的執行順序會很整齊。這種更新方法目的很明確，就是要“整齊”，跑的快的節點需要等待其他小夥伴完成這個步驟後，大家在進行下一個步，誰都不允許自己先執行下一步。

不過 ansible 2.0 中新增加了一種 playbook 的執行策略：free strategy，它允許某個 playbook 不再“整齊”的執行，而是像 puppet 一樣，每個節點 try best 的跑到終點，而不用管其他節點執行的情況如何。
如何選擇

雖然 puppet 和 ansible 有一定的功能重疊，比如都支援配置檔案模版，裝包，啟動服務，等等，但是仍然有區別。如何選擇？只能說“視情況而定”。

如果你的團隊已經有合適的配置管理，並且已經能否覆蓋 90% 的場景，那麼很幸運，不需要換配置管理工具。
如果如 puppet 順序圖所示的情況你不能接受，那麼最好選擇 ansible。
如果一開始選擇了 ansible，並且對“整齊”不敏感，不關心，那麼可以使用 free strategy，或者用 ansible-pull [3]。
如果已經使用 puppet 好多年，並且對於“不整齊”執行沒什麼顧慮，不關心，不敏感，那麼繼續使用 puppet。
如果已經使用 puppet 好多年，並且對於“不整齊”有顧慮，很敏感，但是又不想拋棄已有的 puppet modules，因為它們已經很穩定了，那麼可以選擇使用 Mcollective 改造，或者用 ansible 呼叫 puppet，或者兩者一起用。

Atlassian 公司（做 Jira 的公司）已經給我們介紹了經驗
我們用 Ansible 建立 AWS 虛擬機器，將它們放進 DNS，和負載均衡後面，然後用 Puppet 管理這些虛擬機器的作業系統的配置。當它們完成後，再使用 Ansible 管理應用層軟體的部署和升級。
SaltStack或Ansible

SaltStack與Ansible都是Python寫的而且較新，網上評論也很好。

1、是否需要每臺機器部署agent（客戶端）
很多選用ansible的朋友，都是因為agentless這個原因，覺得要維護agent很麻煩。
而一些使用saltstack比較順的朋友，覺得這個問題無所謂，agent出問題的概率有，但不高。
其實ansible也支援agent的方式，即所謂的“pull”的模式，就是通過一個客戶端去拉取要執行的任務。

2、大規模併發的能力
這方面的對比已經比較多了，因為實現機制的差異，也導致saltstack在這方面是佔優的。不過對於幾十臺-200臺規模的兄弟來講，ansible的效能也可接受。
注：前期調研的大多數都是中下企業，伺服器規模一般不超過200臺，所以對這個問題不算太看重。如果一次操作的機器過千臺，可能還是用saltstack效率更高一些。

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支援的友好程度
ansible對windows的支援簡直不忍直視，agentless只是對於linux的，windows要安裝bug修復補丁，powershell還要3.0，還要安裝python。還不如salt方便。salt有對windows的支援，但是也不是很好。

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

前一段時間用了saltstack，免不得要談一下他們的優缺點。兩者都是安裝和使用都非常方便的批量管理軟體。
1、salt要安裝agent；ansible不需要，通過ssh連線，省掉裝agent的事。
2、salt在server端要啟程序；ansible不需要，但這都無所謂差不多。
3、salt與ansible都有模組，可使用任意語言開發模組。
4、salt與ansible都使用yaml語言格式編寫劇本。
ansible由於走的是ssh,所以它有認證的過程，以及加密碼的過程，這使得ansible非常慢，不適用於大規模環境（指上千臺）。
為什麼我放棄salt呢，首先伺服器不多（百臺左右），其次，salt的master端與minion端TCP連線經常斷開，導致有時執行命令時會漏機器，這簡直讓我忍無可忍。聽說最新版的salt好了很多，但由於公司系統是定製的，安裝軟體特別麻煩（15M的系統，解決依賴就是個大問題），我還是選擇了ansible。

參考連結:
http://blog.takipi.com/deployment-management-tools-chef-vs-puppet-vs-ansible-vs-saltstack-vs-fabric/
http://blog.51cto.com/liqilong2010/1850617
https://www.gaott.info/which-one-ansible-or-puppet/
https://www.zhihu.com/question/22707761
---------------------
作者：張小凡vip
來源：CSDN
原文：https://blog.csdn.net/zzq900503/article/details/80143740
版權宣告：本文為博主原創文章，轉載請附上博文連結！