原文連結：http://jensrantil.github.io/salt-vs-ansible.html
作者： Jens Rantil
之前某些時候我需要評估配置管理系統。結合從他人得到的意見，我認為Puppet及Chef在配置和執行方面過於複雜。由於我是Python粉，所以我時常關注Ansible及Salt。Ruby目前不是我感冒的語言，當然我也不想在這裡引起語言之爭。
去年我花了6個月美好的時光用Ansible來配置伺服器。從而對這個工具變得很熟悉。在那個專案中Ansible可以說是最佳選擇，因為它易於使用，還有完整的文件。我所工作的團隊儘量遵循文件中指示的最佳實踐，從而使我們快速上手，而且我們可以借鑑已經被驗證過可以工作的結構。
幾周前我去日本開始為期10天的休假，在一個完全沒人認識我的地方，我有充足的時間來閱讀一些電腦雜誌和文件。享受了美味的壽司，觀賞了東京美景，玩耍了滑雪之餘，我發現閱讀Salt PDF文件是一個很棒的休閒。
當然我花了一些時間來試用Salt並使用了States系統。現在我認為我對兩個系統有了一個粗略的背景，我義無返顧的進行了一個具有個人色彩的測評。
術語
Salt及Ansible建立之初都被作為執行引擎。即，它們都可以在一臺或多臺遠端系統中執行命令，並且可以並行執行。
Ansible支援在多個機器上執行任意的命令列命令。它也支援執行模組。一個Ansible模組基本上是以對Ansible友好的方式編寫的Python模組。大多數標準的Ansible模組是冪等的。這意味著你只需告訴你的系統想要的狀態，那麼該模組就會嘗試將你的系統調整為該狀態。
Unusable也有Playbook的概念。一個playbook是為一組主機定義了一系列模組執行順序的檔案。playbook可通過執行模組來改變主機準櫃檯。這使得我們可以精準控制多臺機器，比如在升級一個應用程式之前把機器從負載均衡器中剔除出去。
Salt有兩種模組：執行模組和狀態模組。執行模組可以簡單的執行一些命令，比如執行命令列命令，或者下載一個檔案。狀態模組與Ansible模組更相似，通過引數定義一個狀態，而模組則嘗試滿足該最終狀態。通常狀態模組呼叫執行模組來完成工作。
狀態模組執行時使用state執行模組。狀態模組支援通過檔案定義狀態，該檔案被稱為SLS檔案。而狀態與主機的對映關係被定義在top.sls檔案中。
playbook及SLS檔案（通常）都是使用YAML格式。
另外，我想指出當任務需要使用inventory,或者需要在多臺機器上執行時，使用遠端執行引擎是非常有用的。
架構
Salt有一個Salt master，而很多Salt minon在初始化時會連線到該master上。通常，命令起始於master的命令列中。master然後將命令分發到minion上。初始化時，minion會交換一個祕鑰建立握手，然後建立一個持久的加密的TCP連線。我可以喋喋不休的闡述Salt如何藉助ZeroMQ庫來通訊，但簡短的來說，Salt master可以同時連線很多minion而無需擔心過載，這歸功於ZeroMQ。
由於minion和Salt master之間建立了持久化連線，所以Salt master上的命令能很快的到達minion上。minion也可以快取多種資料，以便加速執行。
Ansible無需master，它使用SSH作為主要的通訊層。這意味著它比較慢，但無需master意味著它在設定及測試Ansible playbook上更加容易。有人也聲稱它更安全，因為它不需要額外的伺服器程式。你可以在“安全”章節獲取更多資訊。
Ansible也有支援ZeroMQ的版本，但需要一個初始的SSH連線來設定。我嘗試了這個，但說實話我並沒感到速度有所提升。我猜如果playbook更大，主機更多時才會感受到速度的提升。
Ansible推薦使用inventory檔案來追蹤機器。inentory檔案基本上包含了一組主機，可以對其分類為組，可以對一組主機或單個主機指定屬性。你可以建立多個inventory檔案，比如一個作為階段環境，另一個作為產品環境。
Salt也支援使用SSH替代ZeroMQ，即Salt SSH。但請注意目前還是試用版本（而且我還沒嘗試用過）
社群
對於這兩個專案我都有使用IRC及郵件列表的經歷。我也給它們發過補丁包，包括Python程式碼及一些文件修正。以下是我的經歷的總結：
Ansible：IRC上反饋非常快，並且很友好。但該專案貌似缺少社群影響，更像是一個人在領導，即Michael DeHaan。抱歉我這樣說，其實我很喜歡社群，因為對於改進更加開放和友好。Ansible一些改進問題還未修復就關閉了，讓我感覺它把問題隱藏了起來。好在所有的問題都有回答。
Salt需要繼續證明其歡迎社群貢獻。IRC反饋已經變得及時和友好。有時我需要藉助於郵件列表。我有一些郵件，直到4天以後才得到響應，但看起來每個郵件最終都會有跟進。
我的印象是Salt有更成熟的社群，更歡迎協作。我說這句話時可能會得罪很多人，當然這是我個人觀點！
速度
如果你以為你的伺服器比較少，速度無所謂時，我相信你是錯的。能夠快速迭代永遠是非常重要的。長期來說，配置緩慢會拖慢你的整個節奏。如果有些東西需要花費30秒以上來編譯，我會在編譯時去玩Twitter，而這意味著該編譯會其實會花掉至少120秒。部署時也會這樣。
Ansible始終使用SSH來初始化連線。這很慢。也許Ansible的ZeroMQ實現（之前提到過）會改善這點，但初始化依然會很慢。Salt預設使用ZeroMQ，所以很快。
之前說過，Salt擁有持久的minion程式。這使得Salt可以快取檔案，從而加速執行。
程式碼結構
我最不能忍受的是Ansible模組不能被匯入（因為匯入就會執行程式碼）。這意味著測試模組時會引入一些魔法。因為你無法匯入任何一個模組。我不喜歡魔法，而喜歡純粹簡單的程式碼。這更像Salt的風格。
少用魔法意味著給Salt模組寫測試更清晰。Salt完全可測。我很高興Salt關於測試有三個章節，包括鼓勵你mock一些你不具備的基礎設施來增加可測性，比如mock一個MySQL例項。
以上說明Ansible通常擁有簡潔乾淨的程式碼。我在其中可以快速跳轉。然而，提升程式碼結構不是“Ansiable社群”的關注點。
Ansible和Salt都可以通過PyPi來安裝。
Vagrant支援
當討論測試時，DevOps人喜歡Vagrant。直到現在我還沒用過它。Vagrant可以使用Slat和Ansible提供的模組來初始化機器。這意味著在初始化機器時，Vagrant可以輕而易舉的使用master+minion模式，或者執行一個playbook。
任務編排
Ansible和Salt都支援編排，我認為Ansible中編排規則更容易理解和使用。基本上，playbook可以分割為多個任務組，每組匹配一組主機（或主機組）。每組按順序來依次執行。這與任務的執行順序相同。
Salt支援事件和反應器。這意味Salt執行可能會觸發另一個機器上的東西。Salt的執行引擎也支援監控。所以未來這塊前景比較廣闊。你可以使用Overstate在叢集中以特定順序設定多種角色來實現基礎編排。
Ansible比Salt在編排方面更好，因為它簡單。Salt將來會更好，因為在叢集變化中它更具持續反應性。
Salt及Ansible都支援通過機器視窗執行任務。這對於保證服務始終可用（比如升級時）是非常有用的。
安全
Ansible使用SSH來傳輸資料。SSH是經歷過考驗的協議。一旦SSH伺服器被正確配置（使用一個良好的隨機數生成器），我相信大多數人會認為SSH客戶端是安全的。
Ansible也可以輕鬆的建立多個非root使用者與單個主機的連線。如果你非常反對有程式以root許可權執行，那麼你可以考慮使用Ansible。Ansible支援使用sudo來以root方式執行模組。所以你可以無需使用root來建立SSH連線。
Salt使用“自己”的AES實現及key管理。我想指出這裡的“自己”其實是使用PyCrypto包。Salt以前有安全問題，但同時我認為Salt架構很簡單，所以安全問題可以輕鬆的維護。
有點需要指出，Salt執行master及minion時預設以root方式。這個配置可以改，但顯而易見會導致一些新問題，比如非root模式下很難安裝Debian包。在master上你可以配置salt命令為非root模式。我極力推薦這樣做。
敏感資料
所有敏感資料應當單獨存放，然後在需要時存放在配置機器上。如果配置機器是系統管理員的機器（現在通常是膝上型電腦），那麼會有資料被盜用的風險。
經過深入的長時間思考後，我認為認證master方式是更好的選擇。這意味著敏感資料可以強制存放在一個受保護的地方（當然需要加密的備份）。Salt可以把安全證照存放在”Pillar”裡。當然，破解master會是個毀滅性打擊，但是同時我們只需要安全保護一臺機器。不是所有的開發者電腦都是安全的，尤其在火車上或飛機場時。
顯然，Ansible使用者可以選擇始終通過一個絕對安全的存放敏感資料的電腦上執行playbook。但人們通常會這樣做嗎？
審計能力
當討論安全時我認為審計是相當重要的。Salt在這方面比Ansible做的要好。Salt的每次執行都會在master上存放X天。這樣我們更容易除錯，也容易發現可疑的事情。
部署
Ansible顯然更容易些。因為它無需部署。當然，Salt支援SSH，但文件中大多數情況下假設我們使用ZeroMQ的方式。當然，SSH要慢些。
初始化minion的好處是這些minion都會連線到master。這使得我們可以快速初始化很多新機器。如果你想使用類似於亞馬遜的自動化彈性擴充套件功能時，minion-連線架構很有用。每一個自動化彈性擴充套件的機器將自動變為一個minion。
Salt 初始化指令碼非常好用，而且執行很快。可以處理不多種分發，文件也很豐富。
學習曲線
Ansible這方面更好。Ansible更容易學習及提高。因為我們只需拷貝一份Ansible GIT程式碼庫，然後設定一些環境變數就可以執行playbook了。
Salt可以以非master模式執行。這樣可以更容易設定和執行salt。然而，對於產品環境（以及階段環境）我推薦使用master模式來執行Salt。
通體來說，Salt功能更花哨，代價是學習曲線陡峭。Salt更加模組化。這易於組織程式碼結構，但是完全精通Salt需要更多學習。
升級
升級Salt取決於當時是如何安裝Salt的。基於Debian的分發的話，有一個apt程式碼庫來存放最新的Debian包。所以升級的話可以使用apt-getupgrade。對於Ubuntu機器，有PPA。這些程式碼庫的維護很活躍。最新發布的2014.1.0版本一週內（時間有點長）就有了Debian/Ubuntu包。
升級Ansible更簡單。你只需簡單執行git fetch && git checkout
文件
兩個專案都有詳盡的文件供你設定和執行，以及開發模組及配置。過去Ansible比Salt有更好的文件結構。最近Salt花了大力氣來重整文件。我也貢獻了自己的力量來幫助完善這些文件。
結語
對於我來說，Ansible是個極好的工具來自動化伺服器配置及自動化部署。設定Ansible並執行起來很簡單，而且文件也很豐富。
進一步說，Salt具有可伸縮性，速度快，架構合理。我發現Salt的結構更適合雲端部署。將來我會毫不猶豫的使用Salt。
總的來說，你在做出選擇之前最好在你的專案中都試用下它們。反正配置及測試Ansible及Salt都非常快。