|
美國拼車應用創(chuàng)業(yè)公司Lyft宣布用SaltStack代替Puppet作為其系統(tǒng)配置管理工具。根據(jù)Lyft工程師Ryan Lane在其博客中的敘述，Ansible也在考慮之列。但Lyft在綜合考慮易用性、成熟度、性能和開發(fā)社區(qū)等因素后，認為SaltStack更勝一籌。 就易用性而言，SaltStack復雜的文檔結構和密集的文字，使得其學習曲線更為陡峭。Ryan表示，雖然Ansible的文檔對初學者而言更簡單易讀，但隨著項目規(guī)模的增大，SaltStack的文檔對開發(fā)者的幫助更大。深入分析配置文件（Ansible中稱為playbooks，SaltStack稱為stat definitions）突顯了二者的區(qū)別。Lyft的工程師發(fā)現(xiàn)，SaltStack保持了輸入、輸出、配置文件的一致性，所有文件均使用YAML格式，而Ansible則使用不同的文件格式（INI,YAML）。循環(huán)和條件的實現(xiàn)方式也不同。Ansible將邏輯部分內嵌在DSL中，而SaltStack使用Jinja（一個Python模板引擎）。Ryan和他的同事更喜歡SaltStack的方法。另一個決定性的因素是SaltStack擁有“卓越的”自省（introspection）性能。 在成熟度方面，針對Lyft的用例，Ansible和SaltStack都能提供所有必要的性能和足夠的成熟度。不過Ryan發(fā)現(xiàn)SaltStack有更豐富的特性：可以以不同的文件格式輸出到不同的位置；可以從不同的來源加載pillars（其本質是一種數(shù)據(jù)結構）；如果以代理模式運行，可以通過reactor系統(tǒng)觸發(fā)本地事件。 性能方面，以Lyft的用例做測試，SaltStack速度更快，尤其是在no-change運行模式下：
在相同的應用場景下SaltStack的運行速度遠遠快于Ansible，Ryan因此曾在Ansible上提交過一個問題，不過該問題目前已經(jīng)關閉。Ansible的創(chuàng)始人Michael DeHaan在Hacker News上提供了一篇關于Ansible性能調節(jié)的文章，不過文章內容并沒有回應Ryan對于在Ansible中用戶相關操作運行緩慢的抱怨。 至于開發(fā)社區(qū)，Ryan和他的同事認為SaltStacks更為友好，開發(fā)者數(shù)量也更多。雖然Ryan說“Ansible幾乎是由mpdehaan一個人開發(fā)的”，但Michael DeHaan表示Ansible“目前有810名貢獻者”。Lyft的工程師們還認為SaltStack社區(qū)是個更友好、更有助于開發(fā)者的社區(qū)，對特性請求的接受度也較高。與Asible相比，他們可以向SaltStack提交更多的變更，雖然SaltStack“有時候在接受代碼時不夠嚴格（我希望看到更多的代碼審查）”。這似乎是個項目管理的哲學問題，而Michael DeHaan在Hacker News上寫道“當我們不同意時一定會拒絕。我認為這非常重要。篩選和測試在一定程度上決定了一個項目?！? 促使Lyft選擇替換Puppet的主要原因是其復雜的、有將近10000行代碼的代碼庫。因為Lyft遵從“誰開發(fā)，誰運行”的原則，其DevOps團隊認為Puppet代碼庫不再適合開發(fā)者使用。而使用SaltStack和Ansible，用1000行左右的代碼就能復制Puppet的架構。 當被問到徹底重寫Puppet的可能性時，Ryan寫道：
Lyft對新工具有幾個主要的需求。工具應該允許無主架構，因為主節(jié)點增加了“一個不必要的故障節(jié)點，同時犧牲了性能”。代碼應該能順序閱讀，而不會有任何優(yōu)化打破該原則。代碼應該簡潔，有少量的配置管理抽象。工具應該支持將橫切配置（例如監(jiān)控）和服務/應用特定配置放置在不同代碼庫的設計。 InfoQ發(fā)表過一個基礎架構配置管理工具的系列，其中就有SaltStack和Ansible的介紹。我們也組織過一次該領域主要產(chǎn)品的用戶間的虛擬座談會。有意思的是，Ryan指出的SaltStack和Ansible的幾項特點，在我們的虛擬座談會中也被重點提到過。 |
|
|
