基于Ansible和Devops的一键测试环境部署实践

本文插图
随着网络架构的不断升级和业务的复杂化，对产品多环境支持的要求越来越高。产品支持的数据库、应用服务器、中间件、操作系统等的多样化，使测试环境的组合越来越多，导致测试环境的部署难度不断增加。
如何选择一个合适的工具，实现多样化环境部署的同时保证部署操作的易用性。下面分享一下我们基于Ansible和Devops实现的一键式测试环境部署的过程。
Ansible是一款自动化运维工具，基于Python开发，集合了众多运维工具（Saltstack、puppet、chef等）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。 Ansible是基于模块工作，具有丰富的内置模块，同时也支持自定义模块开发[1] 。以下是对Ansible和其他常见运维工具的对比[2]：

本文插图
而ansible在自动化运维过程时具有如下优势：
1.基于模块运行，有丰富的内置模块支持
2. 基于Python开发，方便二次开发
3. 基于SSH 交互，被管机器不要安装 Agent
4. 无Server ，在任何安装ansible的机器上执行命令即可
5. 脚本用YAML编写，易读和易维护
正因为ansible操作简单、易上手，功能丰富，已被很多公司纳入使用。
Ansible主要有ad-hoc和playbook两种执行方式， Ansible Ad-hoc是一次性命令，适合执行单个、简单的任务，一次只调用一个模块执行，如执行：
ansible-m yum -a “name=net-tools state=present“即可完成通过yum方式在远程机器上安装net-tools；执行
ansible-m service -a “name=httpd state= started“可以在远程服务其上启动httpd服务，若服务已启动，在远程机器上不会发生任何改变。
Ansible Playbook模式使用YAML格式定义操作，通过模块编排完成复杂的操作，以角色(role)为执行单位，一个role包含多个文件目录，不同目录放置不同作用的文件，一个简单的playbook脚本目录结构如下所示：
. ├── group_vars │└── all.yml ├── install.yml ├── linux.inventory ├── roles │└── test │├── defaults ││└── main.yml │├── files ││└── update.sh │├── handlers ││└── main.yml │├── tasks ││└── main.yml │├── templates ││└── server.xml │└── vars │└── main.yml └── windows.inventory每个目录下放置文件的具体作用为：
files：用来存放copy模块或script模块调用的文件
templates：用来存放jinja2模板
tasks：目录包含一个main.yml文件,该角色执行入口
handlers：角色中触发条件时执行的动作
vars：定义此角色用到的变量
defaults：为当前角色设定默认变量
Playbook模式在安装有ansible 的机器上执行如下命令即可：
ansible-playbook -i linux.inventory install.yml --extra-vars “host=192.168.1.1”-i:用来指定具体的host inventory文件，默认使用/etc/ansible/hosts文件里面定义的主机或分组
--extra-vars:通过命令行方式指定部署用到的参数，通过命令行指定的参数优先级高于脚本中定义的参数
下面介绍几个ansible中常用的一些模块。
1. set_fact
set_fact模块主要用来在部署过程中修改和新增变量，设置的变量可以在后面的role中使用。如依赖mysql数据库时，可通过set_fact 设置db_driver_class、db_driver_jar、db_url等参数,避免在执行时传入复杂的参数，减少执行时参数定义的复杂度，如下所示通过set_fact设置mysql数据库的连接信息。