Saltstack VS Ansible，如何选自动化部署工具？

　　　今天说说，Saltstack VS Ansible，如何选自动化部署工具？在众多自动化部署工具中做选择题的时候，相信很多运维都会纠结，到底选哪一个比较好?现在我就来说说，希望看完本文，大家心中会有答案。如果没有，请再看一遍，哈哈哈

 

　　

　　术语

　　Salt和Ansible最初都是作为执行引擎构建的。也就是说，如果需要，它们允许在一个或多个远程系统上并行执行命令。

　　Ansible支持在多台计算机上执行任意命令行命令。它还支持执行模块。一个Ansible模块基本上是写在一定Ansible友好的方式一个Python模块。大多数标准的Ansible模块都是同等的。这意味着你告诉他们你希望系统进入的状态，并且模块尝试使系统看起来像这样。

　　Ansible有Playbook的概念 。Playbook是一个文件，为一组主机定义了一系列模块执行。Playbook可以改变执行主机模块的方式。这样就可以协调多台计算机，例如在升级应用程序之前将它们从负载平衡器中取出。

　　Salt有两种类型的模块;execution(执行)模块和 state(状态)模块。执行模块是简单地执行某些操作的模块，它可以是命令行执行或下载文件。状态模块更像Ansible模块，其中参数定义状态，然后模块尝试实现该结束状态。通常，状态模块在大多数工作中都使用执行模块。

　　状态模块是使用state执行模块执行的。状态模块还支持在称为SLS文件的文件中定义状态。在top.sls文件中定义了哪些状态适用于哪些主机 。

　　Playbook和SLS文件(通常)都是用YAML编写的。

　　作为一个旁注，我想指出一个远程执行引擎对于诸如在多台机器上启动特定操作之类的任务非常有用。

　　结构

　　

 

　　Salt围绕一个Salt Master和多个启动时连接到该主节点的Salt Minions构建。通常，命令是在主命令行上发出的。然后，Master将那些命令分派给Minions。最初，Minions发起一个由加密密钥交换组成的握手，之后它们具有持久的加密TCP连接。因此可以快速到达Minions。还缓存各种数据以加快执行速度。支持ZeroMQ库进行通信。

　　Salt还支持使用SSH而不是使用Salt SSH的ZeroMQ 。但是请注意，它是Alpha软件(我还没有尝试过)

　　

 

　　Ansible是无主从概念的，它使用SSH作为其主要通信层。这意味着速度较慢，但也因为无主从，可能会使运行安装程序和测试Ansible Playbook更加容易。有人说它也更安全，因为它不需要其他服务器应用程序。这在下方的“安全性”可以详细了解该内容。

　　Ansible也支持ZeroMQ版本，但需要初始SSH连接才能进行设置。我尝试了一下，说实话，我并没有看到有很明显的提速。我想可能是在大型的Playbook和有更多的主机才可以看到明显效果吧。

　　要列举机器，建议你使用一个Ansible Inventory 文件，该Inventory文件基本上包含按组分组的主机列表，还具有添加到组或单个主机的属性。你可以有多个库存文件，例如，一个用于登台，一个用于生产。结构简单清晰。

　　社区

　　Ansible：该项目的其余部分似乎不是社区的努力，而是迈克尔·德哈恩(Michael DeHaan)的单人秀。好消息是所有问题都会得到相应的回应。

　　迄今为止，Salt已被证明是一个更受欢迎的社区。问题可能要花大约4天的时间才能得到答复，但似乎大多数问题最终也都会得到跟进。

　　我的明确印象是，Salt在受欢迎和协作方面拥有更成熟的社区。

　　速度

　　尽管你可能认为只有几台服务器时速度并不重要，但我认为你是错的。能够快速迭代始终很重要。启动缓慢会降低你的速度。

　　Ansible始终使用SSH发起连接。太慢了，它的ZeroMQ实现(如前所述)确实有帮助，但是初始化仍然很慢。

　　Salt默认使用ZeroMQ，它是很快的。如前所述，Salt可以缓存文件以更快地重新执行。

　　编排

　　Ansible和Salt都支持编排。我想说编排规则通常更容易获得Ansible的概述。基本上，一个Playbook分为几组任务，每个组与一组主机(或一个主机组)匹配。每个组按顺序按时间顺序执行。任务的执行顺序也是如此。

　　Salt支持 事件和 事件的监控。这意味着Salt执行可以触发另一台计算机上的事件。Salt的执行引擎还可以实现诸如监控之类的功能，而未来的发展将非常有趣。

　　Ansible因其简单性而在这里获胜。Salt之所以能胜任，是因为它能够对群集变化做出持续的反应。

　　Salt和Ansible都还支持在服务器窗口上执行任务。这对于确保服务始终可用非常有用。

　　安全

　　Ansible使用SSH进行传输。SSH是经过测试的协议。只要正确配置了SSH服务器，我相信大多数人会认为SSH客户端是安全的。

　　Ansible还可以轻松地将多个非root用户连接到单个主机。如果你对进程运行非常挑剔， root则应评估Ansible。也就是说，Ansible支持使用 sudo来执行其模块。

　　Salt使用AES实现和密钥处理，需要安装Minions。它为此使用了 PyCrypto软件包。安全性是相当容易维护。

　　还需要注意的重要一点是，root默认情况下，Salt运行其Master和Minions 。这可以更改，但是显然如果你不是root用户，则很难安装Debian软件包等。我强烈建议，对于主服务器，可以将其配置为允许该salt命令为非root用户。

　　可审核性

　　在谈论安全性时，我也认为可审核性很重要。在这里，Salt大赢家。Salt执行的每次执行都会在主服务器上保存X天。这使调试变得很容易，而且还可以查看是否发生了异常的事情。

　　部署方式

　　Ansible在这里绝对容易。无需部署。当然，Salt支持SSH，但文档主要采用ZeroMQ。但是，SSH仍然很慢...

　　设置Minions的一件好事是它们是连接到主节点的Minions。这样可以快速轻松地引导大量新机器。

　　Salt 引导脚本 对于引导非常有用，并且轻而易举。它处理许多不同的分布，并且有据可查。

　　学习曲线

　　Ansible在这里赢了。更容易上手和理解。主要是因为设置几个环境变量并开始执行你的Playbook以外，不需要做其他事情。

　　Salt可以在无主模式下运行。这使得它更容易启动和运行。但是，出于生产(和稳定性)的考虑，我建议启动并运行一个实际的Master。

　　升级

　　升级Salt取决于安装方式。对于基于Debian的发行版，有一个apt存储最新Debian软件包的存储库。所以升级很简单apt-get upgrade。对于Ubuntu，有一个PPA。两个存储库均得到积极维护。

　　升级Ansible更加简单。你只需执行 git fetch && git checkout 而已。

　　文献资料

　　从文档开始，这两个项目都具有启动和运行，开发模块和配置设置所需的所有信息。Ansible历史上比Salt拥有更好的文档结构。也就是说，最近在结构化Salt文档方面付出了巨大的努力。

　　结论

　　Ansible

　　优点

　　Ansible无代理部署和通信

　　CLI支持几乎所有编程语言

　　使用在Linux发行版中无所不在的Python

　　使用SSH / SSH2的出色安全性

　　附加的塔式仪表板允许对节点/资源进行可视化管理(在商业版本中可用)

　　缺点

　　有时容易出现性能问题

　　缺乏内省(即查看Playbook变量值)

　　Salt

　　优点

　　由于具有多主机功能，因此可快速扩展，非常有弹性且高效

　　使用Minions比Ansible提供更多的选择和灵活性

　　尚无GUI(目前正在开发中)

　　缺点

　　强迫用户学习Python或PyDSL

　　未开发的GUI

　　小型部署不如无代理通信那样高效

　　对我而言，Ansible是对自动化服务器配置和部署的出色介绍。它很容易启动和运行，并且具有出色的文档。

　　展望未来，Salt的可扩展性，速度和体系结构都不错。对于云部署，我发现Salt架构更合适。将来我会毫不犹豫地使用Salt。

　　综上所述，你应该在做出决定之前先对两个项目进行调整。他们的设置和测试相当快。至此，希望你心中已有答案。今天内容说到这边了，希望对您有帮助啦。