游戏更新系统:opersible

背景（2014年）

起初的技术主要是使用shell,其实也实现了shell下的并发需求. 但是shell写起来比较费劲,很多都需要自己去实现,太复杂.
后来开始寻求运维管理系统,这才开始了踏上了ansible之路

当时有一个php的web管理后台, 不过这个后台只能用于维护游戏区服的信息(该信息保存在mysql中);
我们通过这个后台能去配置区服,查看区服列表和区服的详细信息等;
该后台没有实际的游戏更新部署能力,更新管理的事情由编写的的一些shell脚本去完成,shell脚本读取mysql拿到区服信息进行操作.
这个mysql库就被我们当成cmdb来使用.

开发与上线

开发工作是由本人这边完成的
内容有:

1.重写ansible的api
2.封装读取mysql中区服信息的代码
3.编写playbook
4.结构的设计: 代码结构和实施方案

这里是写成python脚本的形式, run.py是每个task的入口,只需执行run.py即可.

架构

php后台 ---> mysql <--- opersible ---> playbook

系统上线情况

当前运营了十多款游戏（按平台分）,也都完全成功进行了接入; 每一款游戏只需要根据模板添加对应的参数,对应的执行脚本,和对应的playbook即可.
所有的游戏也只是维护这一套系统,没有维护多套的烦恼,而且各个项目互不影响:A项目的改动不会影响到B系统.
该系统更像是一个框架一样, 我们只需要做的只是简单添加一些血肉就能完成

实现的功能(tasks)

1. 制作后端更新的模板包
2. 部署游戏后端:支持迁移和部署新区
3. 全服更新后端,包含指定区服的更新、区服分段更新
4. 后端批量控制(start/stop)

目录结构

├─config     *#该系统需要用到的一些配置，如cmdb连接信息等, 所有的游戏都放在这里*
├─config_an  *#ansible-playbook的一些配置文件*
├─lib        *#库：读取cmdb 、 调用ansible api*
├─logs
└─tasks      *#该目录下以目录存放着每个task。每个task是建立在ansible程序之上*
     └─setup_game   *#setup_game task， 用于部署游戏服，*
         ├─project
         └─roles    *#ansible-playbook的roles*

# ** ps: tasks目录下本身是有很多个task的,现在进行了隐去. **

使用

# 所有的task放在tasks目录下,修改zone.py,执行run.py即可
cd tasks/task_one   #task_one,task的名字,这里只是举例
vim zone.py         #根据实际要操作的目标区服修改
python run.py       #直接执行即可,有做区服信息提示、检查,避免一些人为错误

后记

今年(2020年)年后,去一家游戏公司面试,和面试官聊到现在很多游戏公司采用了这个设思想计来维护游戏.
想来不会是从我这来的设计思路吧? 想想还有点小激动呀 有木有? 如果是,希望可以发扬光大, 我就当抛砖引玉吧 哈哈
该系统完成于2014年, 当时就职于星辉天拓,整理提交到github是4年前, 开始写的时候, 也并无借鉴也没想到哪里有的借鉴,只是凭自己的想法设计的. 现在已离职多年, 去年18年时, 和之前的同事闲聊,了解到目前还依然在使用该套系统,没想到走了这么久, 再一次小激动,深藏功与名,低调低调.

整体上,这个系统的思路不错,让运维不用忙于各种机器,各种零散,来回折腾,一套系统就控制了所有的游戏,岂不快哉?
当然,话说回来,目前这个系统也只是个雏形, 也有很多地方需要改善和扩展,比如cmdb并不是个标准意义上的cmdb.
另外也不是以个开箱即用的系统,需要本身有一些系统的支撑,比如维护cmdb中信息的管理后台等.

最后说明下由于考虑了敏感性, 有些完成的task进行了清理, 但不影响整体示意说明.