在上一文中，我介紹了Ansible，那麼不得不介紹Saltstack(以下簡稱Salt)了。在眾多自動化部署工具中做選擇題的時候，相信很多運維都會糾結，到底選哪一個比較好？現在我就來說說，希望看完本文，大家心中會有答案。如果沒有，請再看一遍，哈哈哈
術語
Salt和Ansible最初都是作為執行引擎構建的。也就是說，如果需要，它們允許在一個或多個遠程系統上並行執行命令。
Ansible支持在多臺計算機上執行任意命令行命令。它還支持執行模塊。一個Ansible模塊基本上是寫在一定Ansible友好的方式一個Python模塊。大多數標準的Ansible模塊都是同等的。這意味著你告訴他們你希望系統進入的狀態，並且模塊嘗試使系統看起來像這樣。
Ansible有Playbook的概念 。Playbook是一個文件，為一組主機定義了一系列模塊執行。Playbook可以改變執行主機模塊的方式。這樣就可以協調多臺計算機，例如在升級應用程序之前將它們從負載平衡器中取出。
Salt 有兩種類型的模塊；execution(執行)模塊和 state(狀態)模塊。執行模塊是簡單地執行某些操作的模塊，它可以是命令行執行或下載文件。狀態模塊更像Ansible模塊，其中參數定義狀態，然後模塊嘗試實現該結束狀態。通常，狀態模塊在大多數工作中都使用執行模塊。
狀態模塊是使用state執行模塊執行的。狀態模塊還支持在稱為SLS文件的文件中定義狀態。在top.sls文件中定義了哪些狀態適用於哪些主機 。
Playbook和SLS文件（通常）都是用YAML編寫的。
作為一個旁註，我想指出一個遠程執行引擎對於諸如在多臺機器上啟動特定操作之類的任務非常有用。
結構
Salt圍繞一個Salt Master和多個啟動時連接到該主節點的Salt Minions構建。通常，命令是在主命令行上發出的。然後，Master將那些命令分派給Minions。最初，Minions發起一個由加密密鑰交換組成的握手，之後它們具有持久的加密TCP連接。因此可以快速到達Minions。還緩存各種數據以加快執行速度。支持ZeroMQ庫進行通信。
Salt還支持使用SSH而不是使用Salt SSH的ZeroMQ 。但是請注意，它是Alpha軟件（我還沒有嘗試過）
Ansible是無主從概念的，它使用SSH作為其主要通信層。這意味著速度較慢，但也因為無主從，可能會使運行安裝程序和測試Ansible Playbook更加容易。有人說它也更安全，因為它不需要其他服務器應用程序。這在下方的“安全性”可以詳細瞭解該內容。
Ansible也支持ZeroMQ版本，但需要初始SSH連接才能進行設置。我嘗試了一下，說實話，我並沒有看到有很明顯的提速。我想可能是在大型的Playbook和有更多的主機才可以看到明顯效果吧。
要列舉機器，建議你使用一個Ansible Inventory 文件，該Inventory文件基本上包含按組分組的主機列表，還具有添加到組或單個主機的屬性。你可以有多個庫存文件，例如，一個用於登臺，一個用於生產。結構簡單清晰。
社區
Ansible：該項目的其餘部分似乎不是社區的努力，而是邁克爾·德哈恩（Michael DeHaan）的單人秀。好消息是所有問題都會得到相應的回應。
迄今為止，Salt已被證明是一個更受歡迎的社區。問題可能要花大約4天的時間才能得到答覆，但似乎大多數問題最終也都會得到跟進。
我的明確印象是，Salt在受歡迎和協作方面擁有更成熟的社區。
速度
儘管你可能認為只有幾臺服務器時速度並不重要，但我認為你是錯的。能夠快速迭代始終很重要。啟動緩慢會降低你的速度。
Ansible始終使用SSH發起連接。太慢了，它的ZeroMQ實現（如前所述）確實有幫助，但是初始化仍然很慢。
Salt默認使用ZeroMQ，它是很快的。如前所述，Salt可以緩存文件以更快地重新執行。
編排
Ansible和Salt都支持編排。我想說編排規則通常更容易獲得Ansible的概述。基本上，一個Playbook分為幾組任務，每個組與一組主機（或一個主機組）匹配。每個組按順序按時間順序執行。任務的執行順序也是如此。
Salt支持 事件和 事件的監控。這意味著Salt執行可以觸發另一臺計算機上的事件。Salt的執行引擎還可以實現諸如監控之類的功能，而未來的發展將非常有趣。
Ansible因其簡單性而在這裡獲勝。Salt之所以能勝任，是因為它能夠對群集變化做出持續的反應。
Salt和Ansible都還支持在服務器窗口上執行任務。這對於確保服務始終可用非常有用。
安全
Ansible使用SSH進行傳輸。SSH是經過測試的協議。只要正確配置了SSH服務器，我相信大多數人會認為SSH客戶端是安全的。
Ansible還可以輕鬆地將多個非root用戶連接到單個主機。如果你對進程運行非常挑剔， root則應評估Ansible。也就是說，Ansible支持使用 sudo來執行其模塊。
Salt使用AES實現和密鑰處理，需要安裝Minions。它為此使用了 PyCrypto軟件包。安全性是相當容易維護。
還需要注意的重要一點是，root默認情況下，Salt運行其Master和Minions 。這可以更改，但是顯然如果你不是root用戶，則很難安裝Debian軟件包等。我強烈建議，對於主服務器，可以將其配置為允許該salt命令為非root用戶。
可審核性
在談論安全性時，我也認為可審核性很重要。在這裡，Salt大贏家。Salt執行的每次執行都會在主服務器上保存X天。這使調試變得很容易，而且還可以查看是否發生了異常的事情。
部署方式
Ansible在這裡絕對容易。無需部署。當然，Salt支持SSH，但文檔主要採用ZeroMQ。但是，SSH仍然很慢...
設置Minions的一件好事是它們是連接到主節點的Minions。這樣可以快速輕鬆地引導大量新機器。
Salt 引導腳本 對於引導非常有用，並且輕而易舉。它處理許多不同的分佈，並且有據可查。
學習曲線
Ansible在這裡贏了。更容易上手和理解。主要是因為設置幾個環境變量並開始執行你的Playbook以外，不需要做其他事情。
Salt可以在無主模式下運行。這使得它更容易啟動和運行。但是，出於生產（和穩定性）的考慮，我建議啟動並運行一個實際的Master。
升級
升級Salt取決於安裝方式。對於基於Debian的發行版，有一個apt存儲最新Debian軟件包的存儲庫。所以升級很簡單apt-get upgrade。對於Ubuntu，有一個PPA。兩個存儲庫均得到積極維護。
升級Ansible更加簡單。你只需執行 git fetch && git checkout 而已。
文獻資料
從文檔開始，這兩個項目都具有啟動和運行，開發模塊和配置設置所需的所有信息。Ansible歷史上比Salt擁有更好的文檔結構。也就是說，最近在結構化Salt文檔方面付出了巨大的努力。
結論
Ansible
- 優點
- Ansible無代理部署和通信
- CLI支持幾乎所有編程語言
- 使用在Linux發行版中無所不在的Python
- 使用SSH / SSH2的出色安全性
- 附加的塔式儀表板允許對節點/資源進行可視化管理（在商業版本中可用）
- 缺點
- 有時容易出現性能問題
- 缺乏內省（即查看Playbook變量值）
Salt
- 優點
- 由於具有多主機功能，因此可快速擴展，非常有彈性且高效
- 使用Minions比Ansible提供更多的選擇和靈活性
- 尚無GUI（目前正在開發中）
- 缺點
- 強迫用戶學習Python或PyDSL
- 未開發的GUI
- 小型部署不如無代理通信那樣高效
對我而言，Ansible是對自動化服務器配置和部署的出色介紹。它很容易啟動和運行，並且具有出色的文檔。
展望未來，Salt的可擴展性，速度和體系結構都不錯。對於雲部署，我發現Salt架構更合適。將來我會毫不猶豫地使用Salt。
綜上所述，你應該在做出決定之前先對兩個項目進行調整。他們的設置和測試相當快。至此，希望你心中已有答案。
