新增功能:
逻辑与业务分离,完美实现逻辑与业务分离,业务实现统一shell脚本开发,由框架统一调用。
并发多线程部署,不管多少台服务器,多少个服务,同时发起线程进行更新、部署、启动。
提高list规则文件DIY程度,减少新增服务带来的修改代码,实现扫描list自动化安装部署。(配置、与监控属于业务范围,还需手动修改。)
完善回滚机制,可根据时间段进行回滚,实现即时回滚即时使用。
1 引言
自动化部署与统一安装升级,适用于多资源型分布/分离式部署项目。
随着服务/业务的越来越多,配置文件更是眼花缭乱,每次不知道因为部署/安装问题浪费多少时间,更不知道因为配置问题出过多少问题。多台服务器来回切换,如果服务需要依赖,启动更是问题。
怎么实现自动化安装升级,一键执行统一安装。
适用于多资源型分布式部署项目,随着服务的越来越多,配置文件更是眼花缭乱,每次不知道因为部署问题浪费多少时间,更不知道因为配置问题出过多少问题。多台服务器来回切换,如果服务需要依赖,启动更是问题。
1.1 目的
统一安装、批量部署、统一监控。
1.2 范围
本项目使用范围包括:
- 基于多资源型开发项目
- 项目相关服务繁多
- 服务多依赖关系
1.3 读者
本需求规格说明书的阅读者或其他文档干系人有平台总监、产品经理、项目总监、项目经理、开发人员、测试人员、运维人员、用户体验设计人员等。
2 项目总体描述
2.1 系统总体功能框架
执行统一安装前,首先备份上一轮项目并提取涉及配置文件,再是检查SVN更新版本,确认无误后执行统一安装。
实现一键执行统一安装,执行完毕展示服务进程及相关版本。
2.2 系统功能列表
编号 | 模块 | 功能 | 说明 |
unifyDeploy_0.1 | Exec | 建立信任、初始命令 | 初始 |
unifyDeploy_0.2 | Tools | 服务介入List规则 | 扫描提供服务列表,获取配置信息 |
unifyDeploy_0.3 | Conf | 配置文件处理优化展示 | 自动生成 |
unifyDeploy_0.4 | Bin | 执行工具 | 提供总执行与单一执行 |
unifyDeploy_0.5 | New | 存放修改后配置文件 | 与bak保留文件成反比 |
unifyDeploy_0.6 | Bak | 存放原始配置文件 | 便于问题分析 |
unifyDeploy_0.7 | Temp | 存放临时文件 | 临时文件将及时删除无任何冗积 |
unifyDeploy_0.8 | Workapp | 存放安装包 | 上传安装包 |
unifyDeploy_0.9 | Workbak | 备份安装包 | 统一回滚 |
3 功能描述
3.1 获取配置文件
通过本系统统一安装部署非常简单,只需用户根据list模版提供服务列表,其他无需操作。服务列表如下:
名词解释:
server :服务名称 ip :服务器ip指向 path :部署路径指向 config :配置项 cfpath:配置路径
执行脚本,“conf”目录自动生成用户所需修改配置文件,配置文件是通过处理筛选后生成,所以一个服务不管需要配置多少文件,这里只生成一个,方便修改与管理。配置文件沿用上一轮版本配置文件,在新一轮版本没有新增配置项情况,无需修改跳过此步。
3.2 自动化统一安装部署
自动化统一安装部署,包括:主机信任、SVN安装包下载、上传解压安装包、同步配置、上一轮安装备份、启动服务、监控服务等。
list.sh init.sh pass.war startup.sh syn.sh exec.sh thread.py
部署支持统一安装于分布式安装,每个脚本可以拆分开任意组合使用,比如:
1) 一套新环境中还未部署服务,只需调整上传安装包脚本顺序,先上传安装包后,后续操作正常执行。
2) 迭代更新,功能稍作修改,原配置项无需修改,也只需调整上传安装包包脚本顺序,先获取原有配置,再上传更新安装包包,后续操作正常执行。
3.3 与Ansible优缺点对比
优点:
1) 框架开源,业务脚本基于shell开发,不像Ansible封装的那么严重,只能按照他的格式去写
2)将一个服务下的多个配置文件处理成一个配置模板,与Ansible相比更加的方便修改与检查
3)支持更多的DIY功能,更好的实现监控进程、检查版本等
4)可根据时间段进行回滚,实现即时回滚即时使用
5)不仅适用于更新部署同样适用于第一次部署
缺点:
1)Ansible商业化要久,更多人在用
自动化部署与统一安装升级 - 类ansible工具 unifyDeploy0.3版本发布 (更新时间2014-12-24)
udeploy 1.0