[JunieXD]

关联

路线图 #2：一期做完先部署内测。

改了什么

照鼠洞的做法部署（鼠洞 docs/design.md §12）：在 main 上打版本标签时，GitHub Actions 构建镜像推到 GHCR，两台机器只拉镜像、用 compose 跑。

• 网站：
  • web/Dockerfile：多阶段构建，以 node 用户运行，带健康检查。V8 堆 256MB，因为抓取节点一次最多交 50MB 的文件。
  • web/deploy/：服务器上用的 compose，只监听 127.0.0.1:3280，根文件系统只读，内存上限 512MB；1Panel 反代用的 OpenResty 配置，请求体上限 50MB；Gatus 的两条检查。
• 抓取节点：crawler/deploy/compose.yml。
  • 挂卷存读过的图片；
  • 停止时等进行中的几轮做完，最多 10 分钟；
  • 给 Chromium 256MB 共享内存，Docker 默认只有 64MB；
  • 根文件系统只读，内存上限 2GB。
• 发布：.github/workflows/release.yml，打 v* 标签时并行构建 mouseclock-web 和 mouseclock-crawler 两个镜像。
• 总体设计 §16 写上镜像、目录、端口、数据库、反代、发布、备份、日志和监控。

怎么验证的

• 本机建了两个镜像，照 compose 里的限制跑（只读根目录、去掉所有权限）：
  • 网站：迁移执行了，/healthz 返回 ok，首页和压缩过的静态文件正常，内存约 60MB。
  • 抓取节点：入口能导入，卷能写、换一个容器读得回来，Chromium 能同时开两个页面。
• 两份 compose 都过了 docker compose config；网站 prettier --check 通过。
• release 工作流要打了标签才会跑，这次没跑。镜像架构是 linux/amd64，本机建的是 arm64。
• 另请 Codex 对照鼠洞的部署文件审过，没有确定的问题。它提醒了两点：
  • 香港那台 root 的 Docker 配置里有一个拉不了公开包的 ghcr.io 登录，要和鼠洞一样用空的 DOCKER_CONFIG 拉镜像，已写进 §16。
  • 几个来源同时上传大附件时，网站 512MB 的上限可能不够。附件一般只有几 MB，先按这个上线，看实际占用再调。

影响

• 只加了部署用的文件和一个发布工作流，代码没改。发布工作流只在打标签时跑。
• 两个 GHCR 包第一次推上去后要设为公开，机器才能匿名拉。