用 DSH 辅助部署一个网站监控平台:Uptime Kuma + Docker 实战

最近在用 DSH(DeepSeek Harness)辅助做一些项目,发现它除了改代码,也很适合用来整理部署步骤、检查配置和排查日志。

这次不做简单的"Hello World",而是部署一个能实际使用的开源项目:Uptime Kuma。它能监控网站或接口的在线状态,支持创建监控项、查看历史记录和配置通知。项目地址:https://github.com/louislam/uptime-kuma

本文提供可以复现的部署流程和 DSH 提示词。命令已对照项目安装文档整理,但不同服务器的实际运行结果请以自己的终端为准;截图请在操作完成后补充。

1. 准备环境:一台 Linux 服务器和 DSH

建议使用 Ubuntu 22.04/24.04 等常见发行版,具备 SSH 登录权限,且服务器已经可以正常访问互联网。对少量网站进行基础监控,可以先用轻量级实例尝试,实际内存和 CPU 占用取决于监控数量、间隔和启用的功能。

如果只是想找一台临时机器练手,也可以查看慈云数据目前开放的公益云服务,体验资源和库存以页面为准:

https://www.ciyundata.com/plugin/189/free_cloud.htm?ref=2D5BE062

DSH 是 DeepSeek Harness,官方提供 Web UI,支持文件编辑、Shell 命令等操作。可以在本地电脑的项目目录中运行:

bash 复制代码
npx @deepseek-ai/dsh web

需要符合其 Node.js 版本要求并按官方说明完成模型配置,默认 Web UI 地址为 http://127.0.0.1:3080。官方参考:https://www.scnet.cn/help/docs/mainsite/mass/tools/deepseek-harness.html

注意:本地启动 DSH 并不代表它已经登录云服务器。 后面的 Linux 命令可以先由 DSH 生成、人工审阅后通过 SSH 执行;如已配置可信的远程 SSH 工作区,也可以在明确目标主机和权限后让 DSH 辅助执行。不要把 root 密码或 API 密钥直接粘贴到聊天记录中。

2. 先让 DSH 制定部署检查清单

我会先给 DSH 这样一段需求,而不是让它直接执行一串未知命令:

我准备在一台 Ubuntu Linux 云服务器上用 Docker 部署开源监控平台 Uptime Kuma 2.x。请先帮我整理部署前的检查清单:系统版本、磁盘空间、Docker 和 Compose 是否存在、端口占用、防火墙和数据备份。先给出只读检查命令,再给出安装方案,不要执行破坏性操作,也不要修改现有业务。

服务器上可运行:

bash 复制代码
cat /etc/os-release
uname -m
free -h
df -h
command -v docker || true
docker compose version 2>/dev/null || true
sudo ss -lntp | grep ':3001 ' || true

检查的目的是确认机器环境和端口可用,不是单纯跑完命令就算部署成功。

3. 安装 Docker(若尚未安装)

已经安装 Docker Engine 和 Compose 插件的服务器可以跳过本节。Ubuntu 上建议按 Docker 官方安装文档添加官方软件源并安装,不要盲目复制网上来源不明的一键脚本。

官方文档:https://docs.docker.com/engine/install/ubuntu/

安装完成后验证:

bash 复制代码
sudo docker version
sudo docker compose version

如果 DSH 给出了安装命令,先检查其来源、发行版适配情况以及是否会影响现有容器,再执行。

4. 正式部署 Uptime Kuma

下面采用 Docker Compose,数据单独持久化到本机目录。为避免在设置管理员账号前把后台直接暴露到互联网,先只监听本机回环地址 127.0.0.1。

bash 复制代码
sudo mkdir -p /opt/uptime-kuma
cd /opt/uptime-kuma
sudo mkdir -p data

创建 compose.yaml:

yaml 复制代码
services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - ./data:/app/data

启动服务:

bash 复制代码
cd /opt/uptime-kuma
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs --tail=50
curl -I http://127.0.0.1:3001

服务启动后,curl 返回 HTTP 状态码或跳转响应即可作为初步连通性证据,仍需在浏览器完成初始化。

Uptime Kuma 官方 2.x 安装文档使用 louislam/uptime-kuma:2,并提醒持久化数据库所在文件系统需要支持 POSIX 文件锁,避免将数据目录随意放在存在锁兼容性问题的网络文件系统中。

官方安装文档:https://github.com/louislam/uptime-kuma/wiki/🔧-How-to-Install

5. 在本地浏览器访问后台

因为前面没有开放公网 3001 端口,可以在自己电脑上建立 SSH 隧道:

bash 复制代码
ssh -L 3001:127.0.0.1:3001 用户名@服务器公网IP

保持连接,然后在自己电脑的浏览器打开:

http://127.0.0.1:3001

按页面提示创建管理员账户并登录。这样可以在没有公开暴露后台的情况下完成初始化。

如果计划长期对外访问,再考虑配置 HTTPS 域名、反向代理、访问控制和安全组,而不是直接把未加保护的管理面板开放到公网。

6. 添加第一个真实监控目标

以自己管理的网站或 API 为例:

  1. 在后台点击"添加监控项"。
  2. 类型选择 HTTP(s)。
  3. 填写监控名称,如"我的测试站"。
  4. 在 URL 中填写自己拥有或已获授权的网站地址。
  5. 设置合理的监控间隔,保存后观察状态变化。

也可以监控自己部署的 API 健康检查接口,例如:

text 复制代码
https://example.com/health

如果页面展示为"正常运行",再通过后台检查响应时间和历史记录。不要用高频探测对第三方网站进行未经授权的压力测试。

7. 用 DSH 辅助排查服务异常

如果浏览器访问失败,不必立刻重装。先检查服务状态:

bash 复制代码
sudo docker compose -f /opt/uptime-kuma/compose.yaml ps
sudo docker compose -f /opt/uptime-kuma/compose.yaml logs --tail=100
sudo ss -lntp | grep 3001 || true
curl -v http://127.0.0.1:3001

把脱敏后的输出交给 DSH:

我使用 Docker Compose 部署 Uptime Kuma 2.x,浏览器无法打开。以下是 compose.yaml、docker compose ps、最近 100 行日志和本机 curl 结果。请按"容器进程 → 服务监听 → SSH 隧道 → 浏览器访问"顺序排查,先说明每个异常可能意味着什么,再给出风险最低的验证命令。不要让我直接清空 data 目录或重新创建所有容器。

这样 DSH 的作用不只是生成一条安装命令,而是协助整理可验证的排障路径。

8. 数据备份和维护

监控数据默认保存在映射的 ./data 目录中。备份前应先考虑数据库一致性,最简单的维护窗口操作方式是停止容器后备份:

bash 复制代码
cd /opt/uptime-kuma
sudo docker compose down
sudo tar -czf /root/uptime-kuma-backup-$(date +%F).tar.gz data
sudo docker compose up -d

上述操作会导致短暂监控中断。生产环境需要规划更完整的备份、恢复验证与更新流程。不要把单份备份长期只留在原服务器上。

如果后续升级,先备份并阅读对应版本的发布说明,再拉取新镜像:

bash 复制代码
cd /opt/uptime-kuma
sudo docker compose pull
sudo docker compose up -d

9. 临时云服务器到期怎么办?

这类项目如果只是用于学习 Docker、熟悉监控系统和验证部署流程,不一定需要长期购买服务器。

前面提到的公益云服务带有任务中心,符合活动要求的用户可以通过完成任务、邀请好友等方式获取额外使用天数。具体奖励、审核条件与库存请以实际页面为准。

**

**

需要提醒的是:监控系统本身最好运行在稳定、独立且持续在线的环境中。 如果把它放在可能到期回收的免费体验实例上,监控也会跟着中断。因此免费实例更适合做学习和功能验证,重要业务应迁移到长期维护的环境。

10. 总结

这次实战的完整链路是:准备 Linux 服务器 → 使用 DSH 整理部署计划 → 安装 Docker → Compose 部署 Uptime Kuma → SSH 隧道访问 → 添加监控 → DSH 辅助排错 → 备份数据。

相比让 AI 直接"帮我把项目部署好",我更推荐让它先检查环境、解释命令、分析日志,再由自己确认关键修改。这样既能利用 AI 提高效率,也不会忽略服务器安全和数据管理。

如果你正准备学习 Docker 或者想搭建自己的小型网站监控平台,Uptime Kuma 是一个很适合动手的项目。建议把真实执行过程中的终端输出和界面截图补齐,再整理成自己的实践记录。


资料链接

相关推荐
毒爪的小新1 小时前
最新 Dify 1.14.0+ 内网离线插件打包、部署完整踩坑方案(解决 uv.lock 依赖校验失败)
运维·ai·uv·dify
静以修身zzz1 小时前
OpenStack对象存储-Swift、OpenStack编排管理-heat、OpenStack网络管理-neutron
linux·运维·服务器·架构·openstack·swift
东鹏特饮1 小时前
本机状态监控页面html
运维·css·html·css3
螺蛳粉 螺蛳粉1 小时前
第 03 篇:为什么 K8s 的最小调度单元是 Pod 而不是容器:pause 容器与边车模式(底座认知 03)
docker·云原生·容器·kubernetes·etcd·运维排障·kube-apiserver
艾伦_耶格宇1 小时前
【kubernetes - 1.28版本】-9 K8S-dashbord可视化界面
云原生·容器·kubernetes
Gauss松鼠会2 小时前
GaussDB 整体架构解析
运维·服务器·网络·数据库·sql·架构·gaussdb
Gauss松鼠会2 小时前
GaussDB 中 gsql 与 DBeaver(JDBC)客户端工具查询时间不一致:原因、排查与处理
运维·服务器·数据库·sql·gaussdb·经验总结
谙弆悕博士2 小时前
debian快速换源
linux·运维·windows·debian·下载·换源·网络问题
.道阻且长.2 小时前
Linux基本开发工具:编译器gcc/g++
linux·运维·服务器·职场和发展