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


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


推荐阅读