之前某些時候我需要評估配置管理系統。結合從他人得到的意見，我認為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可通過執行模組來改變主機準櫃檯。這使得我們可以精準控制多台機器，比如在公升級乙個應用程式之前把機器從負載均衡器中剔除出去。
狀態模組執行時使用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來安裝。
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都非常快。
Ansible簡介與安裝
當我們在部署多台伺服器軟體環境的時候，10臺機器以內我們還可以自己每台都去布置一下，但是當需要部署的機器繼續增多的時候比如 30臺，40臺，甚至上百臺的時候。每台都去乙個乙個布置就不太現實了，而且這樣做也顯得很沒有技術含量。運維工程師一般會通過一寫自動化運維工具去做這些事情。一些 常用的自動化運維工...
Ansible介紹與安裝
ansible是一款自動化運維工具，基於python開發，集合了眾多運維工具 puppet cfengine chef func fabric 的優點，實現了批量系統配置 批量程式部署 批量執行命令等功能。ansible是基於模組工作的，本身沒有批量部署的能力。真正具有批量部署的是ansible所執...
salt鹽度與使用者密碼加密機制
1 密碼必須雜湊儲存 內容略 2 加salt雜湊 我們知道，如果直接對密碼進行雜湊，那麼黑客 統稱那些有能力竊取使用者資料並企圖得到使用者密碼的人 可以對乙個已知密碼進行雜湊，然後通過對比雜湊值得到某使用者的密碼。換句話說，雖然黑客不能取得某特定使用者的密碼，但他可以知道使用特定密碼的使用者有哪些。...