自动化工具后起之秀Ansible的部署实践

从早期手动加脚本的部署方式，到后来自动化工具（chef, puppet, saltstack, ansible等）的出现，再到如今DevOps的盛行，企业应用部署正 式进入平台部署阶段，CD（持续部署）已经成为企业对应用部署的标准需求，运维的交付也不再是以周或天为单位，而是以分钟为单位。

      本文主要介绍自动化工具Ansible，及其在普元DevOps平台中的应用部署和日常应用部署中的实践。

一、如何选择合适的自动化工具？

      面对众多的自动化工具（chef, puppet, saltstack, ansible等），我们该如何选择适合自己的呢？总的来说，无外乎从以下几点来权衡利弊。 

      • 活跃度（GitHub活跃度，社区活跃度）

      • 学习成本

      • 使用成本

      • 编码语言

      • 性能

     

      各种开源的自动化工具在GitHub的关注度是其活跃度最直观的体 现，从图中Contributors这一项就可以看出Ansible和SaltStack的开源项目 贡献者远远多于其它几种自动化工具。越活跃的开源项目往往意味着更 完善的功能和更高效的问题解决率。

      Ansible Galaxy和Salt Formulas都提供了丰富的第三方工具，基本覆 盖了日常部署应用的所有需求。

     

      Puppet和Chef使用的开发语言是Ruby，而Saltstack和Ansible使用的开发语言则是在运维开发这个圈子相对吃得开的Pythen，这也是 SaltStack和Ansible相对于Puppet和Chef更容易被接收的原因。

      很多选择Ansible的朋友，大多都是觉得Ansible上手简单，因为Ansible默认采用SSH连接的方式，不需要安装配置Client，只需要在Server端配置SSH连接信息即可。这也是Ansible相对其他自动化工具的一大优势，但是这一优势带来的影响就是实现机制的差异导致在大规模环境下，Ansible的性能确实要比SaltStack差很多，当然，规模大概在一 两百台机器左右Ansible的性能也是可以接受的。如果是做少量机器应用部署的话，性能问题也就不是那么关键了。

      综合以上因素，最后我们选择Ansible作为我们DevOps部署功能底层实现的自动化工具。

二、Ansible架构图及工作流程

      先来看看这张架构图（来源于网络），看起来是不是很简单，首先对Ansible架构图的各个组成部分作一个说明。 

     

      核心引擎：即图中所看到的Ansible。

      核心模块（Core Module）：和大多数运维工具一样，将系统和应 用提供的能力模块化，一个模块有点像编程中一个功能接口，要使用的 时候调用接口并传参就可以了。比如Ansi