Ansible的应用场景分析

Ansible的应用场景分析

最近对devops很感兴趣，从而也开始接触自动化运维工具，在网上查阅了不少关于ansible的资料，对ansible和saltstack等工具的争论也很激烈，各说各的优点，可是争论了半天我总感受这些工具和持续交付并非一个目的。

首先来说，不管是ansible仍是saltstack都是被称为是“配置管理”的工具，那么究竟什么是“配置管理”呢？个人理解就是把对计算机进行的配置集中管理起来。

并且Ansible是一个声明式的管理工具，在编写脚本时使用的是声明式语言，如：“我但愿这台机器的apache服务是启动的”，那么在执行时若是发现服务是启动的则返回“ok”，若是服务没有启动则启动它并返回“changed”。那么相比shell这种“命令式”语言，声明式语言更智能，由于若是用shell启动apache，若是发现服务已经启动，则会返回“端口被占用”的错误，并异常退出，返回码非0，这样就会致使后面的脚本中断执行，是很烦人的一种状况。

举个例子（以下表所示）：好比我但愿在主机A、B、C上部署JDK1.7的环境，主机D、E、F上部署JDK1.8的环境，而又想在A、B上安装Nginx；C、D上部署Tomcat；E、F上部署MySQL，这时候使用Ansible工具是最佳的。对于这种状况须要新建5个roles，分别是：JDK1.7、JDK1.8、Nginx、Tomcat、MySQL。对于A、B主机，安装JDK1.7和Nginx的roles，C主机安装JDK1.7和Tomcat的roles；D主机安装JDK1.8和Tomcat的角色，E、F主机安装JDK1.8和MySQL的角色。换句话讲，Ansible就是对于各类环境的搭积木式组合，你须要什么环境，我就给你装上什么环境，对于系统管理员来说，没必要再去每一台机器上根据开发给的需求名单一个一个安装，不只效率低、劳动成本高、并且容易出错，形成环境的不一致。而Ansible具备幂等性的特色，不管执行多少次，只要你的操做系统是同一个版本，那么安装出来的环境绝对是同样的，这样也就保证了应用所处的底层环境的一致性，而不会形成同一个版本的应用在不一样的机器上运行出现不一样的效果的问题。

环境需求表

Hosts	所需环境		服务名称
A	JDK1.7	Nginx	LVS
B	JDK1.7	Nginx
C	JDK1.7	Tomcat	WEB-1
D	JDK1.8	Tomcat	WEB-2
E	JDK1.8	MySQL	MySQL
F	JDK1.8	MySQL

对于以上案例的playbook执行入口应该以下表所示：

其中能够明显看出，roles字段就像搭积木，你须要什么就往上加一个什么。而对于这个角色的实际执行脚本都是写好的，在入口引用就行了。

其次来说，网上也有人非要用Ansible作持续部署，以下图代码截图。这个并无不能够，可是在启停服务的时候每每使用的是CentOS 6的service httpd start/stop这种方式，由于Ansible内置了服务管理模块service，用法为service：name=httpd status=stopped/started。但对于使用二进制或者源码安装的服务则无能为力，依旧须要使用shell：/PATH/resin.sh start方式启动，而这样也就起不到幂等性的效果，对于已经开启的服务再次执行启动一样会报错。

 

因此综上所述，我认为Ansible更适合基础设施运维/机房运维，而Jenkins更适合应用运维。

最后再来补充一句题外话，下图是我在DevOps学院上摘抄的图片（鸣谢赵班长及其主办的运维社区：www.unixhot.com），这个体系是目前来说比较实用的架构，首先使用cobbler对裸机进行操做系统的自动化安装，而后就会使用刚才说到的Ansible或者saltstack进行基础软件的安装以及配置，而后就要对服务进行监控，作完这一切以后就是平常的部署上线工做了，在整个服务的生命周期中还会不断的产生日志，须要ELK日志平台进行收集和分析加工。而对于底层的硬件不管是物理机、仍是虚拟机都无需关心，只须要作好CMDB的资源登记管理工做便可。这就是互联网行业的一个基本的思路。