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具有幂等性的特点，无论执行多少次，只要你的操作系统是同一个版本，那么安装出来的环境绝对是一样的，这样也就保证了应用所处的底层环境的一致性，而不会造成同一个版本的应用在不同的机器上运行出现不同的效果的问题。

环境需求表

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

其次来讲，网上也有人非要用Ansible做持续部署，如下图代码截图。这个并没有不可以，但是在启停服务的时候往往使用的是CentOS 6的service httpd start/stop这种方式，因为Ansible内置了服务管理模块service，用法为service： name=httpd status=stopped/started。但对于使用二进制或者源码安装的服务则无能为力，依旧需要使用shell： /PATH/resin.sh start方式启动，而这样也就起不到幂等性的效果，对于已经开启的服务再次执行启动同样会报错。其中可以明显看出，roles字段就像搭积木，你需要什么就网上加一个什么。而对于这个角色的执行脚本都是写好的，在入口引用就好了。

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

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

Ansible的应用场景分析

标签：配置管理 ansible

原文地址：http://blog.51cto.com/hebutyx/2094774