IT工程師數位筆記本

原文鏈接：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都非常快。