Django/admin是非常好的运维平台框架, 尤其是小团队, save your life.
我是从负责MySQL的小伙伴那里看到django/admin的, 在这之前一直在找类似的系统, 然而没有看到合适的, 要不太复杂--看tutorial就不想继续了, 要不感觉太简陋. 当第一眼看到MySQL的django/admin界面的时候, 有个声音就在心里说, 这就是我要的.
本人是非常反对自己写运维系统前端的, 原因有很多, 列举一些.
- 网页前端开发太费时间, 很难做得好看. 谁也不想让运维或者开发团队花大把的时间调整像素和颜色, 浏览器兼容, 以及争论JS框架吧.
- 运维最重要的工作, 就是处理系统的不工作. 如果运维系统也不工作, 难道要先修复运维系统再修复线上系统? 所以, 运维系统栈必须简洁, 容易理解: 操作怎么变成最终的命令, 整个执行流, 都要直白. 运维系统不工作的时候, 就绕过它直接操作. 而自己写的前端, 这一点非常难保障. 一句话: 你是相信一整个开源社区的设计, 开发和测试呢, 还是相信一个实习生的?
- 自己写前端, 那么按谁想要的样子写呢? 一朝老板一朝UI算好的了, 我遇到过一位老板换了三套的. 究其根本, 很多原本只是随便想想的功能, 都会想试试. 所以开发疲于奔命, 产品死不悔改.
- 运维基本上都会写脚本, 用Python写个后台, 大家都很乐意, 能充分调动积极性. 以我的经历为例, 开始推广django/admin的时候, 我是迫着同事一起来的, 没过多久, 他们都比我更熟悉这个框架, 写出来的功能都把我看傻了. 因此, 组内也能形成很好的交流氛围.
- 写前端的运维是很少的, 做后台的又看不起做前端的, 总是招俩实习生来做. 于是就出现了问题: 运维系统是重要系统, UI是产品的重要入口, 责任人却是实习生, 非常有趣. PS. 我时常说, 如果用架构的眼光去审视这个世界, 真的非常有趣.
- 另一方面, 如果有前端, 运维人员想尝试新功能, 要经历"提需求=>排计划=>上线"的流程; 而不是有自主权的"上线=>不爽自己改=>不爽自己改=>不爽自己改". 不好意思总是不停地麻烦别人吧? 就算好意思, N对1人家也没时间啊. 结果必然导致: 1. 系统不称手; 2. 有改进系统积极性的人不懂怎么改; 3. 懂怎么改的人没有积极性.
Admin提供了最简单的表格式界面, 这个界面, 非常明确地要求把"重要的数据"展示出来. 我觉得, 对于运维人员而言, 尤其是查看meta data, 这是非常有效的方式. 很多人认为图很重要, 那是统计报表, 或者监控变化. 对于元数据信息, 一个表格可以表达更多.
我觉得把这两者分开是一件很自然的事情, 虽然两者会用到相同的数据: 运维是设计用于线上操作的, 报表是看看的. 报表做不出来, 和运维系统不工作, 两者之间的取舍, 我是倾向前者. 当然也可能很多人倾向于后者, 反正是给老板做事么.
很多开源出来的系统, 都会带上各种图, 看上去很牛逼. 我还是坚持"运维避免写网页"的观点. 当然, 我也预留了写网页的地方, 后面会说到.
首先, 当然是建模Model, 把admin页面的表格列好; 其次, 用action作为命令的触发. 这里有个很有趣的事, 因为http服务器默认超时断开, 但是django的测试用http服务器runserver不会. 正好有些操作耗时比较长, 所以我很惬意地一直用runserver. 因为操作是同步的, 所以执行action, 相当于执行命令, 不用去处理"异步任务"这种烦人的事. 对于小型团队, 非常合适.
这是一个例子:
我把系统逻辑上分成三部分: 数据, 逻辑, 命令.
数据: 就是保存的元数据
逻辑: 复杂的逻辑, 比如: 对10台服务器安装redis, 遍历就是逻辑部分
命令: shell脚本, 一串命令的集合, 比如: 在一台服务器上安装redis
这样区分的好处是:
1. shell脚本基本上是顺序执行, 减少了复杂逻辑, 出错就fail fast.
2. Python来做逻辑处理, 较于用shell写逻辑, 是天堂和地狱的区别. 相对的, 如果在python里写命令, 虽然有各种lib, 依然是不方便的.
3. 调试简单, shell脚本也可以独立使用 => 运维系统不work的时候, 活照样干; 如果命令写在python里, 就麻烦多了.
举个例子, 如果把"在一批机器上安装redis", 写在shell里. 当其中某一台出错, 要反馈给前端(给运维看). shell返回怎么样的数据给django呢? 得设计个返回数据的协议. 如果shell只操作一台, 这个协议就是exit 1. As simple as naive. 忘了说, 把这批机器从python传给shell, 需要设计参数格式, shell还要解析. 只操作一台的话, 也省了这些事情.
留个图, redis部署模型是多实例共享环境的. 顺便提个问: 为什么app不叫redis?
说到参数和返回值的协议, 突然想到最近Google的模块化手机又冒了下新闻. 我相信它在商业上是不会成功的, 因为手机本身已经成为一个模块, 并且整体制造的成本如此之低, 额外的模块化反而是增加成本. 像Python和shell的组合, 直接用最简单直白的协议组合就可以了, 额外的协议和模块化就是徒增烦恼.
想起当年, 大家觉得手机还很贵的时候, 模块化的确是个好的想法, 譬如PC机.
说到成本, 不得不感概一下: IT行业的人, 真是太无私地爱着这个世界了. 用沙子, 智慧, 青春和热血把数学和想象力能到达的一切都以不断地更低的成本带给大众.