服务器越来越多不好管？我用Spug把主机、脚本和Web终端集中到一个运维后台

前言

脚本当然能做运维，但当服务器越来越多、操作开始重复、执行记录需要追溯时，问题往往不在“会不会写 Shell”，而在于这些脚本散落在哪里、谁执行过、对哪些主机执行、结果是什么。个人机器还能靠记忆，团队一多就容易失控。

这次我把 Spug 部署到极空间，用 Docker Compose 同时运行 Spug 和 MySQL，把 Web 端映射到 8086。安装完成以后再初始化管理员账号，实际添加主机、打开 Web 终端、批量执行 Shell / Python 脚本，并测试文件上传。

本地运维链跑通以后，再用 cpolar 给 8086 增加外部访问入口，从随机公网地址切换到固定二级子域名，让人在外面也能进入同一套运维后台。

整篇重点不是“从此再也不用写脚本”，而是把脚本、主机、执行过程和结果放进统一界面里管理。对经常重复执行命令、批量维护多台主机的人来说，可视化最大的价值其实是让操作过程更集中、更容易回看。

这类平台真正有价值的地方，也不是把所有运维动作都“点按钮化”，而是让高频任务有统一入口、统一目标和统一结果。尤其当脚本已经积累很多以后，集中管理比继续往个人电脑里堆文件更容易维护。

1 Spug更适合解决什么问题

Spug不是为了让运维人员彻底离开命令行。

它更适合解决这些日常问题：

• 主机越来越多，连接入口分散；
• Shell、Python脚本到处保存；
• 同一条命令需要在多台服务器重复执行；
• 操作结果不好统一查看；
• 团队成员之间缺少统一入口；
• 需要保留执行记录和操作过程。

把这些能力集中到一个Web后台以后，脚本仍然存在，但执行方式从“每个人各自终端操作”变成了“统一平台管理”。

2 这篇实际要跑通哪些内容

整个过程可以拆成四段：

第一段：

极空间 → SSH → Docker

第二段：

Docker Compose → MySQL + Spug → 8086

第三段：

Spug → 主机管理 → Web终端 → 批量脚本 → 文件上传

第四段：

外部浏览器 → 固定公网地址 → Spug:8086

先把本地运维功能跑通，再处理远程访问。

3 Spug适合哪些运维场景

从这次实际使用的功能来看，更适合：

• 中小规模服务器管理；
• 日常批量命令；
• Shell / Python脚本执行；
• Web终端；
• 文件上传；
• 主机分组；
• 定时任务；
• 应用发布；
• 团队协作和执行记录。

它的价值不是“功能越多越好”，而是：

把常用运维动作放到同一个入口里。

4 先通过SSH进入极空间

开启SSH以后，从电脑终端连接：

ssh root@IP

连接成功：

后面的Docker和Compose操作都在终端里完成。

5 先确认Docker环境

执行：

docker -v 
systemctl status -v

极空间页面也可以直接查看Docker状态：

接着再次确认Docker版本：

docker --version

结果：

确认Docker环境正常以后，再继续创建Spug部署目录。

6 创建Spug目录

按本次部署命令执行：

mkdir -p /docker/spug
chmod -R 777 /spug

结果：

后面需要在部署目录里保存：

• MySQL数据；
• Spug数据；
• 仓库目录；
• docker-compose.yml。

7 创建docker-compose.yml

执行：

vi docker-compose.yml

然后写入本次使用的Compose配置：

version: "3.3"
services:
  db:
    image: mysql:8.0
    container_name: spug-db
    restart: always
    networks:
      - spug-net
    #command: --port 3306 --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    command:
      - --default-authentication-plugin=mysql_native_password
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_unicode_ci
    volumes:
      - ./mysql:/var/lib/mysql
    environment:
      - MYSQL_DATABASE=spug
      - MYSQL_USER=spug
      - MYSQL_PASSWORD=spug.cc
      - MYSQL_ROOT_PASSWORD=spug.cc
  spug:
    image: openspug/spug-service
    container_name: spug
    privileged: true
    restart: always
    networks:
      - spug-net
    volumes:
      - ./service:/data/spug
      - ./repos:/data/repos
    ports:
      # 如果8086端口被占用可替换为其他端口，例如: - "8000:80"
      - "8086:80"
    environment:
      - MYSQL_DATABASE=spug
      - MYSQL_USER=spug
      - MYSQL_PASSWORD=spug.cc
      - MYSQL_HOST=db
      - MYSQL_PORT=3306
    depends_on:
      - db
networks:
  spug-net:

这份配置同时启动两个容器：

MySQL 8.0

以及：

openspug/spug-service

其中Spug对外映射：

8086:80

所以浏览器后面访问的是极空间的8086端口。

8 这篇部署方式实际依赖MySQL

虽然Spug常被描述为轻量化运维平台，但这次Docker Compose配置里明确运行了：

mysql:8.0

并为Spug设置：

• 数据库：spug
• 用户：spug
• 密码：spug.cc
• 数据库主机：db
• 数据库端口：3306

所以本文实际跑通的是：

Spug容器 + MySQL容器

这一套Docker部署方式。

9 启动Spug和MySQL

执行：

docker-compose up -d

结果：

两个服务启动以后，下一步直接从浏览器验证Web页面。

10 浏览器访问8086

访问：

http://极空间IP:8086

页面：

能够正常打开Spug页面以后，可以确认：

浏览器 → 极空间8086 → Spug容器80

已经跑通。

11 初始化管理员账号

执行：

docker exec spug init_spug admin admin

这次示例创建：

• 用户名：admin
• 密码：admin

执行页面：

初始化成功：

这里的admin/admin只是实操示例。

如果准备长期使用，尤其后面还要做远程访问，登录以后应该更换成自己实际使用的强密码。

12 登录Spug

登录页面：

进入后台：

到这里，本地Spug管理后台已经可以正常使用。

13 第一件事：添加目标主机

点击：

新建主机

页面：

填写目标服务器相关信息，并输入账号密码：

保存以后回到主机管理：

现在已经可以在Spug里统一看到这台服务器。

14 Web终端比“每次重新开SSH”更方便

选中目标主机以后点击：

Web终端

页面：

连接成功：

这样一些临时检查和命令操作，可以直接在浏览器里完成。

对已经有多台服务器的人来说，最大的变化不是SSH本身变了，而是：

连接入口集中到了Spug。

15 接下来测试批量执行脚本

进入批量执行功能：

先选择目标主机。

然后编写需要执行的Shell或Python脚本。

这次测试创建一个：

ooo

目录：

执行以后查看结果：

16 回目标主机确认脚本确实生效

继续检查目标目录：

可以看到目录已经创建成功。

这一步比单纯看到Spug页面显示“执行成功”更重要。

因为真正需要验证的是：

Spug发出的任务 → 目标主机实际发生变化。

17 批量执行真正适合重复任务

如果只操作一台服务器，直接SSH也很方便。

Spug更有价值的场景是：

• 同一条命令执行多台服务器；
• 多台服务器统一检查；
• 固定脚本反复调用；
• 团队成员复用相同任务；
• 需要集中查看输出结果。

也就是说，它不是替代Shell。

而是：

把Shell脚本的执行入口、目标主机和结果统一管理。

18 继续测试文件上传

进入文件相关功能：

上传完成以后，到目标服务器的：

/app

目录查看：

文件已经正常出现。

这样除了命令和脚本之外，常用文件操作也能从同一个后台完成。

19 Spug还有哪些能力

功能页面：

后面还可以继续使用：

• 主机组；
• 定时任务；
• 应用发布；
• 脚本管理；
• 权限控制；
• 操作日志。

这篇没有把所有模块逐个展开，重点先验证最常用的主机管理、终端、脚本和文件操作。

20 本地运维链到这里已经跑通

当前结构已经是：

极空间Docker

↓

MySQL + Spug

↓

Spug Web:8086

↓

目标主机

↓

Web终端 / 脚本 / 文件

如果只在公司或家庭局域网使用，做到这里已经够了。

只有确实需要异地运维时，再继续开放远程入口。

21 运维后台做公网访问要比普通网页更谨慎

Spug不是展示页面。

它可以：

• 登录服务器；
• 执行Shell；
• 执行Python；
• 上传文件；
• 进行批量操作。

也就是说，一旦账号权限较高，这个后台本身就是高权限入口。

所以公网访问时不能只关注：

“能不能打开页面。”

还要同时关注：

• Spug管理员密码；
• 用户权限；
• 目标主机账号权限；
• 公网地址传播范围；
• 日常操作审计。

cpolar负责网络入口，Spug负责运维业务和账号权限，两层不能混在一起理解。

22 安装cpolar

执行：

sudo curl https://get.cpolar.sh | sh

结果：

然后检查服务状态：

sudo systemctl status cpolar

结果：

确认服务正常以后，再进入cpolar管理页面。

23 打开cpolar Web UI

通过：

极空间IP:9200

进入管理界面：

登录以后，后面的公网地址都在这里配置。

24 给Spug的8086创建HTTP隧道

创建参数：

• 隧道名称：spug
• 协议：HTTP
• 本地地址：8086
• 域名类型：随机域名
• 地区：China Top

配置页面：

这里映射的是Spug实际提供Web服务的8086端口。

25 先用随机公网地址测试

进入在线隧道列表：

从其他网络打开生成的公网地址：

能够正常进入Spug以后，可以确认：

外部浏览器 → 公网地址 → 极空间8086 → Spug

已经跑通。

26 随机域名适合先验证

如果只是临时远程处理服务器，随机地址已经可以使用。

但如果准备长期保存入口，随机地址变化以后会比较麻烦。

所以后面继续配置固定二级子域名。

27 保留固定二级子域名

进入预留页面：

这次示例名称：

spug

保留页面：

实际使用时，以自己账号最终成功保留的名称为准。

28 编辑Spug隧道

回到：

隧道管理 → 隧道列表

找到对应隧道：

进入编辑以后修改：

• 域名类型：二级子域名；
• Sub Domain：填写已经保留的名称；
• 地区：China Top。

更新：

29 查看固定地址是否已经生效

回到在线隧道列表：

可以看到原来的随机地址已经切换成固定二级子域名。

30 最后从外部设备再访问一次

使用固定公网地址：

能够正常进入以后，长期远程入口已经完成。

整条链现在变成：

外部浏览器 → 固定公网地址 → 极空间8086 → Spug → 目标服务器

31 固定地址不等于安全已经完成

固定地址解决的是：

入口不再频繁变化。

它不代表：

• 管理员账号自动安全；
• 主机权限自动最小化；
• 所有人都应该能访问；
• 运维操作不需要审计。

Spug属于高权限后台，长期远程使用时更应该：

• 修改默认管理员密码；
• 给不同成员分配不同权限；
• 不共享高权限账号；
• 定期检查操作记录；
• 控制公网入口的使用范围。

32 Spug和脚本真正是什么关系

更准确的理解不是：

Spug替代脚本。

而是：

Spug把脚本、主机、执行目标和结果集中起来。

如果脚本本身有问题，换成可视化平台并不会自动修好。

但当脚本已经成熟以后，Spug可以让它们：

• 更容易复用；
• 更容易批量执行；
• 更容易让团队成员调用；
• 更容易看到结果。

33 这套方案更适合什么人

比较适合：

• 有多台服务器；
• 经常重复执行命令；
• 需要批量操作；
• 团队里有多人参与运维；
• 希望保留统一入口；
• 想减少每个人各自维护脚本的情况。

如果只有一台服务器，平时也只是偶尔SSH进去改一两处配置，那么直接使用SSH可能已经够用。

34 最后把整条技术链重新看一遍

基础环境：

极空间 → SSH → Docker

部署：

Docker Compose → MySQL + Spug

端口：

8086:80

初始化：

init_spug → admin

运维：

主机管理 → Web终端 → 批量脚本 → 文件上传

随机远程：

公网随机地址 → 8086

固定远程：

固定二级子域名 → 8086

实际完成：

• SSH登录；
• Docker环境确认；
• Compose配置；
• MySQL容器；
• Spug容器；
• 8086本地访问；
• 管理员初始化；
• 主机添加；
• Web终端；
• Shell / Python批量执行；
• 文件上传；
• cpolar安装；
• 随机公网访问；
• 固定二级子域名；
• 外部设备访问。

这样Spug才真正从“装起来了”变成一套可以日常使用的可视化运维入口。

总结

这次真正跑通的是一条完整的Spug运维链：先在极空间确认SSH和Docker环境，通过Docker Compose启动MySQL与Spug，再通过8086进入Web后台并初始化管理员账号。

本地功能验证没有停在“页面能打开”，而是继续添加目标主机，实际打开Web终端、执行Shell脚本，并回目标服务器确认目录确实创建成功，同时测试了文件上传。这样才能证明Spug已经真正参与到日常运维流程里。

远程部分是在本地功能正常以后再增加的能力。随机公网地址先验证链路，固定二级子域名再解决长期入口变化的问题；但Spug属于高权限运维后台，固定地址本身并不等于安全，管理员密码、用户权限和操作记录仍然需要单独管理。

Spug更适合被理解成“脚本和主机的统一执行平台”，而不是“以后再也不用写脚本”。真正成熟的脚本依然有价值，只是通过Spug以后，它们更容易被集中管理、批量执行和团队复用。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/2302_78391795/article/details/168124780