把闲置的甲骨文 ARM 服务器变成 CI/CD 中枢：一次 hermes-agent 实战

发表于 阅读次数： 本文字数： 3.9k 阅读时长 ≈ 7 分钟
记录我如何用 hermes-agent、GitLab 和 GitLab Runner，把云雀通 Larktun 文档站从手动部署改造成自动发布流程。

最近我给自己的新产品「云雀通」Larktun 做了一个文档网站。源码放在 GitHub 上，公开访问，日常更新也很简单：我在本地电脑或笔记本上改文档，确认没有问题后提交到 GitHub。

问题出在「部署」这一步。

之前我一直是手动发布。倒不是不想自动化，而是生产服务器配置比较低，不适合把 Node 依赖安装、站点打包、发布脚本这些事情都压在它身上。身边也没有一台现成的 Jenkins 或 CI 服务器。与此同时，我又申请了一台甲骨文免费的 ARM 服务器，配置是 4 核 24G 内存，长期闲置有点可惜。

于是我开始琢磨：能不能把这台闲置服务器变成自动化发布中枢？真正线上服务仍然跑在原生产服务器上，但构建、同步、流水线、部署控制这些重活交给甲骨文服务器。

这一次，我没有手工从零搭环境，而是让 hermes-agent 接管了从方案完善到落地实施的大部分工作。hermes 绑定的是 ChatGPT，使用 gpt-5.4 模型。最后形成的链路是：

我本地更新文档 -> GitHub -> GitLab -> GitLab Runner -> deploy -> 生产服务器更新 -> 发布成功

云雀通 Larktun 文档站自动发布架构

背景：为什么不直接用 GitHub Actions

对一个公开文档站来说，GitHub Actions 当然是一个很自然的选择。但这次它并不适合我的场景。文档站最终要部署到正式生产服务器，而这台服务器的安全管控比较严格，不能随意把外部 CI 的访问权限接入生产环境。换句话说，GitHub 可以继续作为公开源码仓库，但 GitHub Actions 不能直接进入生产发布链路。

所以我的目标不是「找一个最常见的 CI」，而是在安全边界可控的前提下，把现有资源利用起来，同时尽量不改动自己的工作习惯。

我当时的约束大概有几个：

  1. 文档源码已经在 GitHub，继续保留 GitHub 作为公开协作入口。
  2. 生产服务器配置较低，不希望在上面执行安装依赖、构建前端、跑流水线等任务。
  3. 甲骨文免费 ARM 服务器配置不错，适合承担 GitLab、Runner、构建缓存和自动化任务。
  4. 生产服务器是正式环境，安全管控严格，不适合让 GitHub Actions 这类外部 CI 直接持有发布权限。
  5. 生产发布需要可控，最好使用专门的低权限账号，避免 CI 拿到过大的服务器权限。
  6. 我希望后续不只是这个文档站，其他小项目也能复用这套发布基础设施。

所以最终方案不是把所有东西塞进生产服务器，也不是完全依赖外部平台，而是让甲骨文服务器承担「自动化控制平面」的角色。

方案：GitHub 保持入口，GitLab 负责自动化

整个结构可以理解为两层：

第一层是内容协作层。我仍然在本地写文档、预览、提交，然后推送到 GitHub。这个路径不变，因为它已经足够顺手。

第二层是发布自动化层。甲骨文服务器上部署 GitLab，并将 GitHub 文档仓库同步到 GitLab。GitLab Runner 监听仓库更新，触发打包流程，构建完成后通过专门的 deploy 账号发布到生产服务器。

从本地修改到生产发布的流程

这个方案的好处是职责很清晰：

环节 职责 放在哪里
写作与源码托管 修改文档、提交代码、公开访问源码 本地电脑 + GitHub
自动化控制 仓库镜像、流水线、任务调度 甲骨文 ARM 服务器
构建 安装依赖、生成静态站点产物 GitLab Runner
发布 上传产物、切换线上版本 生产服务器 deploy 账号
访问 对外提供文档网站 生产服务器

这里面最关键的一点是：生产服务器不参与构建。它只接收已经构建好的静态文件，并完成一次轻量级发布。

hermes-agent 做了什么

我先把自己的想法告诉 hermes-agent：我有一台甲骨文 ARM 服务器，有一个 GitHub 上的文档站仓库，有一台低配置生产服务器，希望实现自动打包和自动发布。

它先帮我完善方案，把实施过程拆成几个阶段：

  1. 在甲骨文服务器上准备基础环境。
  2. 部署 GitLab，并配置从 GitHub 同步文档仓库。
  3. 安装并注册 GitLab Runner。
  4. 编写 CI 流水线，让 Runner 完成依赖安装和文档站打包。
  5. 为生产服务器创建专门的 deploy 用户。
  6. 配置 SSH key、发布目录和权限边界。
  7. 编写部署脚本，保证发布过程中网站不会异常。
  8. 跑通一次完整链路，并根据失败日志继续修正。

然后它开始执行。

比较有意思的是，hermes-agent 在需要敏感信息的时候会停下来问我。例如 GitLab token、SSH 私钥、公钥部署、生产服务器地址和 deploy 用户信息，这些它不会凭空假设，也不会试图绕过授权。我的角色从「执行每一条命令」变成了「确认方案并提供必要密钥」。

剩下的事情，基本都由它完成：安装 GitLab、部署 GitLab Runner、配置仓库同步、编写流水线、调试构建环境、调整发布脚本、处理权限问题，直到最后能够自动把文档站发布到生产服务器。

发布时为什么不会影响线上访问

我最关心的一点，是自动发布不能把线上文档站搞挂。

如果直接在网站目录里覆盖文件，发布过程中很容易出现短暂的不一致：有些文件已经更新，有些文件还没更新；用户访问时可能遇到资源 404、页面样式错乱，甚至空白页。

更稳妥的做法是「构建产物先上传到新目录，确认完整后再切换线上指针」。也就是说，Runner 先把新的静态文件上传到生产服务器的某个 release 目录，比如：

1
/var/www/larktun-docs/releases/20260426-1130

上传完成后，再把 current 指向这个新目录：

1
/var/www/larktun-docs/current -> /var/www/larktun-docs/releases/20260426-1130

Nginx 或其他 Web 服务始终读取 current。这样发布动作本质上就是一次目录指针切换，速度很快，也方便回滚。

静态文档站的零停机发布模型

这个策略带来的安全感很明显：如果构建失败，不会发布；如果上传失败，不会切换；只有新版本完整到达生产服务器之后，才会让线上流量看到它。

这套链路的实际收益

改造完成后，我的日常操作变成了：

1
2
3
4
5
本地修改文档
提交到 GitHub
等待 GitLab Runner 自动构建
自动发布到生产服务器
验证线上页面

和过去相比，最大的变化不是「少敲了几条命令」，而是发布过程变得稳定、可追踪、可复用。

过去手动部署时，我需要记住在哪台机器上执行什么命令、构建产物放在哪里、发布目录怎么更新、失败了怎么恢复。现在这些动作被写进流水线和脚本里，每次都按同样的方式执行。

对我来说，这就是自动化最有价值的地方：它把临时经验变成了可重复流程。

安全边界也要提前想清楚

这类自动化方案一旦涉及生产服务器，安全边界必须明确。我的处理方式是给生产服务器专门创建一个发布账号，而不是直接使用 root。

这个 deploy 账号只需要拥有文档站发布目录的权限，不应该能随便操作系统其他目录。SSH key 也只服务于发布流程，后续如果泄露或不再使用，可以单独吊销。

我建议至少注意这几件事：

  1. CI/CD 使用专门的 deploy 用户，不使用 root。
  2. 发布目录和服务目录权限分离，不给过大的写权限。
  3. SSH 私钥、GitLab token 等敏感信息只放在 GitLab CI 变量或受控位置。
  4. 生产服务器保留最近几个 release，方便快速回滚。
  5. 首次跑通后，整理关键命令和恢复流程，避免以后只剩「它当时能跑」。

hermes-agent 能把大量工程细节执行到位，但最终的安全策略仍然要由人来确认。尤其是密钥、权限、生产服务器访问范围这些部分，不能完全交给自动化惯性。

关于 hermes-agent 的使用感受

这次体验让我对 agent 类工具的定位有了更具体的认识。

它不是一个只会回答问题的聊天窗口，而更像一个能持续推进任务的远程工程助手。传统上，我可能会问「GitLab Runner 怎么装」「GitLab 怎么同步 GitHub」「rsync 怎么做发布」，然后自己把答案拼起来。hermes-agent 的不同之处在于，它可以从目标出发，把这些步骤串成一个完整方案，并持续执行到环境真正跑起来。

当然，这不代表人可以完全放手。我的参与点仍然很关键：

  1. 明确目标：我要的不是炫技，而是让文档站稳定自动发布。
  2. 提供上下文：服务器配置、仓库位置、生产环境限制、密钥来源。
  3. 审核方案：确认 GitLab、Runner、deploy 用户这些设计是否符合自己的长期维护习惯。
  4. 掌握边界：敏感密钥由我提供，生产权限由我控制。
  5. 验收结果：最终以线上文档站是否正常发布为准。

这更像是一种新的协作方式：人负责目标、边界和验收，agent 负责把中间大量繁琐但可执行的工程步骤推进下去。

小结

这次 hermes-agent 实战，最终把一台闲置的甲骨文免费 ARM 服务器变成了云雀通 Larktun 文档站的 CI/CD 中枢。

现在我的发布链路是：

1
本地电脑 -> GitHub -> GitLab -> GitLab Runner -> deploy -> 生产服务器 -> 发布成功

hermes-agent 帮我完成了从 GitLab 开始的大部分工作：部署 GitLab、配置 Runner、同步仓库、编写流水线、设置发布流程、处理构建和权限问题。除了密钥和关键权限由我提供与确认，其余部分基本由它连续推进完成。

这篇文章记录的不是一个复杂到无法复制的架构，而是一个很适合个人开发者、小团队和轻量产品的实践：把闲置资源用起来，把手动经验固化成流水线，把生产服务器从构建压力中解放出来。

对我来说，这就是 hermes-agent 最有价值的地方。它没有替我决定产品方向，却帮我把一个长期想做、但一直嫌麻烦的基础设施任务真正落地了。

gitlab