拿什么拯救你,我的Ansible


在自动化运维方面,我用过Chef,Puppet,Salt还有Ansible。
其中Chef和Puppet之前在线上用了很长一段时间,效果也都不错。后来,我们希望尝试一些新的工具,而Salt和Ansible都是通过Python实现的,加上我们的团队也很喜欢用Python,所以就对二者进行了一些比较和试用。

就我个人而言,当时是比较推崇Salt的,因为看起来Salt更轻量级,跟Puppet在配置管理方面也非常相似,而且Salt的源码看起来很舒服,结构很简单,很适合学习和做二次开发。
但Ansible看起来则似乎更独特一些,通过SSH通道实现免Agent,同时在配置方面显得更干练,也有丰富的模块,能通过tags对每个配置项来进行灵活的分组。这些特点,得到了另外一些同事的大力肯定和推荐,在经历过几次争论之后,领导决定将线上所有的Puppet配置都迁移到Ansible上去。

在初期,使用Ansible感觉是比较新鲜的,还略微有点嗨,因为不再需要安装Agent了,新服务器上线之后,把主机名加入hosts inventory,利用初始的root用户密码Push一次,整个配置任务就算完成了。
但在运行了半年多之后,在我们将所有的Puppet配置都迁移过来后,在不停的增加新的配置的情况下,我感到了痛苦,是真真正正的痛苦。

因为,我们目前很难确保线上的配置是完整的,上下逻辑是没有问题的,是能够适用于所有环境的。
而这些,不是Ansible的问题,是人的问题。
由于Ansible免Agent,所以每一次配置的更改,都需要主动的Push一次。在之前配置内容不多,服务器较少的情况下,我们每次都直接把整个配置Push一次。但随着配置的增多,服务器数量增加到了一个相对饱和的程度时,我们绝大部分情况下都只需要对现有的服务器配置进行一些调整,例如增加或更新某个软件,修改某个参数等。

在这种情况下,我们每一次的Push基本上都是通过tags来完成的,没有人愿意在每次都将所有的配置都主动Push一次,没有人会有这个耐心,因为使用tags来执行我想要修改的部分,可能只需要10秒,而将整个配置都跑一次,则需要3分钟甚至更长的时间。因此,日积月累,整个配置的完整性没有了保障,大家更新过的地方,通过tags跑都没有问题,但是抛开tags将整个配置Push一次的时候,就会发现,各种冲突和错误都出现了。

我曾经写过一个CDH5的role,在最开始部署集群时没有一点错误,但是在维护了1个月之后,需要新上线一个新的CDH5集群时,这个role根本无法完成一个新集群的部署,我花费了足足2天来修复所有的报错,我发现,在这1个月里,大家更新了很多的地方,通过那些绑定的tags在现有的环境中Push,都不会报错。
但其实有很多地方,是有冲突和逻辑问题的,很多仅需要在初始化的时候执行的配置之后再也没有执行过,因为更新后的配置大家都是通过tags进行Push的,而Ansible在任何一个配置项报错时都会中止。

这的确是人的问题,但这也是符合人性的。我们尝试过不使用tags来Push,但之后所有的人都觉得这样太过愚蠢,因为绝大部分时间都不会发现错误,只会浪费时间。而经过一段时间之后,谁都不敢保证整个配置Push一次是没有问题的,并且,残酷的现实告诉我们,每次都会有错误出现。

为何之前在使用Puppet的时候,没有遇到过这样的困扰呢?因为,Agent的方式,每次都需要Pull所有关联的配置,需要耗费一些时间,但由于不需要手动去Push,所以感受会不同,我们没有觉得浪费了多少时间,也不用担心更新之后其它的配置项会有问题。

这或许不是工具的问题,是我们没有找到一个合适的方法来使用它。
但是,真的很难找到解决的办法,强制所有人Push整个配置,或周期性的检查整个配置,都难以实施下去。
该拿什么拯救你,我的Ansible。

  1. #1 by non on 2014/08/27 - 00:13

    作者没有用模版引擎来控制配置管理?

    • #2 by mcsrainbow on 2014/08/27 - 11:22

      我们大量使用了模板和自定义模块,但这是人的问题,通过Push每次进行局部更新,本身就会有缺乏全局QA的特点,当配置内容庞大,服务器类型和数量太多的时候,非常容易出错。

  2. #3 by Richie on 2015/11/06 - 14:56

    作者关于ansible有新的感悟吗? 我是个初学者,很希望能知道你碰到的这个问题如何去规避?
    是管理上的问题? 还是ansible不太适合大批量的运维呢?

    • #4 by mcsrainbow on 2015/11/06 - 18:46

      问题依旧,免Agent是最大的亮点也是最大的不足,Push的模式跟有Agent的Pull模式相比,适合于配置简单,环境简单,服务器数量少,变更不频繁的环境,但是当有2000台左右的服务器时,还用Push的模式,那就是灾难。

  3. #5 by mingmings on 2016/01/25 - 16:49

    这个问题曾经碰到过,的确和工具无关,也不能说完全无关,我只能说因为不同的实现方式,ansible 的 role 可以设置依赖 role,variable 可以设置依赖的变量,所以单个 role 没问题的时候不代表依赖没有问题,这就是 puppet 帮你解决的问题,可是在 ansible 里,得自己实现,最后还是到人。。。

  4. #6 by 调兵虎符 on 2016/06/16 - 11:11

    我们只有20台以下,甚至所有项目未来增长到总共500台的概率也非常小,应该适合用ansible了。并且现在我自主开发的基于shell+ssh的批量管理,也是无agent的方式,和ansible的基础思路类似。

(will not be published)
*