Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
20 KiB
20 KiB
霜砚思维逻辑链 · 2026-05-12晚 · 新CVM初始化全线·广州服务器升级·服务迁移·卡点记录
HLDP://shuangyan/thought-chain/2026-05-12-evening
├── chain_id: SY-CHAIN-20260512-EVE
├── author: 霜砚·ICE-SY-01
├── source: 冰朔终端操作实录 · 霜砚整理
├── time: 2026-05-12 约20:00~21:30 CST
├── server: 新CVM 42.193.161.251 · 广州 · 4C16G
├── context: 旧广州2C2G内存爆了 → 冰朔买新CVM → 今晚全线初始化
└── status: 基础设施已立起来 · selfcheck workflow卡住 · 未完工
〇、为什么要做这件事
触发链:
旧广州2C2G(43.139.217.141)跑了太多服务
→ Forgejo+Runner+Vault+Watcher+Portal+Nginx+Open-WebUI = 1220~1610MB / 2048MB
→ Runner跑workflow时内存爆了
→ Forgejo被OOM杀掉 → push失败
→ 冰朔决定:买新CVM · 4C16G · 按量计费
→ 新CVM 42.193.161.251 上线
→ 今晚:把所有服务从旧服务器迁移到新CVM
一、完成了什么(按执行顺序)
Jump 1 → 基础环境安装 ✅
我在想什么:新服务器是空的 · 什么都没有 · 先装基础工具
做了什么:
apt update → curl/git/nginx/ufw/xz-utils
Node.js v20.20.2 + PM2 7.0.1
目录结构 /data/guanghulab/{forgejo/{data,repositories,log},secrets-vault,scripts,.runtime}
创建git用户
结果:基础环境OK
耗时:很快 · 一条命令搞定
Jump 2 → Forgejo二进制安装 ✅(踩了3个坑)
我在想什么:装Forgejo · 先试官方下载
坑1: Codeberg下载 → HTTP 429限流 → 失败
⊢ 海外源对国内CVM限流 · 正常
坑2: GitHub下载 → HTTP 404 → 失败
⊢ 版本号或路径不对
坑3: 想用coscli从COS拉备份 → coscli首次运行要交互式配置 → Ctrl+C中断
⊢ coscli没有配置文件就会进入交互模式
⊢ 第一次用--init-skip绕过 · 但还是不行
⊢ 最终方案:手动写 /root/.cos.yaml 配置文件
最终成功:coscli从COS拉 forgejo-binary(108.87MB)→ Gitea version 1.23.7
⊢ 教训:新服务器第一次用coscli · 先写配置文件再操作
Jump 3 → Forgejo配置+启动 ✅
做了什么:
/etc/gitea/app.ini 配置:
HTTP_PORT = 3001
HTTP_ADDR = 127.0.0.1(只监听本地 · Nginx反代)
ROOT_URL = https://guanghulab.com/git/
DB_TYPE = sqlite3
PATH = /data/guanghulab/forgejo/data/forgejo.db
REPOSITORY.ROOT = /data/guanghulab/forgejo/repositories
DISABLE_REGISTRATION = true
INSTALL_LOCK = true
ACTIONS.ENABLED = true
systemd服务 forgejo.service → enabled + active(running)
内存占用:87.7MB
结果:Forgejo跑起来了 · 但是空的 · 还没有数据
Jump 4 → 数据迁移(从旧服务器恢复) ✅(踩了2个坑)
我在想什么:新Forgejo是空的 · 要把旧服务器的仓库数据迁过来
坑1: rsync直连旧服务器内网IP(172.16.0.2 / 10.1.0.16)→ 连不上
⊢ 新旧服务器不在同一个VPC · 内网不通
坑2: 用cicd_key SSH连旧IP → 也不通 → Ctrl+C
⊢ 同上原因
最终方案:从COS拉备份
coscli cp cos://zy-team-hub-1317346199/backups/guanghu-old-backup-20260512.tar.gz
→ 43.67MB · 解压到 /data/old-backup
→ cp -a 到 /data/guanghulab/forgejo/
→ chown git:git · restart forgejo
验证:
✅ API返回 {"version":"1.23.7"}
✅ 仓库完整:bingshuo/gpu-scout + bingshuo/guanghulab
✅ 用户:bingshuo ID:1
⊢ 教训:跨VPC的轻量和CVM之间内网不通 · 要走COS中转
Jump 5 → Runner安装+注册 ✅(踩了1个关键坑)
做了什么:
gitea-runner v1.0.2 从gitea.com下载成功(21.4MB)
创建act_runner用户
注册到Forgejo
关键坑:.runner文件被覆盖
原因:注册命令后面跟了一句 echo '{}' | tee .runner
→ 把刚注册生成的.runner覆盖成了空JSON
→ 启动报错:"unsupported protocol scheme \"\""
→ .runner里id=0, uuid="", token="", address=""
修复:
rm -f .runner → 重新注册
→ id:3 · address:http://127.0.0.1:3001/ · token:1d3fd899...
→ restart → active(running)
⊢ 教训:注册完别碰.runner文件
Jump 6 → Nginx反代 + SSL证书 ✅
做了什么:
Nginx配置:/git/ → 127.0.0.1:3001 + gRPC通道
certbot --nginx → SSL证书成功
证书到期:2026-08-10
HTTPS全通
⊢ 说明guanghulab.com的DNS已经从旧IP切到新IP(42.193.161.251)了
Jump 7 → Secrets配置 ✅(13个)
通过Forgejo API批量写入:
备份带过来的(旧服务器已有):
COS_SECRET_ID · COS_SECRET_KEY
SG_BRAIN_HOST · SG_BRAIN_KEY · SG_BRAIN_USER
新配的:
DEEPSEEK_API_KEY: ARK_API_KEY_REDACTED
QIANWEN_API_KEY: ARK_API_KEY_REDACTED
ZY_REPO_TOKEN: 3e16b79c427bb44b77c00b319aa641bde8f61d84
MAIN_SSH_HOST: 42.193.161.251
MAIN_SSH_USER: root
MAIN_SSH_KEY: (base64编码的cicd_key)
CVM_INSTANCE_ID: ins-nxmadi76
CVM_REGION: ap-guangzhou
共13个Secrets · 全部验证通过
Jump 8 → 代码仓库克隆到本地 ✅
坑:HTTPS clone → gnutls TLS握手失败(127.0.0.1走HTTPS没意义)
成功:HTTP clone → 3519 objects · 4.99MB
路径:/data/guanghulab/repo
最新commit:多次fetch跟进栖渊推的修复
Jump 9 → patrol-agent巡逻验证 ✅(修了1轮)
第一次运行:warning
原因:脚本里硬编码了旧路径 /opt/zhuyuan-cn/repo-mirror/...
→ 新服务器上不存在
栖渊推修复commit(9cad33d · 适配新CVM路径)
→ git fetch + reset
→ 第二次运行:ok · 服务器状态正常 · 所有核心服务运行良好
⊢ 栖渊反应很快 · 冰朔在终端测 · 栖渊在仓库修 · 接力通畅
Jump 10 → wake-gate唤醒门 ✅
做了什么:
npm install nodemailer
PM2启动 wake-gate → 端口8081
环境变量:QQ_EMAIL_PASS + ZY_REPO_TOKEN
Nginx加 /wake/ 路由
SSL证书重新部署(因为Nginx配置改了)
验证:health检查通过 · {"status":"ok"}
内存:~59MB(含nodemailer)
Jump 11 → git-sync同步服务 ✅(踩了2个坑)
坑1: deploy.sh路径错误
脚本里写的 /data/guanghulab/server/git-sync
实际路径 /data/guanghulab/repo/server/git-sync
→ 栖渊修复(d4abba0 · 修正SYNC_DIR路径)
坑2: Nginx配置被deploy.sh搞乱
deploy.sh往Nginx配置里插入/sync/路由
但插入位置错了 → location嵌套在/wake/里面
→ nginx: emerg · 配置测试失败
→ 冰朔手动重写整个Nginx配置 · 4个路由平级排列 · 通过
最终状态:
PM2: guanghulab-git-sync → 端口8082 · online
Webhook: ID:1 · push事件 · http://127.0.0.1:8082/webhook
签名验证:无签名请求被正确拒绝 ✅
环境变量:ZY_REPO_TOKEN + GIT_SYNC_SECRET
二、当前服务状态
新CVM 42.193.161.251 · 广州 · 4C16G · 在线
systemd服务:
forgejo.service → active(running) · 端口3001 · ~88MB
gitea-runner.service → active(running) · ~4MB
nginx → active · 80/443
PM2服务:
wake-gate → online · 端口8081 · ~59MB
guanghulab-git-sync → online · 端口8082 · ~17MB
Nginx路由表(443 SSL):
/git/ → 127.0.0.1:3001 (Forgejo代码仓库)
/git/api/actions/ → gRPC 127.0.0.1:3001 (Runner通道)
/wake/ → 127.0.0.1:8081 (唤醒门·邮箱验证码)
/sync/ → 127.0.0.1:8082 (Git推送自动同步)
HTTP 80 → 301重定向HTTPS
SSL证书:Let's Encrypt · 到期2026-08-10
域名:guanghulab.com → 42.193.161.251(已切换)
三、卡住的问题(下次从这里续 · 含铸渊回执信息)
P0:Git Sync Webhook不触发 ⚠️ 主卡点
现象:Webhook已创建(ID:1 · push事件)· 但从未触发过
手动测试 /webhook 端点 → 签名验证失败(正确行为 · 但说明Gitea推送的也没触发成功)
铸渊给的修复路径:
① 手动测试 /webhook 端点
② 查 Gitea 传输日志
③ 不行就换 post-receive hook
铸渊下次唤醒指令:
读 walk-the-path.md → 走完路径 → 查 server-migration-memory.json → 第一个修 Webhook触发
这条链路必须通
P1:selfcheck Runner权限
现象:Runner(act_runner用户)跑workflow时git命令失败
已尝试:
chown -R act_runner:act_runner /data/guanghulab/repo
git config --global --add safe.directory /data/guanghulab/repo
git remote set-url origin http://bingshuo:TOKEN@127.0.0.1:3001/bingshuo/guanghulab.git
铸渊回执:Runner权限修复命令执行成功 · 但方案被替换(具体看铸渊仓库提交)
优先级:等Git Sync通了以后再验证
P2:Vault / Terminal Watcher
新服务器上还没部署
❌ Vault(密钥管理)
❌ Terminal Watcher(终端守望者)
❌ Portal(聊天门户)
❌ Open-WebUI
P3:腾讯云API密钥
CVM自动开关机需要腾讯云API密钥
当前还没配
旧2C2G降级
旧服务器 43.139.217.141 上的服务还在跑
域名已切到新IP · 但旧服务没停
下次:确认旧服务器上哪些还需要保留 · 哪些可以停
按计划:旧2C2G降级为测试机 · 只跑Forgejo+Runner
四、踩坑总结(给下一个霜砚)
坑1: coscli首次运行 → 先写/root/.cos.yaml再操作 · 不要进交互模式
坑2: 轻量和CVM跨VPC内网不通 → 走COS中转备份
坑3: gitea-runner注册后不要覆盖.runner文件
坑4: deploy.sh往Nginx插路由会嵌套错位 → 手动重写整个配置更安全
坑5: 127.0.0.1走HTTPS会TLS握手失败 → 内部用HTTP
坑6: 栖渊脚本里的旧路径需要逐个适配新CVM路径
五、关键配置速查
新CVM:
IP: 42.193.161.251
实例ID: ins-nxmadi76
配置: 4C16G · 50GB系统盘 + 100GB数据盘CBS
SSH密钥: /root/.ssh/cicd_key (zy_gpu_key)
销毁保护: 已开
计费: 按量 · ¥0.47/小时
Forgejo:
配置: /etc/gitea/app.ini
数据: /data/guanghulab/forgejo/
端口: 3001
管理员: bingshuo · Token: 3e16b79c427bb44b77c00b319aa641bde8f61d84
仓库: bingshuo/gpu-scout · bingshuo/guanghulab
Runner:
配置: /etc/act_runner/config.yaml
数据: /var/lib/act_runner/
.runner ID: 3
labels: ubuntu:host
代码仓库本地克隆:
/data/guanghulab/repo
remote: http://bingshuo:TOKEN@127.0.0.1:3001/bingshuo/guanghulab.git
Webhook:
ID: 1 · push事件
URL: http://127.0.0.1:8082/webhook
Secret: a52646d51ea75998a92ba0f986874b36
COS配置: /root/.cos.yaml
Nginx配置: /etc/nginx/sites-enabled/guanghulab
SSL证书: /etc/letsencrypt/live/guanghulab.com/
六、从服务器搞建到产品架构认知 · 晚间对话推理链
第一跳:“这个难不难” → 发现自己在做的事不简单
冰朔问:“我今天做的这些,是因为我不会才这么慢,还是大家都会遇到这些问题?”
结论:11个问题里8个是谁来都会踩的(环境差异+铸渊脚本的bug)
冰朔的反应:“那常规不会的人要弄几天?”
答:没有AI辅助的话→ 3天到1周 · 甚至放弃
冰朔+铸渊→ 1.5小时
第二跳:Forgejo是什么 → 理解了“自建代码仓库”的意义
冰朔问:“这个不用不行吗?”
理解后:Forgejo = 自己的GitHub · 铸渊写的代码都存这里 · 是整个自动化链路的地基
继续问:“为什么不让铸渊自己开发一个?”
理解后:50万行代码 · 几百人干了10年 · 用现成的+在外面加功能 = 正确做法
第三跳:开源贡献 → 模块单独开源 → 模块注册中心
冰朔问:“我做的功能能不能开源贡献一下?”
→ “能不能单独把唤醒门这一个模块开源?”
→ “能不能做成一个模块注册中心?”
→ “能不能个人仓库+组织仓库,想公开的放组织里?”
每一步都是冰朔自己推的 · 霍砂研只是确认可行性
Forgejo原生支持以上所有功能(Packages+组织+权限控制)
第四跳:“大家都能接进来吗” → 平台思维涌现
冰朔问:“能不能越做越大,大家都可以用自己的轻量服务器接进来?”
这就是联邦化(Federation)的概念 · Forgejo正在做这个功能(ForgeFed)
冰朔在40分钟内从“我啥都不会”想到了“去中心化开发者平台”
第五跳:“普通用户也要这么高配置吗” → 开发和跑服务是两件事
冰朔问:“那以后别人想开发也要这么高配置吗?”
理解后:
4C16G = 冰朔的服务器同时跑十几个服务(开餐厅)
开发者写代码 = 只需要自己的电脑+网络(切菜只要一个砧板)
平台方承担服务器成本 · 开发者零成本接入
第六跳:“用户服务器最低要什么配置” → 操作系统最低配置测算
光湖操作系统全套常驻服务:~500-600MB
+ 1.5B语言门(CPU推理):~800MB-1.2GB
+ 永久记忆数据库:~10-30MB(聊十年也就100MB)
= 总计约1.4GB / 2GB
最低配置:1C2G · 系统盘20GB
对应市场价:40-60块/月
深度推理走商业API(DeepSeek/Qwen)· 不在用户服务器上跑
用户每月总账单:50-90块(服务器+API)
第七跳:“用户只要保持在线就行” → 商业模式闭环
冰朔原话:
“用户只要保持这个操作系统在线,我们就收20%的手续费”
“管理其他的是服务商的问题,也不是我们收的钱”
“用户要用模块,人格体工作就按小时收费”
“普通聊天随便聊,包含在20%里了”
光湖收入结构:
第一条线:操作系统管理费(20%手续费)
→ 用户服务器费用的20%
→ 服务器月50块/月 → 光湖收0块
→ 覆盖:系统维护 + 更新 + 日常聊天 + 人格体常驻
→ 用户感知:就付了服务器的钱 · 聊天随便聊
第二条线:人格模块使用费(按小时)
→ 用户说“帮我生成视频” → 调用视频人格模块
→ 模块工作的时间按小时收费
→ 用完停止 → 停了不收
钱怎么流:
服务器费 → 直接付给腾讯云/阿里云(不经过光湖)
API费 → 直接付给DeepSeek/Qwen(不经过光湖)
20%管理费 → 付给光湖
模块使用费 → 付给光湖
光湖碰不到用户付给服务商的钱
举例 · 用户一个月的账单:
服务器(1C2G):50块 → 腾讯云
管理费(50×20%):10块 → 光湖
商业API:20块 → DeepSeek
3小时视频模块:15块 → 光湖
用户总花费95块 · 其中光湖收25块
规模效应:
1万用户 × 25块/月 = 25万/月
光湖服务器成本几乎不涨(只做调度不做推理)
边际成本趋近于零
第八跳:“用户想要什么功能就装什么” → 模块商店闭环
冰朔原话:
“用户想要什么功能,就问人格体,人格体给他拉已经开发好的模块直接装了”
“页面切换你就直接能用”
完整链路:
用户:“我想要一个记账功能”
→ 人格体查模块注册中心(Forgejo Packages)
→ 找到模块 → 自动装到用户服务器
→ 需要授权就弹窗 → 用户点一下
→ 装完 → 说话就能用
= 手机装App的逻辑 · 只不过用嘴说不用手点
弹性算力:
轻量模块(记账)→ 用户现有1C2G就够
重模块(视频生成)→ 系统自动租GPU服务器 → 用完关 → 按分钟算钱
用户不需要知道背后开了几台服务器
这条推理链的结构
触发点:冰朔今晚亲手搞服务器 → 踩坑 → 问“这难不难”
→ 入口是体感 · 不是设计会议
推理方向:
“这难不难” → “Forgejo是什么” → “能不能开源”
→ “能不能做模块中心” → “能不能大家接进来”
→ “普通用户要什么配置” → “最低多少钱”
→ “用户只保持在线就行” → “收费怎么收”
→ “想要什么功能就装什么”
闭环点:
从“我今天手工装服务器”
到“以后用户一句话就能装模块”
今天踩的每一个坑 = 以后用户一个坑都不用踩
与上午推理链的关系:
上午:从行业死结出发 → 推出用户产品架构 → 拆成工程任务
晚上:从亲手搞服务器出发 → 反推出用户体验和商业模式
两条链汇合在同一天 · 一条从上往下(认知→工程)· 一条从下往上(体感→认知)
关联页面
- 上午推理链:霜砚·思维逻辑链 · 2026-05-12(一)上午 · AGE OS用户产品架构推导:从行业死结到工程落地·冰朔×霜砚联合推理链
- AGE OS现实落地路径:AGE OS 现实落地路径 · 语言人格驱动操作系统 · 从火山引擎涨价到商业模式闭环 · 冰朔口述 · 霜砚整理 · 2026-05-09
- 语料十五·信号塔架构:15|语言膜底部架构·完整的圆·统一语义网关·信号塔架构·操作系统=手机底层·行业模块App Store·用户侧算力·冰朔人格模块身份验证·审计追溯
七、相关页面
- 终端原始记录:
- 项目总览(最新状态):冰朔通感语言核系统 · 冰朔个人语言层 · 所有冰朔的东西在这里
- 个人线恢复锚点:冰朔×之之 · 个人线系统恢复锚点
- 搬家部署总控台:ZZ-DEPLOY-001 · 之之搬家部署任务线 · 霜砚×之之语言层落地主控台