用户定案:「辅助仓就用 openlist,其他不再考虑」。
据此把前一轮为 Gitee 铺的路全部收回,git 远端只剩 CNB 一个。
一、git 配置收口
- `pushall` 别名 `origin + gitee` → `!git push origin main`(只推唯一远端)
- 移除 `gitea` remote(自建 23.254.236.47:3001)—— 远端仓库本身没删,
需要时可 `git remote add` 恢复;改动前配置存
`.workbuddy-backup/git-remotes.20261006-211516.txt`
- 确认无 gitee 相关 credential 残留
二、发布链路去 Gitee 化(6 处)
- `deploy/editor-api/bootstrap.sh`
· 删掉 GITEE_URL / GITEE_SSH_KEY 两个变量与「没给私钥就降级」的分支
· PUSH_REMOTES 默认 → origin
· 原「配 gitee 辅仓远端」一节改为「清理退役远端」循环(gh/gitee/gitea),
让从旧部署续用的工作区自动恢复干净
- `docker-compose.editor.yml`、`editor-api/server.mjs` → 默认值 origin
- `editor-api/README.md` → 变量表同步
- `editor-api/Dockerfile` → 注释里的「CNB / GitHub」改「CNB」
- `blog-admin/src/routes/rss/tools.ts` → deploy-notify 的注释里
「与 Gitea Actions 的构建通知配套」改为中性描述
(该轮询链路 2026-10-04 起已被 CNB 国内节点直传取代)
三、`scripts/setup-cnb-remotes.sh` 重写为单远端模式
- 去掉 GITEE_URL / GITEE_TOKEN 参数、校验、凭据写入与自检提示
- 新增「清理退役远端」步骤
- 凭据处理改为「已存在空的 credential.helper 就不再添加」,
不再用 --replace-all —— 本仓另有一个从 `$HOME/.workbuddy/secrets/cnb-token`
读令牌的自定义 helper,那是有效的,不能被脚本抹掉
四、备份升级为「唯一辅仓」的配置
- 保留份数 3 → 7(一周窗口;每份 605.5 MB ≈ 4.2 GB,F50 有 256 GB)
· `scripts/backup-task.cmd` 默认参数 --keep 7
· `scripts/backup-bundle.mjs` 的 KEEP 默认值同步为 7
(原先写的是 2,一直被命令行参数掩盖着)
- 远端目录 `/本地/备份` → `/本地/备份/blog-bundle`:
根目录是用户自己在用的(放着 github-zqlit-*、local-repos-* 等手工备份),
实测发现直接放根下的 bundle 已被清掉 —— 改子目录隔离,避免混放与误删
五、新增 `scripts/backup-run.mjs`:备份的推荐入口 + 失败告警
- 读 `.workbuddy-backup/openlist-backup.env`(只补空缺,环境变量优先)
- 跑 backup-bundle.mjs 并实时透传输出,同时留一份日志尾部
- 退出码非 0 → 经 `scripts/send_mail.js` 发告警邮件(附日志尾部与常见原因);
成功默认不发,`--notify-success` 才发
- 退出用 `process.exitCode` 而非 `process.exit()`,避免截断未排干的 stdout
- 发信失败不改判备份退出码 —— 通知不该掩盖真正的故障
- 理由:这是当前**唯一**的异地备份,而「每天自动跑」的任务最典型的失败模式
恰恰是静默的(F50 被带出门、换了网段、OpenList 没起来、口令改过……),
没有告警就要等到真要用备份那天才发现
- `scripts/backup-task.cmd` 改调它
六、文档
- `架构总览.md`
· §1.2 地址地图:备份行改指 F50/OpenList;通知行补「兼做备份失败告警」
· §2 旅程图:双推改单推,并说明备份换了介质
· §5.1 / §5.2 推送与远端:只剩 origin;补「已移除远端」表与恢复命令;
GitHub 退役记录保留并补上「CI 定义也已删除」
· §5.3 由「辅仓选型」改为「异地备份的定案」—— 明确不走 git 远端;
平台对比数据保留备查,并注明 `bin/linux/hugo` 出库不必再做了
· §5.6 补「唯一备份」定位、专属子目录、失败告警、keep 7、SMTP 配置键,
实测数据更新为本次复测值
· §6 待办:#2 定案、#3 不必做、#4 已移除、#8 已更新、#10 定位升级,
新增 #11(F50 目录使用约定)
- `CNB构建落地方案.md` §4.0:双远端改单远端,脚本示例去掉 Gitee 参数
- `README.md`:推送说明改单推;脚本表补 backup-run.mjs
实测(2026-10-06,本轮复测):
bundle 7.4s / AES-256-GCM 加密 1.3s / 上传 19.2s(31.6 MB/s)
/ 读回 sha256 一致 → 端到端 60.6s,退出码 0
告警邮件链路已实测(发出一封「备份成功」验证信)
★ 一处过程记录,供以后避免重复踩坑:
中途我把「本机沙箱里 `env -u ... cmd > file` 会让输出整个消失」
误判成 process.exit 截断 stdout,并据此改了日志实现;
随后用 `env -u FOO echo hi > file`(同样零输出)证伪 ——
那是沙箱文件重定向的伪影,与脚本无关。相关改动已回滚,
只留下本身无害的 process.exitCode 写法。
452 lines
22 KiB
Markdown
452 lines
22 KiB
Markdown
# CNB 构建落地方案:双 CDN 架构不动,砍掉中转链
|
||
|
||
> 状态:2026-10-04 · 待你确认后落地
|
||
> 回答的问题:「CNB 构建的前提下,能不能继续现在的架构(境外 EdgeOne + 境内多吉云 → 又拍云源站)?」
|
||
|
||
---
|
||
|
||
## 一句话结论
|
||
|
||
**能,而且一个字都不用改。** 域名解析、备案、EdgeOne 项目、多吉云配置、又拍云存储全部保持原样。
|
||
CNB 只替换「构建 + 搬运」这一段,顺带砍掉广州中转机上那个每分钟轮询的 `sync.sh`。
|
||
|
||
---
|
||
|
||
## 零、GitHub 依赖审计:全链路零依赖
|
||
|
||
回答「GitHub 账号被标记了,还能连上 CNB 吗」——**能,而且这条链路从头到尾不需要 GitHub。**
|
||
|
||
逐环节核实(来源:腾讯云官方文档「社区版快速入门」「个人中心」、CNB 官方 Wiki):
|
||
|
||
| 环节 | CNB 的做法 | 碰 GitHub 吗 |
|
||
|---|---|---|
|
||
| 注册 / 登录 | **微信扫码**,扫码即自动注册,无邮箱验证、无登录密码 | ❌ |
|
||
| 实名认证 | 微信扫码授权手机号 | ❌ |
|
||
| 建组织 / 仓库 | CNB 内建(无「个人私有仓库」,仓库必须挂在组织下) | ❌ |
|
||
| 导入代码 | 标准 git:`git push --mirror <cnb-url>`,源仓可以是**自建 Gitea** | ❌ |
|
||
| 拉构建依赖 | CNB 自带「国内外依赖源默认加速」(腾讯云 CDN + Docker/NPM/Maven 镜像) | ❌ |
|
||
| hugo 二进制 | **已随仓库携带**(`bin/linux/hugo`),构建时零跨境下载 | ❌ |
|
||
| 部署 | EdgeOne API + 又拍云 upx v0 | ❌ |
|
||
|
||
官方原文:
|
||
|
||
> 云原生构建默认使用微信扫码注册登录,未注册用户在扫码登录后,将自动完成注册。
|
||
> —— 腾讯云文档《社区版快速入门》
|
||
|
||
> 云原生构建为微信扫码登录注册,没有登录密码。
|
||
> —— 腾讯云文档《个人中心》
|
||
|
||
### 唯一会碰到 GitHub 的两个场景,你都不走
|
||
|
||
1. **用 CNB 的「从 GitHub 导入」一键迁移工具** —— 那个需要 `GITHUB_TOKEN`。
|
||
**但你从自建 Gitea 迁,用 `git push --mirror`,不需要它。**
|
||
2. **构建时在线拉 GitHub 资源** —— 这正是**已经提前拆掉**的雷:hugo 二进制改为随仓库携带。
|
||
|
||
### 顺带纠正一个概念
|
||
|
||
**「账号被标记」≠「IP 被墙」。** 标记是账号级限制;匿名 HTTP 访问 github.com 的公开资源不受影响
|
||
(实测国内节点 `curl` hugo release 仍返回 302 正常)。所以即便真要在构建里拉 GitHub,也只是**慢**,不是**不通**。
|
||
|
||
### 你真正要做的三件准备(都与 GitHub 无关)
|
||
|
||
1. 微信扫码注册 CNB
|
||
2. 微信扫码完成**实名认证**(官方说明:未实名用户禁止写行为 —— 创建仓库 / 推送代码)
|
||
3. 先建一个**组织**,仓库建在组织下
|
||
|
||
---
|
||
|
||
## 一、决定性发现:答案你自己早就写在代码里了
|
||
|
||
`deploy.yml` 第 290 行起,那段被 `if: false` 停用的 `Upload to UpYun`,注释原话:
|
||
|
||
```
|
||
│ 2026-10-03 起永久跳过海外直传:本 runner 在境外,对 UpYun v0 接口
|
||
│ 无论 -w 10/--strong 还是 -w 3 均为 70 秒左右 EOF,3 轮重试全败,
|
||
│ 每次部署白耗 5 分钟(2026-10-03 build #25 日志实锤)。
|
||
│ 国内线路由腾讯云广州中转机兜底(1Panel 计划任务「又拍云同步(国内
|
||
│ 中转)」每分钟比对 COS build hash → 下载 355M → upx sync →
|
||
│ 又拍云 purge → 多吉云刷新,实测 5 分钟内完成且它自己会刷 CDN)。
|
||
│ 将来若把 runner 挪到国内,把下面的 if: false 删掉即可恢复。
|
||
```
|
||
|
||
**当初被迫上中转机,唯一的原因是「runner 在境外」。**
|
||
链路是这样被逼出来的:
|
||
|
||
| 环节 | 为什么存在 |
|
||
|---|---|
|
||
| runner 在境外 | Gitea 跑在境外 VPS |
|
||
| 直传又拍云失败 | 境外 → 又拍云 v0 接口,**跨境 + 并发敏感 → 70 秒 EOF,必败** |
|
||
| COS 中转 | 境外的产物,国内机器得有个地方取 |
|
||
| 广州中转机 + sync.sh | 只有它在国内,能直传又拍云 |
|
||
|
||
**CNB 的构建节点就在国内(腾讯云)。** 那句注释的复活条件直接成立 —— 中转机、COS、artifact 传递全都失去了存在理由。
|
||
|
||
---
|
||
|
||
## 二、目标架构
|
||
|
||
```
|
||
写作 / 本地
|
||
│ git push
|
||
▼
|
||
CNB(腾讯云,构建节点在国内 4 核 8 GiB)
|
||
│ 一次构建,三条出口
|
||
├──► 又拍云存储(境内源站) upx sync + upx purge
|
||
│ │ 多吉云回源自动跟随
|
||
│ └──► 多吉云 CDN 刷新(API 精确刷新)
|
||
│
|
||
└──► EdgeOne Pages(境外) npx edgeone pages deploy --area overseas
|
||
```
|
||
|
||
**保留不动**(零改动):
|
||
- 又拍云存储 `imzql`(境内源站)
|
||
- 多吉云 CDN(境内解析,回源又拍云)
|
||
- EdgeOne Pages 项目 `hugo-blog`(境外解析,`--area overseas`)
|
||
- 域名解析、ICP 备案、Ying 主题、content 内容
|
||
|
||
**替换掉**:
|
||
- Gitea Actions `build` job → CNB 流水线
|
||
- act_runner → 不需要
|
||
- COS / Gitea artifact 传递 → 不需要(含那串 v3/v4 坑)
|
||
- 广州中转机 `sync.sh` 轮询 → 不需要
|
||
- `deploy.yml` 里 8 处 `github.server_url` 兼容分支 → 不需要(另写 `.cnb.yml`)
|
||
|
||
---
|
||
|
||
## 三、CNB 能力核对(全部官方文档核实)
|
||
|
||
| 能力 | 值 | 对本项目的意义 |
|
||
|---|---|---|
|
||
| 构建节点 | 默认 8 核 16 GiB(**内存 = CPU 核数 × 2**) | 全面优于广州机 2 核 1.9 G |
|
||
| 免费额度 | **160 核时/月**(0.125 元/核时超出) | 见下方换算 |
|
||
| 构建最大时长 | 20 小时;单任务无输出 10 分钟 / 超 1 小时触发超时(可声明,上限 12 小时) | 传 372MB 绰绰有余 |
|
||
| 自定义环境 | `docker.image` 或 `docker.build`(Dockerfile) | 可固定 hugo 0.128.2 extended |
|
||
| 密钥管理 | 密钥仓库 + `imports` 导入环境变量 | 又拍云/多吉云/EdgeOne 凭据不落仓库 |
|
||
| 定时任务 | 支持 cron,最小间隔 5 分钟,时区 Asia/Shanghai | 可替代每日定时构建 |
|
||
| **出网限制** | **无白名单限制**(官方:出口 IP 动态,明确不建议白名单) | 又拍云 / 多吉云 / EdgeOne API 都可直连 |
|
||
| Docker-in-Docker | 支持(`services: docker`) | 备用 |
|
||
| 官方集成 | 腾讯云官方有 **CNB → EdgeOne** 的部署文档示例(`npx edgeone makers deploy`) | 已验证路径 |
|
||
|
||
### 额度换算(关键决策数字)
|
||
|
||
| 规格 | 内存 | 每次构建耗(按 10 分钟) | 160 核时可用次数 |
|
||
|---|---|---|---|
|
||
| 8 核 | 16 GiB | 1.33 核时 | **120 次/月** |
|
||
| **4 核** | **8 GiB** | **0.67 核时** | **240 次/月** |
|
||
| 2 核 | 4 GiB | 0.33 核时 | 480 次/月 |
|
||
|
||
你的触发频率是「每天 1 次定时 + 每次发文」≈ **60–90 次/月**。
|
||
|
||
**建议用 4 核 8 GiB** —— 240 次/月的余量,即使构建耗时翻倍到 20 分钟也还有 120 次。hugo 构建吃 CPU(4 核够并行编译),`upx sync` 吃网络不吃 CPU。
|
||
|
||
---
|
||
|
||
## 四、落地骨架
|
||
|
||
### 4.0 第一步:仓库迁移与远端配置(CNB 主仓,**无 git 辅仓**)
|
||
|
||
**目标形态**
|
||
|
||
```
|
||
origin → https://cnb.cool/<组织>/<仓库> ← **唯一远端**(fetch + push),CNB 构建由它触发
|
||
```
|
||
|
||
> ⚠️ **2026-10-06 定案:git 远端只留 CNB 一个。**
|
||
>
|
||
> - **GitHub**(原 `gh` remote):账号被平台标记、仓库被按 AUP 清空 → 移除
|
||
> - **Gitee**:单仓 500MB / 单文件 50MB 两道硬门槛过不去(本仓 `bin/linux/hugo` 83.1MB)→ 未采用
|
||
> - **自建 Gitea**:发布链路早已不依赖 → 移除
|
||
>
|
||
> **异地备份改为「整仓加密 bundle → 中兴 F50 上的 OpenList」**,与 git 远端无关。
|
||
> 选型依据见 `架构总览.md` §5.3,实现与恢复流程见 §5.6。
|
||
|
||
`git pushall` 仍保留为别名,但现在等价于 `git push origin main`(只有这一段)。
|
||
|
||
**★ 为什么不用「一个 remote 挂多个 pushurl」**(这条教训仍然有效)
|
||
|
||
早期的 `origin` 就是那种写法(pushurl 同时挂了 GitHub 和自建 Gitea)。但它有个被忽视的缺陷,我做了实测:
|
||
|
||
| 场景 | 结果 |
|
||
|---|---|
|
||
| 两个 pushurl 都可用 | ✅ 两个都收到,一次 push 搞定 |
|
||
| **第一个失败** | ❌ **git 立即中止,第二个根本不会被推** |
|
||
|
||
也就是说:**主仓推失败时,辅仓那份备份也不会更新** —— 备份的意义就没了。
|
||
|
||
所以当时才拆成两个独立 remote,别名里用 `;` 而不是 `&&`,保证互不阻塞。
|
||
现在只有一个远端,这层复杂性自然取消了 —— 但**如果将来要再加辅仓**,
|
||
必须回到「独立 remote + 别名」的写法,**不要**用 pushurl。
|
||
|
||
**脚本**(已就位,可直接用)
|
||
|
||
```bash
|
||
bash scripts/setup-cnb-remotes.sh https://cnb.cool/<组织>/<仓库>
|
||
```
|
||
|
||
它会先把你现有的远端配置(含明文凭据)备份到 `.workbuddy-backup/git-remotes.<时间戳>.txt`,
|
||
再重建 `origin`、把 `pushall` 设为 `git push origin main`,
|
||
并顺手清掉 `gh` / `gitee` / `gitea` 这些已退役的远端 —— 全程可回退。
|
||
|
||
**★ CNB 不支持 SSH(官方明确)**
|
||
|
||
> SSH Not Supported —— 平台不支持 SSH 协议访问。
|
||
> 认证方式:用户名**固定填 `cnb`**,密码填**访问令牌**。
|
||
> —— docs.cnb.cool《Git Address and Authentication Instructions》
|
||
|
||
这跟 GitHub 的 SSH 不同,所以两段要各用各的认证:
|
||
|
||
```bash
|
||
git config --global credential.helper manager # Windows 的 Git Credential Manager
|
||
# 首次 push 时:用户名 cnb,密码 = 访问令牌(个人设置 → 访问令牌 → 勾「代码仓库/读写」)
|
||
```
|
||
|
||
仓库地址直接用仓库页地址即可(`https://cnb.cool/组/仓`),带不带 `.git` 都支持。
|
||
|
||
**建仓顺序不能乱**(官方要求)
|
||
|
||
1. 微信扫码注册 → 2. 微信扫码**实名认证**(未实名禁止建仓/推码)→ 3. 先建**组织**(CNB 无「个人私有仓库」,仓库必须挂在组织下)→ 4. 建仓库 → 5. 跑上面的脚本 + push
|
||
|
||
### ⚠️ 推 CNB 之前必须先知道的敏感文件(已审计)
|
||
|
||
这些文件**当前就被 git 跟踪**,会在首次 push 时连**全部历史**一起进 CNB:
|
||
|
||
| 文件 | 内容 | 状态 |
|
||
|---|---|---|
|
||
| `write-server/nginx/ssl/privkey.pem` | **真实 TLS 私钥**(EC P-256,`BEGIN PRIVATE KEY`),2026-06-22 起在库 | 已跟踪 |
|
||
| `.env` | `SILICONFLOW_API_KEY`、`ZHIPU_API_KEY` | 已跟踪 |
|
||
| `GITEA_SECRETS.md` | Gitea 相关凭据说明 | 已跟踪 |
|
||
| `content/posts/2024/.../setup-secrets.png` | 疑似密钥配置截图 | 已跟踪 |
|
||
|
||
**关于暴露面**:该仓一直是**私有**的(匿名 API 返回 404)。2026-10-06 账号被平台标记后
|
||
仓库更被按 **AUP 合规**清空、本地也移除了 `gh` remote → **这条威胁面已彻底消失**。
|
||
|
||
**但两件事仍建议做掉**:
|
||
|
||
1. **CNB 仓库保持「私有」** —— 这些文件在私有仓里影响可控
|
||
2. **`git rm --cached` 停止继续跟踪**(历史里的删不掉,但至少不再新增):
|
||
```bash
|
||
git rm --cached .env GITEA_SECRETS.md write-server/nginx/ssl/privkey.pem write-server/nginx/ssl/fullchain.pem
|
||
```
|
||
⚠️ 注意:`.gitignore` 里其实**已经有** `.env` / `.env.*` 规则 —— 它们失效的原因不是规则写错,
|
||
而是**忽略规则对「已跟踪」文件无效**,所以必须显式 `git rm --cached`。
|
||
(另:`.gitignore` 里那条 `write\.env` 是写错的 —— gitignore 中 `\` 是转义符,
|
||
它实际匹配文件名 `write.env` 而非 `write/.env`;幸好 `write/.gitignore` 里有 `.env*` 兜住了。)
|
||
|
||
**历史清理(`git filter-repo`)的判断已变**:当初不做的唯一顾虑是「会让备份分叉」——
|
||
2026-10-06 GitHub 那份已消失,**这个顾虑没有了**;且离线 bundle 已加密
|
||
(见 `架构总览.md` §5.6),不受影响。
|
||
所以**现在是彻底抹掉这些文件历史的最佳窗口**。
|
||
代价:全部提交 SHA 改变、自建 Gitea 那份需重推。
|
||
|
||
---
|
||
|
||
### 4.1 `deploy/Dockerfile`(构建环境)
|
||
|
||
CNB 默认镜像不含 hugo / upx,写一个专属镜像固定版本:
|
||
|
||
```dockerfile
|
||
FROM node:22-bookworm-slim
|
||
|
||
# 换国内 apt 源(CNB 只明示加速 Docker/NPM/Maven,apt 默认源在国内节点可能慢)
|
||
RUN set -eux; \
|
||
for f in /etc/apt/sources.list /etc/apt/sources.list.d/debian.sources; do \
|
||
if [ -f "$f" ]; then \
|
||
sed -i -e 's|deb.debian.org|mirrors.aliyun.com|g' \
|
||
-e 's|security.debian.org|mirrors.aliyun.com|g' "$f"; \
|
||
fi; \
|
||
done; \
|
||
apt-get update && apt-get install -y --no-install-recommends \
|
||
ca-certificates curl tar zstd python3 xz-utils git \
|
||
&& rm -rf /var/lib/apt/lists/*
|
||
|
||
# Hugo extended 0.128.2(linux/amd64)——★ 随仓库携带,构建时零跨境下载
|
||
COPY bin/linux/hugo /usr/local/bin/hugo
|
||
RUN chmod +x /usr/local/bin/hugo && hugo version
|
||
|
||
# 又拍云 upx
|
||
RUN set -eux; \
|
||
curl -fsSL -o /tmp/upx.tgz \
|
||
"https://collection.b0.upaiyun.com/softwares/upx/upx_0.4.9_linux_amd64.tar.gz"; \
|
||
tar -xzf /tmp/upx.tgz -C /usr/local/bin upx; \
|
||
chmod +x /usr/local/bin/upx; \
|
||
rm /tmp/upx.tgz
|
||
|
||
# EdgeOne CLI
|
||
RUN npm i -g edgeone@latest
|
||
|
||
CMD ["hugo", "version"]
|
||
```
|
||
|
||
> ✅ 已实测(2026-10-04):
|
||
> 1. **hugo 二进制改为随仓库携带**(`bin/linux/hugo`,84MB,进 git 后仅 24MB)。实测国内节点直连 GitHub 拉这个 release 要 **127 秒**(本机只要 7 秒),而每次构建都要付这个成本 → 自带更稳。
|
||
> 2. 又拍云 `upx` 的下载源是 `collection.b0.upaiyun.com`(国内 CDN),直连稳定,保留在线安装。
|
||
> 3. **架构不能混用**:`E:\Hugo\hugo.exe` 是 `windows/amd64`(本地预览用),CNB 构建节点是 `linux/amd64`(`bin/linux/hugo`),两者互不替代。
|
||
> 4. ~~若以后主仓改选 Gitee(单仓 500MB),这 84MB 会挤占配额~~ —— **2026-10-06 定案:不走任何 git 辅仓**(异地备份改用 OpenList 上的加密 bundle,见 `架构总览.md` §5.6),这条约束自然消失,`bin/linux/hugo` 继续随仓库携带即可。
|
||
> 5. **apt 源改阿里云镜像**:CNB 官方只明示加速「Docker / NPM / Maven 镜像」,Debian 默认 apt 源不在承诺范围内,而构建节点在国内 → 换阿里云兜底,避免构建卡在 `apt-get update`(首轮构建时留意这一步耗时)。
|
||
|
||
### 4.2 `.cnb.yml`(流水线)
|
||
|
||
```yaml
|
||
main:
|
||
push:
|
||
- name: 构建并发布(境内外双线路)
|
||
imports:
|
||
# CNB「密钥仓库」(私有;禁止 clone、只能 Web 编辑),存放 10 项凭据。
|
||
# 已在 .cnb.yml 里填好:zqlit/blog-secrets,本地草稿见 cnb-secrets.yml(已 gitignore)
|
||
- https://cnb.cool/zqlit/blog-secrets/-/blob/main/secrets.yml
|
||
runner:
|
||
cpus: 4 # 4 核 → 8 GiB
|
||
docker:
|
||
build: deploy/Dockerfile
|
||
stages:
|
||
- name: Hugo 构建
|
||
script: |
|
||
set -euo pipefail
|
||
hugo version
|
||
python3 scripts/add_draft_to_hidden.py
|
||
rm -rf public resources/_gen
|
||
hugo --minify --gc
|
||
BUILD_HASH=$(find public -type f -print0 | sort -z | xargs -0 sha256sum | sha256sum | awk '{print $1}')
|
||
echo "$BUILD_HASH" > public/.build_hash
|
||
echo "$BUILD_HASH" > public/build_hash.txt
|
||
echo "$BUILD_HASH" > .build_hash.out
|
||
echo "✅ 构建完成 hash=${BUILD_HASH:0:12} 文件数=$(find public -type f | wc -l)"
|
||
|
||
- name: 同步到又拍云(境内源站)
|
||
script: |
|
||
set -euo pipefail
|
||
upx login "$UPYUN_SERVICE" "$UPYUN_OPERATOR" "$UPYUN_PASSWORD"
|
||
upx sync public/ / -w 5 --delete
|
||
upx put public/.build_hash /__build_hash || true
|
||
echo "✅ 又拍云同步完成"
|
||
|
||
- name: 刷新又拍云 CDN
|
||
script: |
|
||
set -euo pipefail
|
||
# ★ 必须刷固定入口页:只刷首页会让 sitemap.xml / rss.xml /
|
||
# archives.html 一直发 CDN 里的旧副本(2026-10-01 实测复现)
|
||
{ echo "https://usj.cc/";
|
||
for p in sitemap.xml rss.xml archives.html posts.html comment.html links.html; do
|
||
echo "https://usj.cc/$p"
|
||
done
|
||
} > /tmp/purge.txt
|
||
upx purge --list /tmp/purge.txt \
|
||
|| echo "⚠️ purge 失败,降级不影响源站已更新"
|
||
|
||
- name: 刷新多吉云 CDN
|
||
script: |
|
||
set -euo pipefail
|
||
python3 - <<'PY'
|
||
import hmac, hashlib, json, os, urllib.request
|
||
AK, SK = os.environ['DOGE_AK'], os.environ['DOGE_SK']
|
||
SITE = 'https://usj.cc'
|
||
P = '/cdn/refresh/add.json'
|
||
urls = [SITE + '/', SITE + '/sitemap.xml', SITE + '/rss.xml',
|
||
SITE + '/archives.html', SITE + '/posts.html']
|
||
def refresh(rtype, u, label):
|
||
body = json.dumps({'rtype': rtype, 'urls': json.dumps(u)})
|
||
sig = hmac.new(SK.encode(), (P + '\n' + body).encode(), hashlib.sha1).hexdigest()
|
||
req = urllib.request.Request(
|
||
'https://api.dogecloud.com' + P, data=body.encode(),
|
||
headers={'Authorization': 'TOKEN %s:%s' % (AK, sig),
|
||
'Content-Type': 'application/json'}, method='POST')
|
||
with urllib.request.urlopen(req, timeout=30) as r:
|
||
print('%s -> %s' % (label, r.read().decode()[:200]))
|
||
refresh('path', [SITE + '/'], '目录刷新')
|
||
refresh('url', urls, '精确刷新 %d 条' % len(urls))
|
||
PY
|
||
|
||
- name: 部署 EdgeOne(境外线路)
|
||
script: |
|
||
set -euo pipefail
|
||
test -n "$EDGEONE_API_TOKEN" || { echo "缺 EDGEONE_API_TOKEN"; exit 1; }
|
||
npx edgeone pages deploy ./public -n hugo-blog -t "$EDGEONE_API_TOKEN" --area overseas
|
||
|
||
- name: 上报部署状态
|
||
script: |
|
||
set -euo pipefail
|
||
H=$(cat .build_hash.out)
|
||
curl -s --max-time 20 -X POST \
|
||
"https://api.200181.xyz/api/deploy-status?token=${RSS_API_TOKEN}" \
|
||
-H "Content-Type: application/json" \
|
||
-d "{\"hash\":\"$H\",\"phase\":\"built\"}" || true
|
||
curl -s --max-time 20 -X POST \
|
||
"https://api.200181.xyz/api/deploy-notify?token=${RSS_API_TOKEN}" \
|
||
-H "Content-Type: application/json" \
|
||
-d "{\"hash\":\"$H\"}" || true
|
||
```
|
||
|
||
---
|
||
|
||
## 五、两个必须复刻的细节(`sync.sh` 里的血泪)
|
||
|
||
### 5.1 purge 不能只刷首页
|
||
|
||
`sync.sh` 的注释记录了一个实测坑:
|
||
|
||
> 历史写法只有 `upx purge "$SITE/"`,即只刷首页 —— `sitemap.xml` / `rss.xml` /
|
||
> `archives.html` / `posts.html` 这些「老路径」会一直发 CDN 里的旧副本。
|
||
> 2026-10-01 实测复现:中转机产物 sitemap.xml 已含新文章(22812B),
|
||
> CDN 上那份却仍是 7/24 的 22592B;手动 purge 后立刻变新。
|
||
|
||
所以骨架里固定刷「首页 + 6 个入口页」。**进阶做法**(完整复刻 `sync.sh` 的精确刷新):
|
||
把文件清单存到又拍云 `/__manifest.txt`,每次 CNB 拉下来与本次产物比对,得出「变化 URL」精确刷新。
|
||
好处是新增文章时只刷那几页;代价是多维护一个清单文件。**建议先跑固定入口版,观察 1–2 周再决定要不要加。**
|
||
|
||
### 5.2 又拍云并发参数
|
||
|
||
`sync.sh` 用 `-w 10 --strong`。当时失败是因为**跨境**(境外 runner 直传),国内直传理论无此问题。
|
||
但建议首次仍保守用 `-w 5`(去掉 `--strong`,它会把请求量放大),实测稳定后再往上调。
|
||
|
||
---
|
||
|
||
## 六、砍掉清单
|
||
|
||
| 砍掉 | 说明 |
|
||
|---|---|
|
||
| act_runner | 不再需要自建 runner |
|
||
| Gitea artifact 传递链 | 含 `upload-artifact@v3/v4` 那串坑 |
|
||
| 腾讯云 COS | 中转存储不再需要 |
|
||
| 广州中转机 `sync.sh` + 1Panel 定时任务 | **注意:只停任务,机器上还有 mysql/openresty 等 7 个容器** |
|
||
| `deploy.yml` 的 8 处 `github.server_url` 补丁分支 | `.cnb.yml` 重新写 |
|
||
| 两套冗余通知(TG/飞书/邮件三选一) | 独立小优化 |
|
||
|
||
**发布链路:7 环节 → 3 环节**(写作 → CNB 构建 → 双线上线)
|
||
**自维护构建节点:1 台 → 0 台**
|
||
|
||
---
|
||
|
||
## 七、前置动作与待核实项
|
||
|
||
### 必须先确认(按重要性)
|
||
|
||
1. **★ EdgeOne 从国内上传 372MB 的耗时**。现在部署是从境外 runner 上传(同区域快),改到 CNB(国内)后是跨境上传到 EdgeOne 国际站。**这是本方案最大的未知数**,必须实测一次。
|
||
2. **★ CNB 构建节点能否顺畅拉取 `github.com` 的 hugo release**。不行就换国内镜像源,或把 hugo 二进制预置进 CNB 制品库。
|
||
3. **又拍云 v0 接口从 CNB 出口的真实表现**。国内直传预期无碍,但需实测确认(这是整个方案的立论基础,务必第一次就验)。
|
||
4. 主仓放哪:
|
||
- **CNB 当主仓** → 最简,Gitea 可退役,写作后台改 `origin`
|
||
- **Gitea 当主仓 + push mirror 到 CNB** → 写作零改动,代价是多留一台机器
|
||
5. 多吉云刷新配额(`sync.sh` 里有 200 条截断逻辑,CNB 版本固定入口页不触及)。
|
||
|
||
### 建议的验证步骤(不动任何现有东西)
|
||
|
||
1. 建一个 CNB 测试仓库(或就用一个分支),放最小化 `.cnb.yml` + Dockerfile
|
||
2. 跑通「hugo build」→ 确认镜像与构建时长
|
||
3. 单独测「`upx sync` 到一个测试 bucket」→ 确认国内直传可行
|
||
4. 单独测「`edgeone pages deploy` 到测试项目」→ 拿到跨境上传耗时
|
||
5. 四项全绿,才动正式仓库
|
||
|
||
---
|
||
|
||
## 八、与之前几份方案的关系
|
||
|
||
| 方案 | 结论 | 与本方案的关系 |
|
||
|---|---|---|
|
||
| `代码源与构建平台选型.md` | CNB 首选(100GiB 仓库 + 160 核时) | 本方案是它的落地细化 |
|
||
| `Gitee方案评估.md` | 可用,但需瘦身 588MB → 500MB | **用 CNB 就不用瘦身** |
|
||
| `EdgeOne双区域方案评估.md` | 建议 `-a global` 或双项目 | 双区域照旧,只是构建方换成 CNB |
|
||
| `阿里云ESA评估.md` | 2000 文件上限卡死 | 不适用 |
|
||
| `精简方案-只留CF和Hugo.md` | 只留 CF 会丢又拍云+多吉云 | **本方案保留双 CDN,复杂度收益同样大** |
|
||
|
||
**核心区别**:之前几份在讨论「CDN 选谁」;本方案证明**你不需要换 CDN,只需要换掉「构建 + 搬运」那一层**。而这一层恰恰是复杂度的大头。
|