Luskey已从地狱归来

灯火烛天

2026-05-18

技术

2 4.5~5.7 分钟 2011

地址：blog.lightupsky.com
如果你不知道 Luskey 是什么玩意，这类似于你当前访问的我的博客的/docs 页面，存放一些分类明确的文档集合。更明确来说，我在 Luskey 最初是翻译校对自己玩的放置游戏的英文攻略，后来也自己写了点攻略，又把填词等一股脑放了上去。
后来用于搭建它的 VPS 到期了，我便暂时将其一部分内容放在了/docs 下方，但很显然，预览的效果不佳。
本质上，Luskey 是 Quartz V4 将Obsidian 语法下的一系列.md 文件转换为网页文件，再用 nginx 托管为静态网页。
过去的部署有不少坑，最麻烦的便是非自动化构建流程。我先要耐心等待 verysync 将我本地设备的修改文件同步到服务器上的 /quartz/content 目录，再去 ssh 链接服务器执行 npx quartz build，将/public 下方文件复制到 nginx 网站目录下。
尽管写了个脚本来优化流程，但也只是从多次执行命令变成执行一次脚本。定时执行 build 又太死板和浪费资源，归根结底，verysync 的同步机制并不稳定，总是疲于来回比对确认服务端是否成功接收了最新版本的文档；手机端还需要额外保持微力同步的后台活动，实际上也是根本活不下去。

Luskey 的复活又经历了两个阶段，其一是自部署的 Gitea，在 Obsidian 中通过 Quartz Syncer 插件向仓库推送文件更新， Web Hook 触发 VPS 端本地 quartz build，最后将文件推送到 openresty 网站目录下。但最终，我又换成了仓库放在腾讯云旗下的云原生开发平台 cnb，自动构建后部署到 EdgeOne Pages 的方式。
接下来，我将逐步介绍这两种部署方法，以及为什么要换方案。

Gitea WebHook

归根结底，WebHook 本就是权宜之计。我本就想用 Gitea Act Runner 实现 CI/CD 自动化构建，但实行起来很困难。
即便在我养的啥子龙虾的帮助下，还是失败了。由于我的 Gitea 本就是 Docker 部署，Act Runner 执行 quartz build 时需要 npm 与 node 22 环境，就要把这些环境与之一同打包为新的 Docker 自定义镜像。这是我完全陌生的领域，尝试构建了一个 dockerfile 后也完全跑不起来。
转念一想，只要能让文件到达 VPS 上 quartz 仓库所在的目录，后续的构建和部署都很容易。于是龙虾出马写了一串串我看不懂的神必脚本：

const http = require("http");
const { exec } = require("child_process");

const PORT = 3000;

const server = http.createServer((req, res) => {
  if (req.method === "POST" && req.url === "/webhook/quartz") {
    let body = "";
    req.on("data", chunk => { body += chunk.toString(); });
    req.on("end", () => {
      try {
        const payload = JSON.parse(body);
        console.log("收到推送：" + payload.commits.length + " 个提交");
        exec("/opt/1panel/apps/quartz-dep/deploy.sh", (error, stdout, stderr) => {
          if (error) {
            console.error("部署失败:", error);
            res.writeHead(500);
            res.end("Deployment failed");
          } else {
            console.log("部署成功:", stdout);
            res.writeHead(200);
            res.end("OK");
          }
        });
      } catch (e) {
        res.writeHead(400);
        res.end("Invalid payload");
      }
    });
  } else {
    res.writeHead(404);
    res.end("Not found");
  }
});

server.listen(PORT, "0.0.0.0", () => {
  console.log("Web Hook 服务运行在端口 " + PORT);
});

总体逻辑我还是看得明白。一旦 Gitea 仓库接受到 push 就触发 WebHook 向服务器 3000 端口推送一个命令，接受到命令的 VPS 执行 deploy.sh，拉取仓库更新的文件到本地，在本地仓库目录执行 build 后，清空网站目录并将最新生成的 public 文件剪切到网站目录。
呃...真是绕了好大一圈啊。

哒哒哒哒哒，好想玩原生

云原生开发，启动！
环境配好确实很爽。而且 cnb 的流水线命令格式很友好，不借助 AI，只要知道自己需要怎样的镜像来构建（此处为 node22-alpine），就可以直接调用，只需要区区几行 .cnb.yml：

v4-deploy:
  push:
    eo_deploy:
      runner:
        cpus: 16
      stages:
        - name: Build
          image: node:22-alpine
          script:
            - apk add --no-cache git coreutils
            - npm install
            - npx quartz build
        - name: Deploy to EdgeOne Pages
          imports:
            - https://cnb.cool/你的组织名称/envs/-/blob/main/envs.yml
          image: tencentcom/deploy-eopages:latest
          script: edgeone pages deploy ./public -n quartz-blog -t $EO_SECRET

非常轮椅。
哦对了，免费云构建时长 160 h/c/月，16 核执行就是 10 小时/月，大致能跑 400 次构建。静态博客基本是一文成稿后再集中调整发布，绰绰有余了。
这样的好处是不用花钱，除了域名，在使用 EdgeOne 加速中国大陆仍然需要合法备案后的域名。

后续

还是要把内容产出提升一下。
另外，对主站点的改造也在计划中。