我們發現分布式是一個發展的趨勢，無論是大型網站的負載均衡架構還是大資料架構部署，以及雲存儲計算系統搭建都離不開多台伺服器的連續部署和環境搭建。
當我們的基礎架構是分散式或者基于雲的，并且我們經常需要處理在大部分相同的伺服器上頻繁部署大緻相同的服務時，我們就應該考慮自動化配置和維護了。
讓使用者極容易配置和維護數十台、數百台、乃至數千台伺服器。
幸運的是，現在有很多運維管理工具是為此目的而設計的，它們能夠讓我們使用配方，模闆，劇本（或者其他描述）來簡化環境搭建中的自動化和編排，以提供标準，一緻的部署。
我們現在面臨的問題不是沒有選擇，而是選擇太多。
是以在選擇工具時，需要明确的是我們的需求，需要集中型的管理還是分布式的管理，還有環境的組成，一些工具以不同的語言編寫，并且對特定作業系統或設定的支援可以不同。 最後確定我們選擇的工具與我們的環境和我們的團隊的特殊技能很好地融合在一起可以為我們節省很多精力。
下面我們分别來簡單了解下這幾種工具并且做對比。
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 / 節 點 / 月 或 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
選用Puppet、Chef、Ansible還是Salt，Fabric
| 工具 | 語言 | 架構 | 協定 |
|---|---|---|---|
| Puppet | Ruby | C/S | HTTP |
| Chef | Ruby | C/S | HTTP |
| Ansible | Python | 無Client | SSH |
| Saltstack | Python | C/S(可無Client) | SSH/ZMQ/RAET |
使用哪種配置管理或部署自動化工具将取決于您的環境的需求和首選項。 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