翻譯-Salt與Ansible全方位比較

原文連接：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都很是快。