【DevOps】Jpom&Spug

背景

使用jenkins作为DevOps工具，在实际使用中发现了一个问题，如果环境是在开发、测试、预发，一键部署问题都不大，即便是崩了那就崩了，但是线上环境不小心点了一下发布事情就大了，这就必须有一些手段来达到控制的目的，比如线上发布要审核等。

目的

各种环境便捷部署，并且带有权限控制，对线上环境的部署做一些审核控制等

介绍

Jpom跟Spug都是开源的DevOps工具，都能实现便捷部署，并且各自都有自己的一套权限控制体系

对比

	Jpom	Spug
开发语言	Java+Vue	Python+React
便捷部署	支持	支持
权限控制	支持	支持
监控报警	支持	支持
docker可视化	支持	不支持
应用一键启停	支持	不支持
ssh	支持	支持
文件上传下载	支持	支持

结论是Spug对比Jpom会更轻一些，但是从另一个角度上看Jpom提供了更强大的在线运维的能力

Jpom

github：GitHub - dromara/Jpom: 🚀简而轻的低侵入式在线构建、自动部署、日常运维、项目监控软件

gitee：Jpom: 简而轻的低侵入式在线构建、自动部署、日常运维、项目运维监控软件

第一步：安装

readme里面讲清楚了，这边直接上最简洁的通过docker-compose的方式

直接就是第五种方式，但是安装过程中出现了问题，Jpom在构建中使用了buildkit，但是我部署的机器docker的版本并不支持，所以最终通过升级docker解决了，这里记一下出现问题的docker版本

• docker：23.0.1
• docker-compose：1.26.2

升级之后的版本

• docker：24.0.7
• docker-compose：2.6.1

第二步：操作

监控机器

直接点击快速安装

这一行curl在需要监控的目标机器上执行，在目标机器上会启动一个插件（应用）并且监听2123端口，用于跟监控端进行交互，其他的自行查看

监控应用

其他方式看到基本就明白如何使用了，但是Dsl需要思考一下，具体看Dsl的脚本

# scriptId 可以是项目路径下脚本文件名或者系统中的脚本模版ID
description: 测试
run:
  start:
#    scriptId: project.sh
    scriptId: 
    scriptArgs: start
    scriptEnv:
      "boot_active": test
  status:
#    scriptId: project.sh
    scriptId: 
    scriptArgs: status
  stop:
#    scriptId: project.sh
    scriptId: 
    scriptArgs: stop
#  restart:
##    scriptId: project.sh
#    scriptId: 
#    scriptArgs: restart
#    scriptEnv:
#      "boot_active": test
file:
# 备份文件保留个数
#  backupCount: 5
# 限制备份指定文件后缀（支持正则）
#  backupSuffix: [ '.jar','.html','^.+\.(?i)(txt)$' ]
# 项目文件备份路径
#  backupPath: /data/jpom_backup
config:
# 是否开启日志备份功能
#  autoBackToFile: true

脚本里面加入了启动、查状态、停止、重启，这几个操作，这就是监控应用里面可以操作的能力

监控docker

docker的守护进程需要开启2375（默认）端口监听

# 修改docker的service文件
vim /usr/lib/systemd/system/docker.service

在ExecStart处加入 -H tcp://0.0.0.0:2375 -H unix://var/run/docker.sock

开启之后无脑添加即可，开启之后需要注意攻击，内网无所谓，外网添加ssl校验增加安全性

权限

权限的菜单通过工作空间的形式隔离，具体操作通过角色关联操作权限来区分

右边的节点菜单控制的是逻辑节点的详情的菜单权限

理解了他这种设计，操作起来还是很简单的

构建部署

具体示例可以直接看项目中的示例，这边提供一种构建加部署的思路

1. 通过平台打包成一个docker镜像，然后上传到私有部署的镜像库里面
2. 在通过应用里面的脚本把镜像拉到目标机执行部署

Spug

github：GitHub - openspug/spug: 开源运维平台：面向中小型企业设计的轻量级无Agent的自动化运维平台，整合了主机管理、主机批量执行、主机在线终端、文件在线上传下载、应用发布部署、在线任务计划、配置中心、监控、报警等一系列功能。

gitee：spug: 开源运维平台：面向中小型企业设计的无 Agent的自动化运维平台，整合了主机管理、主机批量执行、主机在线终端、文件在线上传下载、应用发布、任务计划、配置中心、监控、报警等一系列功能。

第一步：安装

没有任何痛点，按照官方文档直接安装即可

第二步：操作

监控机器

通过ssh的方式

监控其他

监控栏新增任务，Jpom的监控在Spug以这种方式都能满足

权限

权限最重要的就是角色的配置了，通过功能、发布、主机，这三个栏控制所有权限，并且spug控制了之后对应的按钮也会隐藏，体验比jpom强

构建部署

整个发布路径：新建应用->配置应用发布的环境（发布规则）->执行发布（可控权限）

在这里把应用跟发布环境（规则）配置完成，整个发布环境可以理解成打包机跟目标机，在打包机执行打包把应用包打出来，然后告诉Spug，Spug会把应用包部署到目标机器，然后自定义脚本把应用启动

每次需要发布的时候点新建发布即可，并且这个面板支持直接回滚

总结

这两款devops都试用了一下，对比下来Jpom会有一些门槛，Jpom设计了一些功能，通过这些功能来达到具体的目的（具体直接看操作介绍），但是刚接触是真的觉得很傻（至少我是这么觉得），而且Jpom对于权限在按钮层面只控制到了是否有权限，没有控制是否显示，这就导致你能看到一排按钮，但是每个按钮你点击就告诉你权限不足，所以就体验而言Spug更胜一筹。

回到最终目的，是为了带权限控制的DevOps，虽然Jpom使用Java二开的成本更低一些，但是Spug使用下来更舒服，功能层面Spug虽然简洁，但是也确实够用了，在我心里spug完胜。