美國拼車應(yīng)用創(chuàng)業(yè)公司Lyft宣布用SaltStack代替Puppet作為其系統(tǒng)配置管理工具。根據(jù)Lyft工程師Ryan Lane在其博客中的敘述，Ansible也在考慮之列。但Lyft在綜合考慮易用性、成熟度、性能和開發(fā)社區(qū)等因素后，認(rèn)為SaltStack更勝一籌。

就易用性而言，SaltStack復(fù)雜的文檔結(jié)構(gòu)和密集的文字，使得其學(xué)習(xí)曲線更為陡峭。Ryan表示，雖然Ansible的文檔對(duì)初學(xué)者而言更簡(jiǎn)單易讀，但隨著項(xiàng)目規(guī)模的增大，SaltStack的文檔對(duì)開發(fā)者的幫助更大。深入分析配置文件（Ansible中稱為playbooks，SaltStack稱為stat definitions）突顯了二者的區(qū)別。Lyft的工程師發(fā)現(xiàn)，SaltStack保持了輸入、輸出、配置文件的一致性，所有文件均使用YAML格式，而Ansible則使用不同的文件格式（INI,YAML）。循環(huán)和條件的實(shí)現(xiàn)方式也不同。Ansible將邏輯部分內(nèi)嵌在DSL中，而SaltStack使用Jinja（一個(gè)Python模板引擎）。Ryan和他的同事更喜歡SaltStack的方法。另一個(gè)決定性的因素是SaltStack擁有“卓越的”自?。╥ntrospection）性能。

在成熟度方面，針對(duì)Lyft的用例，Ansible和SaltStack都能提供所有必要的性能和足夠的成熟度。不過Ryan發(fā)現(xiàn)SaltStack有更豐富的特性：可以以不同的文件格式輸出到不同的位置；可以從不同的來源加載pillars（其本質(zhì)是一種數(shù)據(jù)結(jié)構(gòu)）；如果以代理模式運(yùn)行，可以通過reactor系統(tǒng)觸發(fā)本地事件。

性能方面，以Lyft的用例做測(cè)試，SaltStack速度更快，尤其是在no-change運(yùn)行模式下：

Salt:

• Full run: 12m 30s
• No change run: 15s

Ansible:

• Full run: 16m
• No change run: 2m

在相同的應(yīng)用場(chǎng)景下SaltStack的運(yùn)行速度遠(yuǎn)遠(yuǎn)快于Ansible，Ryan因此曾在Ansible上提交過一個(gè)問題，不過該問題目前已經(jīng)關(guān)閉。Ansible的創(chuàng)始人Michael DeHaan在Hacker News上提供了一篇關(guān)于Ansible性能調(diào)節(jié)的文章，不過文章內(nèi)容并沒有回應(yīng)Ryan對(duì)于在Ansible中用戶相關(guān)操作運(yùn)行緩慢的抱怨。

至于開發(fā)社區(qū)，Ryan和他的同事認(rèn)為SaltStacks更為友好，開發(fā)者數(shù)量也更多。雖然Ryan說“Ansible幾乎是由mpdehaan一個(gè)人開發(fā)的”，但Michael DeHaan表示Ansible“目前有810名貢獻(xiàn)者”。Lyft的工程師們還認(rèn)為SaltStack社區(qū)是個(gè)更友好、更有助于開發(fā)者的社區(qū)，對(duì)特性請(qǐng)求的接受度也較高。與Asible相比，他們可以向SaltStack提交更多的變更，雖然SaltStack“有時(shí)候在接受代碼時(shí)不夠嚴(yán)格（我希望看到更多的代碼審查）”。這似乎是個(gè)項(xiàng)目管理的哲學(xué)問題，而Michael DeHaan在Hacker News上寫道“當(dāng)我們不同意時(shí)一定會(huì)拒絕。我認(rèn)為這非常重要。篩選和測(cè)試在一定程度上決定了一個(gè)項(xiàng)目。”

促使Lyft選擇替換Puppet的主要原因是其復(fù)雜的、有將近10000行代碼的代碼庫。因?yàn)長yft遵從“誰開發(fā)，誰運(yùn)行”的原則，其DevOps團(tuán)隊(duì)認(rèn)為Puppet代碼庫不再適合開發(fā)者使用。而使用SaltStack和Ansible，用1000行左右的代碼就能復(fù)制Puppet的架構(gòu)。

當(dāng)被問到徹底重寫Puppet的可能性時(shí)，Ryan寫道：

從頭開始重寫可能會(huì)大幅降低代碼量，可能也會(huì)降低運(yùn)行時(shí)間。即便如此，我認(rèn)為重寫Puppet會(huì)耗費(fèi)我相當(dāng)長時(shí)間。

Lyft對(duì)新工具有幾個(gè)主要的需求。工具應(yīng)該允許無主架構(gòu)，因?yàn)橹鞴?jié)點(diǎn)增加了“一個(gè)不必要的故障節(jié)點(diǎn)，同時(shí)犧牲了性能”。代碼應(yīng)該能順序閱讀，而不會(huì)有任何優(yōu)化打破該原則。代碼應(yīng)該簡(jiǎn)潔，有少量的配置管理抽象。工具應(yīng)該支持將橫切配置（例如監(jiān)控）和服務(wù)/應(yīng)用特定配置放置在不同代碼庫的設(shè)計(jì)。

InfoQ發(fā)表過一個(gè)基礎(chǔ)架構(gòu)配置管理工具的系列，其中就有SaltStack和Ansible的介紹。我們也組織過一次該領(lǐng)域主要產(chǎn)品的用戶間的虛擬座談會(huì)。有意思的是，Ryan指出的SaltStack和Ansible的幾項(xiàng)特點(diǎn)，在我們的虛擬座談會(huì)中也被重點(diǎn)提到過。