linux自動化運維工具Ansible saltstack Puppet、Chef、Fabric之間的對比

發現分佈式是一個發展的趨勢，不管是大型網站的負載均衡架構仍是大數據框架部署，以及雲存儲計算系統搭建都離不開多臺服務器的連續部署和環境搭建。

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

讓用戶極容易配置和維護數十臺、數百臺、乃至數千臺服務器。
幸運的是，如今有不少運維管理工具是爲此目的而設計的，它們可以讓咱們使用配方，模板，劇本（或者其餘描述）來簡化環境搭建中的自動化和編排，以提供標準，一致的部署。

咱們如今面臨的問題不是沒有選擇，而是選擇太多。

因此在選擇工具時，須要明確的是咱們的需求，須要集中型的管理仍是分佈式的管理，還有環境的組成，一些工具以不一樣的語言編寫，而且對特定操做系統或設置的支持能夠不一樣。 最後確保咱們選擇的工具與咱們的環境和咱們的團隊的特殊技能很好地融合在一塊兒能夠爲咱們節省不少精力。

下面咱們分別來簡單瞭解下這幾種工具而且作對比。

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寫的並且較新，網上評論也很好。

一、是否須要每臺機器部署agent（客戶端）
不少選用ansible的朋友，都是由於agentless這個緣由，以爲要維護agent很麻煩。
而一些使用saltstack比較順的朋友，以爲這個問題無所謂，agent出問題的機率有，但不高。
其實ansible也支持agent的方式，即所謂的「pull」的模式，就是經過一個客戶端去拉取要執行的任務。

二、大規模併發的能力
這方面的對比已經比較多了，由於實現機制的差別，也致使saltstack在這方面是佔優的。不過對於幾十臺-200臺規模的兄弟來說，ansible的性能也可接受。
注：前期調研的大多數都是中下企業，服務器規模通常不超過200臺，因此對這個問題不算太看重。若是一次操做的機器過千臺，可能仍是用saltstack效率更高一些。

ansible的執行架構已經有所優化，採用基於MQ的agent機制，已支持比較大規模（1000-10000臺）的服務器的批量自動化運維。這樣，在這種存在大規模運維的需求的客戶這裏，也能夠應用豐富的ansible的Playbook了。

三、二次開發擴展的能力
ansible和saltstack都是基於python的，而python在運維開發這個圈子裏接受度仍是很是高的，二次開發的人員相對也好招。
這也是這兩個工具相對於puppet和chef更容易被接受度緣由，這兩個曾經的主流工具都是基於ruby，而如今ruby的活躍度愈來愈低了，要招人也不容易。
ansible和saltstack都具有很好的二次開發擴展能力，能夠寫YAML編排。

四、開源社區的對接
在github上，ansbile有18300多顆星，salt有6700多顆星。
直接按關鍵字搜索，ansible的相關項目也更多一些。
這些指標雖然不能直接說明什麼，但不少技術人員會關注本身所使用的技術的活躍度。
通常來講，越活躍的開源項目，獲得的關注會更高些，功能完善和問題解決的效率也會更高。

五、學習的門檻
從第一次使用來說，ansible的部署配置會更簡單一些。
從官方文檔的質量來看，saltstack就比ansible要好一些。
從國內的中文資料來講，ansbile和saltstack好像各有2-3本中文書。 這兩家的國內用戶組也分別在作一些技術資料翻譯的工做。

六、操做界面的友好程度
試用過Ansible的Tower，但實在是不喜歡這種操做習慣，只能說勉強可用。 saltstack的沒仔細用過，但看過朋友搭建的環境，感受官方的UI還能夠，基本夠用了。Ansible的最初設計定位就不是一個完整的運維管理系統，所以官方UI粗糙些也在預料之中。

七、第三方工具的豐富程度
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少了一個數量級，不過大部分經常使用軟件也覆蓋到了。

八、現有用戶使用的規模
根據rightscale的調研報告：
Ansible在2015年有10%的用戶選用，而2016年有20%的用戶選用。 Saltstack在2015年有6%的用戶選用，而2016年有9%的用戶選用。

九、對Windows支持的友好程度
ansible對windows的支持簡直不忍直視，agentless只是對於linux的，windows要安裝bug修復補丁，powershell還要3.0，還要安裝python。還不如salt方便。salt有對windows的支持，可是也不是很好。

咱們本身目前是用的Ansible，但正在結合咱們本身的DevOps平臺，從新給Ansible開發一套WEB UI。

前一段時間用了saltstack，免不得要談一下他們的優缺點。二者都是安裝和使用都很是方便的批量管理軟件。 一、salt要安裝agent；ansible不須要，經過ssh鏈接，省掉裝agent的事。 二、salt在server端要啓進程；ansible不須要，但這都無所謂差很少。 三、salt與ansible都有模塊，可以使用任意語言開發模塊。 四、salt與ansible都使用yaml語言格式編寫劇本。 ansible因爲走的是ssh,因此它有認證的過程，以及加密碼的過程，這使得ansible很是慢，不適用於大規模環境（指上千臺）。 爲何我放棄salt呢，首先服務器很少（百臺左右），其次，salt的master端與minion端TCP鏈接常常斷開，致使有時執行命令時會漏機器，這簡直讓我忍無可忍。據說最新版的salt好了不少，但因爲公司系統是定製的，安裝軟件特別麻煩（15M的系統，解決依賴就是個大問題），我仍是選擇了ansible。