翻译-Salt与Ansible全方位比较

原文链接:http://jensrantil.github.io/salt-vs-ansible.html

作者: Jens Rantil

之前某些时候我需要评估配置管理系统。结合从他人得到的意见,我认为PuppetChef在配置和运行方面过于复杂。由于我是Python粉,所以我时常关注AnsibleSalt。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都非常快。

posted @ 2015-07-21 15:24 黄博文 阅读(...) 评论(...) 编辑 收藏