拿什么拯救你，我的Ansible

2015-10-28 17:35:35

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

在自动化运维方面，我用过Chef,Puppet,Salt还有Ansible。

[[153958]]

其中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。

原文链接：http://heylinux.com/archives/3245.html?utm_source=tuicool&utm_medium=referral