自动化运维工具
把运维人员常做的大量的重复的操作，通过一个工具很方便的去做，而运维人员只需要为这种工具提供必不可少的配置。这种工具就是自动化运维工具。（完全是个人理解）
什么是ansible
ansbile是一个自动化运维工具，它可以帮助部署应用，管理系统，简化操作，构建devops基础设施。
上面是官方的解释，不够具体，通过两周的使用，我自己的感觉最能发挥ansible价值的场景（任务），满足这样的特点：重复而且大量
首先是重复，借助ansible完成的任务一定是在某个层面（直观点的层面）是重复的，不然使用这个工具没有任何意义；其次是大量，这个比较能体现ansible轻便的优势
为什么使用ansible
主流自动化运维工具对比调研
| 工具 | 语言 | 架构 | 协议 | 学习曲线 |
|---|---|---|---|---|
| puppet | ruby | c/s | http | 上手难 |
| chef | ruby | c/s | http | 上手难 |
| saltstack | python | c/s | ssh/zmp | 难度低于上面两个，新技术 |
| ansible | python | no client | ssh | 上手容易 |
Puppet和Chef会吸引广大开发人员和注重开发的公司，而Salt和Ansible极其适合系统管理员的要求。Ansible的简洁界面和可用性非常迎合系统管理员的想法;而在拥有许多Linux和Unix系统的公司，Ansible运行起来一开始就快速又轻松。
Salt是四款工具中最漂亮最稳健的;与Ansible一样，它也会博得系统管理员的芳心。Salt拥有高扩展性和强大功能，唯一的软肋就是Web用户界面，配置文件相对ansible复杂一些
Puppet是这四款工具中最成熟的，从可用性的角度来看恐怕也最容易上手，不过竭力建议你对Ruby要有深入了解。Puppet不如Ansible或Salt来得精简，配置起来有时会变得错综复杂。对异构环境来说，Puppet是最稳妥的选择，但是你可能会发觉Ansible或Salt比较适合更庞大或更一致的基础设施。
Chef拥有稳定的、精心设计的布局，虽然它在原始功能方面远未达到Puppet的水平，但这是款功能非常强大的解决方案。要是管理员缺乏丰富的编程经验，Chef学起来可能最困难，但它也许最适合注重开发的管理员和开发部门。
总结来说，ansbile相对于其他自动化运维工具而言，有以下优势：
- 简单，上手快
- 安全性好
- 无需client，配置文件容易理解（相对于salt）
ansible使用相关信息调研
环境依赖
windows server不支持，linux server只需要安装了py2.6+ 和 openssl
升级机制
推荐使用一个较新的稳定版，目前是2.2，升级多少都会因为api变动需要调整脚本
新的技术可能都会面临一个版本快速迭代的问题，不过目前ansible已经到了2.0（被红帽收购），应该算相对来说比较稳定了，不会频繁出现bug；另一方面，至于有没有非常完善的升级机制，官网上面只有一个2.2的安装方法。
这里确实存在一些问题，但是考虑到工具本身比较简单，升级带来的最大的问题就是之前使用的某些api会失效，这个可以通过不使用deprecated的api来尽量避免。
其实类似这种工具，应该尽量降低升级更新的频率，如果当前版本的功能，性能能够满足需求，可以考虑不升级。这也是为什么我们使用的Linux系统版本和node版本都比较低的原因。
学习成本
四大自动化运维工具中，ansible是最低的，不需要学习新的编程语言（以后某些复杂场景可能需要py），只需要了解playbook语法（比较简单）。
这个观点是调研的时候得出的结论，事实上经过两周的使用，现在看来还是有py编程经验会更好一些，尤其是使用过jinja2，因为配置文件模板使用的这个语法，上来不明白得到话，非常难受。
社区活跃情况
官方文档，初级问题在官方文档上基本都能找到答案
github开源项目（学习写法，因为各自公司往往有自己特定的需求，而开源项目大部分都会写成通用的，所以能直接用的不多。举个例子，开源项目中安装工具大都会使用yum，或者通过官方下载链接下载等网络途径去安装，然而我们有特定需求就是需要在不能访问公网的情况下安装）
google常见问题已经基本上都能找到答案（两周使用体验）
对当前工作流的影响
开发： 无
测试： 无
发布： 可以改变手动发布的现状，针对需求实现自动化新功能发布
这里可以说ansible对开发测试的工作流程没有什么影响，因为针对工作流，ansible能发挥作用的地方可能就是发布。这里也可以看出ansible是一个负面影响范围很小的工具，你可以在其他开发者意识不到的情况下使用它，这一点在技术选型上是比较重要的。当然，这跟ansible本身就特别简单可能也有关系（相比salt，可能我就需要运维同学配合在初始化新机器的时候，帮忙准备一下salt被管理节点所需要的环境）
ansible原理
简单来说，ansible工作原来就是通过ssh将要执行的命令（python）发送到远程服务器，目标服务器执行这些命令，实现自动化运维的操作
这一点对于我们目前的情况来说，是能基本满足需求的
ansible的不足
命令传输通过ssh，是没有salt快的（zmq），如果对命令执行的速度有比较严格的要求，不能使用ansible，体验过速度确实偏慢（目前）
总结
综合以上调研情况，ansible是一个成本最低，而且又能满足基本自动化运维需求的选择。所以最终我们选择了ansible