Lyft：用SaltStack代替Puppet

美国拼车应用创业公司Lyft宣布用SaltStack代替Puppet作为其系统配置管理工具。根据Lyft工程师Ryan Lane在其博客中的叙述，Ansible也在考虑之列。但Lyft在综合考虑易用性、成熟度、性能和开发社区等因素后，认为SaltStack更胜一筹。

就易用性而言，SaltStack复杂的文档结构和密集的文字，使得其学习曲线更为陡峭。Ryan表示，虽然Ansible的文档对初学者而言更简单易读，但随着项目规模的增大，SaltStack的文档对开发者的帮助更大。深入分析配置文件（Ansible中称为playbooks，SaltStack称为stat definitions）突显了二者的区别。Lyft的工程师发现，SaltStack保持了输入、输出、配置文件的一致性，所有文件均使用YAML格式，而Ansible则使用不同的文件格式（INI,YAML）。循环和条件的实现方式也不同。Ansible将逻辑部分内嵌在DSL中，而SaltStack使用Jinja（一个Python模板引擎）。Ryan和他的同事更喜欢SaltStack的方法。另一个决定性的因素是SaltStack拥有“卓越的”自省（introspection）性能。

在成熟度方面，针对Lyft的用例，Ansible和SaltStack都能提供所有必要的性能和足够的成熟度。不过Ryan发现SaltStack有更丰富的特性：可以以不同的文件格式输出到不同的位置；可以从不同的来源加载pillars（其本质是一种数据结构）；如果以代理模式运行，可以通过reactor系统触发本地事件。

性能方面，以Lyft的用例做测试，SaltStack速度更快，尤其是在no-change运行模式下：

Salt:

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

Ansible:

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

在相同的应用场景下SaltStack的运行速度远远快于Ansible，Ryan因此曾在Ansible上提交过一个问题，不过该问题目前已经关闭。Ansible的创始人Michael DeHaan在Hacker News上提供了一篇关于Ansible性能调节的文章，不过文章内容并没有回应Ryan对于在Ansible中用户相关操作运行缓慢的抱怨。

至于开发社区，Ryan和他的同事认为SaltStacks更为友好，开发者数量也更多。虽然Ryan说“Ansible几乎是由mpdehaan一个人开发的”，但Michael DeHaan表示Ansible“目前有810名贡献者”。Lyft的工程师们还认为SaltStack社区是个更友好、更有助于开发者的社区，对特性请求的接受度也较高。与Asible相比，他们可以向SaltStack提交更多的变更，虽然SaltStack“有时候在接受代码时不够严格（我希望看到更多的代码审查）”。这似乎是个项目管理的哲学问题，而Michael DeHaan在Hacker News上写道“当我们不同意时一定会拒绝。我认为这非常重要。筛选和测试在一定程度上决定了一个项目。”

促使Lyft选择替换Puppet的主要原因是其复杂的、有将近10000行代码的代码库。因为Lyft遵从“谁开发，谁运行”的原则，其DevOps团队认为Puppet代码库不再适合开发者使用。而使用SaltStack和Ansible，用1000行左右的代码就能复制Puppet的架构。

当被问到彻底重写Puppet的可能性时，Ryan写道：

从头开始重写可能会大幅降低代码量，可能也会降低运行时间。即便如此，我认为重写Puppet会耗费我相当长时间。

Lyft对新工具有几个主要的需求。工具应该允许无主架构，因为主节点增加了“一个不必要的故障节点，同时牺牲了性能”。代码应该能顺序阅读，而不会有任何优化打破该原则。代码应该简洁，有少量的配置管理抽象。工具应该支持将横切配置（例如监控）和服务/应用特定配置放置在不同代码库的设计。

InfoQ发表过一个基础架构配置管理工具的系列，其中就有SaltStack和Ansible的介绍。我们也组织过一次该领域主要产品的用户间的虚拟座谈会。有意思的是，Ryan指出的SaltStack和Ansible的几项特点，在我们的虚拟座谈会中也被重点提到过。

查看英文原文：Lyft Replaces Puppet With SaltStack

感谢赵震一对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。