saltstack与ansible对比

深碍√TFBOYSˉ_ 2022-03-29 13:26 308阅读 0赞

<table> 
 <thead> 
  <tr> 
   <th>Saltstack</th> 
   <th>Ansible</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>SaltStack 依靠ZeroMQ速度快</td> 
   <td>Ansible SSH传输速度慢一些</td> 
  </tr> 
  <tr> 
   <td>ZeroMQ本身不加密，AES加密，需注意MITM攻击</td> 
   <td>SSH安全性高</td> 
  </tr> 
  <tr> 
   <td>Master需要守护进程</td> 
   <td>无额外开支，SSH即可</td> 
  </tr> 
  <tr> 
   <td>State语法需要学习</td> 
   <td>playbook语法相对简单，容易学习</td> 
  </tr> 
  <tr> 
   <td>excution模块+state模块，state会调用excution模块</td> 
   <td>Ansible模块+playbook</td> 
  </tr> 
  <tr> 
   <td>使用topfile&nbsp;<a href="https://docs.saltstack.com/en/latest/ref/states/top.html" rel="nofollow">top.sls</a>&nbsp;使用<a href="http://yaml.org/" rel="nofollow">YAML</a></td> 
   <td>playbook使用YAML</td> 
  </tr> 
  <tr> 
   <td>围绕Master输入命令，首次连接使用加密key，使用ZeroMQ库不会拥堵，持续连接速度更快</td> 
   <td>使用SSH通道，无固定Master，更安全，也有MQ版本</td> 
  </tr> 
  <tr> 
   <td>未提及</td> 
   <td>配置记录文件，原始vs生产</td> 
  </tr> 
  <tr> 
   <td>默认本地root，客户端root</td> 
   <td>支持多用户sudo操作</td> 
  </tr> 
  <tr> 
   <td>密码容易保管，命令容易审计</td> 
   <td>SSH，公钥连接</td> 
  </tr> 
  <tr> 
   <td>配置模块化，学习成本更高</td> 
   <td>克隆Ansible Git，语法简单</td> 
  </tr> 
 </tbody> 
</table>

--------------------

## Ansible vs SaltStack 谁才是自动化运维好帮手？ ##

## 1.概述 ##

互联网技术的发展，机房里面机器的数量随之增加，运维的难度和复杂度也在增加，需要投入的运维人员和成本也在增加，从而催生了一系列的自动化运维工具（Ansible、SaltStack、Puppet）的产生来减少运维的成本。  
Ansible、SaltStack、Puppet都是目前比较受用户欢迎的自动化化运维工具，其中Ansible和SaltStack使用python 编写，具有良好的可移植性。Puppet的使用脚本语法复杂，且可移植性比较差，目前的使用者慢慢变少。本文将对Ansible、SaltStack进行 详细的比较。

## 2.Ansible和SaltStack的比较和选型 ##

Ansible和SaltStack都是的目前最流行的自动化运维工具，能满足企业IT系统的自动化运维管理。这两个工具都是用python开发 的，可以部署到不同的系统环境中和具有良好的二次开发特性。在执行的命令的时候,Ansible和SaltStack都支持Ad-hoc操作模式，也可以 支持将命令写入yaml格式文件中再批量执行。在处理返回结果方面，Ansible和SaltStack的返回结果格式都是JSON格式，比较易懂和方便 解析。本文主要从响应速度、安全、自身运维、使用语法等方面对Ansible和SaltStack的不同点进行分析：  
1.响应速度  
SaltStack的master和minion主机是通过ZeroMQ传输数据，而Ansible是通过标准SSH进行数据传输，SaltStack的 响应速度要比Ansible快很多。标准SSH连接的时候比较耗费时间，ZeroMQ传输的速度会快很多，所以单单从响应速度方面考虑SaltStack 会是更好的选择。但是在一般的运维场景下Ansible的响应速度也可以满足需求。  
![这里写图片描述][SouthEast]  
在表格1 Ansible和SaltStack性能测试中，测试了Ansible和SaltStack在执行命令、分发文件、读取文件和批量脚本执行等自动化运维场景下的性能，由耗时数据可以看出Ansible的响应速度比SaltStack要慢10倍左右。  
2.安全  
Ansible和SaltStack都需要和远程主机进行连接，它们的最大的安全问题就是MITM攻击，通过伪装成Master主机和远程主机进行通信，从而进行攻击。  
SaltStack使用ZeroMQ进行数据传输，ZeroMQ本身数据传输不支持加密，SaltStack可以通过使用AES数据加密方法来对数据进行加密传输，但是SaltStack的minion主机以守护进程的方式运行在远端暴露了很多容易被攻击的点。  
Ansible使用标准SSH连接传输数据，不需要在远程主机上启动守护进程，并且标准SSH数据传输本身就是加密传输，这样远程主机不容易被攻击。也不是说Ansible就可以完全避免被攻击，Ansible使用paramiko库进行SSH连接，paramiko是一个有很不错记录SSH连接的 python库。Ansible可以通过配置StrictHostKeyChecking参数，使得远程主机上的keys和之前连接不一样的时候 Ansible没有及时感知和提醒用户。但是Ansible可以通过修改配置文件和配置一个合适的known\_hosts文件来解决这个问题，因此 Ansible在安全方面还是比SaltStack做的好。  
3.自身运维  
SaltStack需要在Master和Minion主机启动守护进程，自身需要检测守护进程的运行状态，增加运维成本。Ansible和远端主机之间的 通信是通过标准SSH进行，远程主机上只需要运行SSH进程就可以进行运维操作，SSH是机房主机中一般都安装和启动的进程，所以在Ansible进行运 维的时候只需要关注Ansible主机的运行状态。Ansible对机房运维不会增加过多的运维成本。从工具本身的运维角度来说，Ansible要比 SaltStack简单很多。  
4.使用语法  
Ansible的Playbook语法要比SaltStack的State语法具有更好的可读性。在使用的过程中发现Ansible在实现loop的更加的简洁，也可以使用相对路径。举例说明，SaltStack在备份文件A.txt和B.txt的State语法为：

1.  `# back up A.txt and B.txt`
2.  `{% for remote_target %}`
3.  `/backup/{ { filename}}:`
4.  `file.managed:`
5.  `‐ source: salt://remote-host/{ { filename }}`
6.  `‐ require:`
7.  `‐ cmd: A.txt`
8.  `‐ cmd: B.txt`
9.  `{% endfor %}`

Ansible的Playbook语法实现同样的功能如下：

1.  `-name: back up A.txt and B.txt`
2.  `copy: src ={ {item}}`
3.  `Dest=/backup/{ {item}}`
4.  `with_items:`
5.  `- A.txt`
6.  `- B.txt`

同样Ansible的Notify模块和Handler模块实现的功能和SaltStack的watch和module.wait的模块实现功能也类似，也比SaltStack要简洁明了。  
总之，Ansible的安全性能比SaltStack好，自身运维简单，使用语法可读性更强，虽然在响应速度方面不如SaltStack，但是在大部分应用场景下Ansible的响应速度能满足需求。因此，在金融行业的自动化运维系统，Ansible工具是最好的选择。

## 3.微服务化架构设计 ##

自动化运维系统的主要运维操作场景有脚本执行、文件的上传下载、启动项管理、用户密码修改、系统软件包管理、定时任务管理等，在云计算的机房里面需 要管理1000余台主机，而Ansible执行任务最高并发数约200个，所以系统中需要部署多个Ansible工具来满足系统的应用需求。运维操作需要 经历连接主机，执行并返回结果的过程，这个过程需要异步执行且实时返回执行结果。  
![这里写图片描述][SouthEast 1]  
图1 展示的是自动化运维平台总体设计，便于自动化运维系统管理大规模主机、实时反馈运维结果的一套系统。  
自动化运维平台：自动化运维平台包含有CMDB、图形化界面、权限管理等核心功能，后端采用REST API调用Worker模块和监听执行结果。  
服务注册中心：服务注册中心提供服务的注册和服务发现的功能，在开源界有Etcd、Consul、Apache Zookeeper、Eureka等组件来实现服务注册中心的功能。Worker模块向网关以IP地址和端口的方式注册到服务注册中心中，自动化运维平台 发现Worker后调度选择Worker执行运维操作。

*  Etcd：一个高可用，分布式，一致的key-value存储，用来共享配置和服务发现。Kubernetes和Cloudfoundry都使用了etcd。
 *  Consul：一个发现和配置服务的工具。客户端可以利用它提供的API，注册和发现服务。Consul可以执行监控检测来实现服务的高可用
 *  Apache Zookeeper：一个常用的，为分布式应用设计的高可用协调服务，最开始Zookeeper是Hadoop的子项目，现在已经成为顶级项目了。
 *  Eureka: 是一个基于 REST 的服务，它主要是用于定位服务，以实现服务注册和服务发现功能，本身具有服务健康检测的功能。  
    Worker集群：Worker模块的核心是Ansible，Worker模块启动的时候使用IP地址和端口向服务注册中心注册一个地址，自动化运维平台 会主动发现Worker模块。图2 Worker模块设计，Ansible本身没有提供REST API,通过使用Flask将Ansible API封装给自动化运维平台调用，在启动REST API的时候将IP地址和端口注册到服务注册中心中。运维操作请求到达REST API后，发送给异步调度celery模块，celery后端对接的是消息中心，实现任务的异步分布式调度。Ansible拿到执行任务，连接远程主机执 行运维操作，然后将执行结果发送消息中心。这个自动化运维平台实时监听消息中心每台主机的执行结果，达到远程主机上的运维操作结果能实时的反馈到自动化运 维平台中。  
    ![这里写图片描述][SouthEast 2]  
    消息中心:消息中心采用的是消息队列，开源消息队列中间件有RabbitMQ、ActiveMQ、kafka。采用消息队列的好处就是能实时的返回执行结果。

## 4.总结 ##

在金融领域中，安全是最重要的考虑因素，在众多自动化运维工具种，Ansible的安全性能最好，是目前最适合金融领域的自动化运维工具。本文通过将Ansible微服务化，集成到自动化运维平台中，实现自动化运维平台高并发执行运维操作场景和实时收集执行结果。

## 5.参考 ##

1.[http://jensrantil.github.io/salt-vs-ansible.html][http_jensrantil.github.io_salt-vs-ansible.html]  
2.[http://www.tuicool.com/articles/3UjQNn][http_www.tuicool.com_articles_3UjQNn]

[SouthEast]: /images/20220329/434c2a26c79245c0be98fb0ff06a85ce.png
[SouthEast 1]: /images/20220329/d60e9444a66246bc8d35073437e25186.png
[SouthEast 2]: /images/20220329/2cd2d7309b164caeac0dc79b251b4eef.png
[http_jensrantil.github.io_salt-vs-ansible.html]: http://jensrantil.github.io/salt-vs-ansible.html
[http_www.tuicool.com_articles_3UjQNn]: http://www.tuicool.com/articles/3UjQNn