Ansible似乎比chef和puppet等竞争对手具有明显的优势,因为它不需要代理,并且可以节省一定程度的开销。

我已经阅读了各种配置工具的几种比较,而每种工具都有它的优点和缺点,我意识到这很大程度上取决于个人喜好。

不用代理的好处是显而易见的,但是主/代理体系结构具有任何优点关于配置管理工具?

#1 楼

我发现了关于配置管理pull vs push拓扑主题的有趣讨论。

一位撰稿人写道,pull系统(主/代理)提供了更大的灵活性,并且更易于扩展。

#2 楼

恕我直言,主/代理拉式体系结构的唯一优势是它可以在防火墙网络中使用(当实际配置位于该网络之外时),而不会在防火墙中造成漏洞,而推式体系结构则不能。

在灵活性方面,我认为最重要的问题是在节点上进行远程管理所需的最少设置。一旦满足此要求,两种架构都可以处理更新。主/代理体系结构需要安装,配置和运行代理。一方面,大多数系统上尚未默认安装Puppet和Chef,而sshd(Ansible需要)是。另一方面,即使Ansible也需要sshd运行并且可以在节点上配置凭据才能访问,所以我想从这个角度看并没有太大区别-尤其是如果最小的设置是通过自定义的系统映像实现的。

就可伸缩性而言,我认为主控/代理体系结构的可伸缩性较差(只是一点点):


如果主控试图主动保持活动的系统状态(即所有代理商及其州的地图)会消耗一些时间/资源。没有管理员,Ansible不会受到此类可伸缩性问题的影响。当然,即使是主/代理体系结构也可以提供一种可扩展的方法,以提供类似于Ansible的总体系统状态(现在可能都如此)。
过去,当主服务器实际驱动代理配置任务时正如您在答案中引用的帖子中提到的那样),此类架构的可伸缩性可能会受到很大影响。但是,这已经不是什么大问题了,因为对于您提到的问题中提到的所有工具,配置都只是转移到本地节点,然后由本地节点执行任务。
在将配置传输到本地节点时,拉式架构仅受提供这些配置的能力(这两种架构都具有这种能力)限制,但是主/代理也需要运行逻辑驱动传输并实际进行传输(如果适用)(可以仅指示代理来提取自己的配置),这限制了主服务器将配置传播到大量代理的速度。


#3 楼

恕我直言,拥有代理或主服务器或同时拥有两者的想法可以归结为:


一种连续管理节点状态的机制。


如果这样的工具允许这样做,那么“自我修复”功能将是显而易见的好处。

就Ansible而言,就我而言,没有内置的机制提供自我修复功能(因为没有守护程序连续运行以获取状态并对它们做出反应。)

话说,自我修复听起来不像是配置管理工具的问题应该解决,所以也许这不是人们可能认为其他工具对Ansible的“优势”。