saltstack 和 ansible比较

以前某些时候我须要评估配置管理系统。结合从他人获得的意见，我认为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可经过执行模块来改变主机准柜台。这使得咱们能够精准控制多台机器，好比在升级一个应用程序以前把机器从负载均衡器中剔除出去。

Salt有两种模块：执行模块和状态模块。执行模块能够简单的执行一些命令，好比执行命令行命令，或者下载一个文件。状态模块与Ansible模块更类似，经过参数定义一个状态，而模块则尝试知足该最终状态。一般状态模块调用执行模块来完成工做。

状态模块执行时使用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来安装。

Vagrant支持

当讨论测试时，DevOps人喜欢Vagrant。直到如今我还没用过它。Vagrant可使用Slat和Ansible提供的模块来初始化机器。这意味着在初始化机器时，Vagrant能够垂手可得的使用master+minion模式，或者执行一个playbook。

任务编排

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都很是快。