基于Jenkins的统一操作平台

作者：SUNNY
时间：2018-11-08

---

为什么要做统一操作平台？

根据实际数据统计，运维工作中，登陆服务器操作的操作，80%以上操作命令是查看之类操作（包括ls，cd，more等），还有一部分操作是文件编辑。
目标：运维人员的日常操作，均能通过统一平台来实现，减少琐事，提高质量、效率

有哪些需求？

日常操作简单分类为：

• 文件查看
• 线上配置变更
• 日志分析
• 重启服务
• 机器/系统级变更
• 各应用服务特有操作
• 其他

结合实际操作数据统计、走访调研，初步分析出数据云运维人员日常操作包括但不限于：

说明：

• 飘红框表示操作频率比较高
• 与服务相关的操作中，频率最大的是应用重启操作

解决思路是怎样的？

• 文件查看
  • 这类操作暂时不细分，在线上服务器上开通dev开发账号（在线服务通过hadoop部署），运维人员通过dev来进行配置查看
• 线上配置变更
  • 通过云翼包部署，不支持配置变更，这样对运维是一个很大麻烦，多次反馈，云翼表示不支持配置变更功能
  • 变更频率比较高的任务，通过Jenkins Job来完成（基于Jenkins的统一操作平台来完成）
• 日志分析
  • 通过ELK来实现
• 重启服务
  • 基于Jenkins的统一操作平台来完成
• 机器/系统级变更
  • 基于Jenkins的统一操作平台来完成
• 各应用服务特有操作
  • 基于Jenkins的统一操作平台来完成
• 其他

基于Jenkins的统一操作平台

这是统一操作平台的重点，把日常操作全部抽象为Jenkins Job，每个操作对应一个Jenkins Job。

在通用性操作中，服务重启使用频率最高，因此优先来完成重启Job。

在Jenkins平台上完成了所有应用的启动、关闭、重启、状态查看操作，方便运维来操作。既然做到了这一步，为什么不再进一步呢？为什么还需要运维来操作应用的重启呢？能不能自动来完成？

为了更进一步解决应用重启这类高频操作，准备使用进程管理工具来管理这些应用，出现问题之后，可以自己拉起，减少运维同学操作，避免人工过多参与。

调研了systemd、supervisor、monit三种常用工具
systemd 虽然功能丰富，性能强大，但使用成本较大，并且只能使用root，没有可视化集群管理界面。而服务要求必须使用非root操作，因此无法使用

supervisor 很轻巧，并且可有可视化管理界面，很实用，但最大问题是只能管理前台应用，当前线上所有应用通过云翼部署，通过云翼启停进行控制，因此需要改造，改造成本太大。可以使用，但需改造每个应用启停脚本
supervisor管理界面：

monit 使用也很方便，比supervisor更灵活些，可以管理前台、后台应用，并且可以自定义start、stop、check条件，最大问题是脚本路径不支持正则，必须是确定的，通过云翼部署的任务，无法做到这一点，对接成本较大

小结

对接monit来实现应用监控，成本最低。但也存在几个改造点：

• 解决应用启停控制脚本路径变化问题

操作任务化过程中，遇到哪些主要问题？

• 如何梳理运维操作。运维操作很杂、很琐碎，需要按照一个统一维度去梳理
  大数据组件常用操作。针对大数据组件任务操作，需要有一定大数据运维经验积累。比如Namenode主备切换等，再完善Job过程中，还需要关注任务的鲁棒性
  任务搜索。比如，我期望找kafka topic配置更新操作，上百个Job中，你很难快速找到，这时需要有一定命名规范