ansible
http://www.cnblogs.com/ee900222/p/ansible.html
http://ju.outofmemory.cn/entry/67581
http://www.cnblogs.com/liang-wei/p/6030755.html
http://www.cnblogs.com/imzye/p/5143708.html
http://www.aichengxu.com/other/3495446.htm
http://www.tuicool.com/articles/FBn6b2m (LAMP)
ansible vs puppet vs saltstack
你一定不会屈服的，实际上很多人已经揭竿而起投笔从戎写出各种IT Automation Management Tool/System（ITAMS），甚至有人还遍尝百草，把经验写成了书（佩服！），我们要搞一个进来也是大势所趋，你真的不想扩容扩到睡着了。
你也一定听过很多ITAMS，那么你看好哪一个呢？所谓萝卜青菜各有所爱，呐，我来放一下我的选择理由：
首先，没有一个工具是能满足大家所有需求的，所以开发是more or less的事了，在选择的时候，我们的标准是：
1. 可作为批量执行工具
2. 可支持playbook，模块化
3. 容易上手，开发扩展容易
4. 在权限控制方面能很好的与目前的登陆授权管理系统结合
5. 社区活跃，有问题能查到解决办法
就playbook和模块化来说，puppet，saltstack和ansible半斤八两，就不细比了。
puppet有产品线已经在用，优点是历史悠久，比较成熟，在可远程可本地，功能强劲，不过这厮批量执行功能没得，为了批量执行个命令写个配置文件，好像有点大刀砍蚊子腿的感觉了，而且有客户端在，和授权系统结合比较麻烦。
saltstack和ansible都是python流的，而且就功能上来讲，两者也极为相似，不同之处是salt stack是有客户端的，并且execution模块还用0MQ实现了pub-sub，命令和执行结果因此可以高效并行传输，不过成也萧何败也萧何，第一个sub阶段（将querystring下发到所有机器，然后收集机器响应的阶段）太依赖与客户端返回了，如果客户端未能及时返回或未响应的话，playbook执行阶段可能会直接漏掉这部分机器而没有任何提示，这对于运维来说是不可接受的，要改造这个就得推掉saltstack的现有架构…算了吧。
与前两者比起来，ansible在特性上似乎并不抢眼，配置管理方面（playbook）绝对比不过老大哥puppet，批量执行方面也只是多线程，不像saltstack那么高大上，不过ansible搜索热度高出saltstack三倍多，显然靠的不是吹牛，至少，ansible至少不会悄悄的丢机器，这给了我们一个定心丸，而且仅依赖ssh，与登录授权管理系统天然集成，简单即有效，没有比这更美妙的事情了。
So， 让我们来尝尝Ansible吧！