最近准备主导重构一套Devops工程,一直忙于筹建中, 所谓再出发,一定是建立在之前的基础上,去重新沉淀并总结。所以这篇文章,我想分两篇文章(分别为总结篇、计划篇)来写,这篇的总结,主要是总结问题,所以欢迎大家能给我提出一些宝贵的建议和想法。我的邮箱是(jeson@imoocc.com)
IMOOCC工程总结篇
伴随当前云技术、自动化等多项技术的成熟及大规模应用,当今小公司更倾向于在用云平台底层架构上来构建并支持自己应用业务服务,而中型、大型公司等高速发展的企业则更多需要通过更多自动化运维方式提高工作效率,同时也能通过自动化的工作来减少人员不断开支。
那么,我们的Team也一直在致力于打造行业内更为功能完善、自动化程度更为高效的devops工程,最终希望我们开发的这套类型的产品能在行业内部有所价值,其中“Imoocc”工程正式我们开发出的其中的一款产品中的一个版本,为什么要叫"imoocc",其实当初有个有意思的想法:
首先、就是这个工程我希望将其中的一个版本开放出代码出来,吸引更多的对Devops开发感兴趣的朋友加入进来,提供给更多的工程师们一个项目演练,所以我在git上开放了这一套代码(git地址见文章最后)。并选择了慕课网推出一个实战Devops开发课程:
同时,我的技术站点域名是(http://www.imoocc.com),在慕课网域名加了一个C,所以,对于这套开放出来的Devops工程就名字就叫做“IMOOCC”工程吧。
开放出来到现在有三个多月的时间了,在此期间我收到很多同学和朋友给我的反馈,下面我来总结如下:
(一)版本问题
imoocc工程,开发之初用的是Python2.7.13、Django建议在1.8.2版本。上线没几天,有几个同学希望能用python3来开发,并且觉得Django版本使用比较老。
为什么要选择python2.7呢?想来主要还是思想上比较保守,python2.7对于原来的开发方式上就认为可以了。另外一个原因,就是曾经我看了一篇贴,在有些场景下需要的模块,python3的支持不是很好,如:进行自动化扫描利用到paramiko模块,有人在安装其中的一个依赖crypto,官方当时是不支持的。当然现在我的感觉来看应该python3出来都这么久了,不应该还有此问题。
(二)管理后台UI需要重新布局、美化
工程界面风格如下图,我对比看了几款其它成熟企业的后台,这块上有待完善,
(1)部分显示内容优化
(2)CMDB搜索添加“全局搜索”选项
之前的版本存在丢失情况
(3)子页面跳转返回页支持
(4)主页面的左侧导航栏不明显
可以增加左侧与右侧的区域颜色区分
(5)搜索结果增加分页显示
(6) 增加查询匹配,增加关键字高亮操作
(7)设备资产报表,添加按照时间段范围选择展示
(三)工程中代码架构设计存在一些问题
在启动自动化扫描程序任务,执行main.py报错:
RuntimeError: Conflicting 'connectioninfo' models in application 'detail': <class 'apps.detail.models.ConnectionInfo'> and <class 'detail.models.ConnectionInfo'>.
这个就是由于设计组织代码结构的时候,不太科学,导致django工程导出,在某种情况下会产生问题,影响工程中models导入。
(四)代码优化完善
(1)一个体现在代码执行流程中的优化,如:自动化扫描发现,对于资产的发现、有的时候需要用到两次的ssh反复登陆探测,流程上完全可以考虑优化。
(2)另外一个体现在代码模块化、共有类的抽象不够,导致代码的重复性有一些高。
(3)模型设计上不够科学,字段名类型、长度。多表关联查询的业务场景如何有效解决。
(4)事件日志添加时间范围选择选项
之前的情况如果默认选择,页面出现报错
(五)功能设计上问题
对于第一版开放的功能中,存在如下的一些问题:
(1)自动化任务执行场景上,队列实现,支持异步任务下发执行。
(2)自动化任务执行中,对于人员组关系和机器组关系,主机组关系和机器关系,权限如何定义。
(3)自动化任务执行中,实现普通用户模式、sudo权限普通用户模式、选择性的root用户模式,这部分功能存在缺失。
(4)CMDB的资产管理部分,缺乏人工管理和编辑功能太少
(5)用户登陆和企业OKR打通
之前采用LDAP认证方式,计划直接通过企业微信来打通分配。
(6)自动化任务加添针对直接机器的IP选择执行
提供不通的选择方式
(六)安全
(1)部分页面没有验证用户登陆步骤
二、阶段规划
阶段
|
阶段任务描述
|
周期
|
---|---|---|
阶段一 | 底层重定义、长远功能规划 | 一个月 |
阶段二 | 事件日志功能、搜索优化、自动化任务权限重写、用户访问分析系统、用户登陆和OKR系统用户打通、调用企业微信消息发送接口 | 一个月 |
阶段三 | 实时日志分析、和分析打通 | 两个月 |
三、第一阶段需求
(1)代码优化
代码结构:
性能优化:
查询优化:
(2)模型重新定义
表结构、关系梳理定义:
表字段设计:
表索引设计:
(3)将工程python2升级python3
python开发版本升级、模块升级:
django版本升级:
(4)UI展现优化
四、重构记录
- 登录页面以企业微信认证(二维码)登录为主,仅管理员支持密码登录
- 当用户登录的时候,检验企业微信上的分组是否改变,如果改变则进行数据库中组的更新
- 管理员可以通过xadmin后台添加自定义组(默认父组为澳客),如果父组被删除,默认回到“爷组”,最终为澳客组
- 设计数据库(用户表,管理员表)
2 .管理员分组以后台(数据库)分组为主,仅支持按组分配权限
3. 资产管理查看变更的详细设备情况
4.日志记录
1.增加执行设备的操作记录(增加字段id,类型,执行是否成功)
2.为执行设备操作记录的设备序列号增加超链接,显示相关的执行结果
5.进入设备详细,对设备进行操作时候发送消息
1.消息的接受者必须有管理员提前定义好,否则报错
2.操作后对相应的组、个人进行发送消息