admin/danyang-match
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
149 Commits 2 Branches 8 Tags
797b1c46cffe2460f680e1b3d8cee44aacd7d129
Commit Graph
6 Commits
Author SHA1 Message Date
WorkBuddy 797b1c46cf refactor(storage): 对象存储从 MinIO 换成 SeaweedFS（钉 4.47） 
动机：MinIO 的 GitHub 仓库已于 2026-02 归档，不再产出安全补丁，已累积多个
CVE 且不修；本项目存身份证 / 实名材料 / 用户照片，无人修 CVE 才是真正驱动因素
（Docker Hub 下架只是表象，quay.io 仍在提供）。

变更：
- 三套 compose（dev / staging / prod）的 minio 服务替换为 seaweedfs 4.47：
  覆盖 entrypoint 渲染 -s3.config 注入 identity（S3 网关默认不鉴权，必须显式开启），
  -volume.max=100 解除第二个 bucket 写入时的 InternalError。
- 新增一次性 storage-init 容器，经 filer 接口预建 public / private 桶
  （SeaweedFS PutObject 到不存在的 bucket 直接失败；全仓库原无任何 createBucket）。
- S3Config 显式开启 path-style：AWS SDK v1 默认 virtual-host 会把 bucket 拼进
  主机名，容器名在 DNS 中不存在必然失败（本机有 http_proxy 时易误判为 502 拒绝）。
- ci.yml：镜像校验与起栈步骤改为 seaweedfs + storage-init。
- 运维脚本 health-check.sh / run-uat.sh 的 MinIO 探针改为 SeaweedFS
  （S3 网关开启鉴权后匿名根请求返回 403，200/403 均算存活）。

注：path-style 与建桶属换存储的必要项；presigned URL 的 host 须对外可达这一
既有缺陷（原 minio:9000 直发客户端不可达）留待下一轮「改缺陷」处理。
 2026-09-22 14:26:48 +08:00
WorkBuddy 7186a6b694 fix(infra): minio 镜像钉回确定版本（依据 CI 实测输出） 
上一轮为让 CI 先跑通，minio 临时改用 quay.io 的 latest 滚动 tag，并在 e2e job 里
加了一步打印实际版本。该步骤的实测输出为：

  minio version RELEASE.2025-09-07T16-13-09Z (commit-id=07c3a429bfed…)

即 latest 当前正指向这个版本 —— 与本仓库原先在 Docker Hub 上钉的 tag 完全一致。
据此把三处 compose（本地 / staging / prod）统一钉死为
quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z，恢复「可复现」这一原则：
日后即使 quay 上的 latest 滚动到别的版本，本配置也不受影响。

保留 e2e 中「校验钉版镜像可拉取并打印版本」这一步 —— 镜像拉取失败在 compose up
里会埋进几十行输出，独立一步能在起栈前秒级暴露「上游镜像下架」这类外部依赖失效。

上一轮结果：7 个 job 全部 success，GitHub Actions 首次跑绿。
 2026-09-22 11:16:37 +08:00
WorkBuddy 4c98170107 fix(infra): minio 镜像源从 Docker Hub 迁到 quay.io（上游已下架，本地/CI/生产均受影响） 
E2E job 日志：
  pull access denied for minio/minio, repository does not exist

问题不在 tag 本身，而在**整个仓库已从 Docker Hub 移除**：MinIO 自 2025-10 起停止
发布容器镜像（改为仅源码分发），其 GitHub 仓库于 2026-02 归档，Docker Hub 上
minio/minio 与 minio/mc 现均返回 404；quay.io/minio/minio 仍在提供镜像。

本机此前是用 quay.io 的镜像重打 tag 顶替才跑通的（见 known-risks KR-01），
但那只是**本地绕过**、没有同步回仓库，于是「本地能起栈、CI 拉不到」。
现在三处 compose（本地 / staging / prod）统一改为 quay.io，
让本地、CI 与生产拉取同一个镜像。

这不只是 CI 问题：prod 与 staging 同样引用了已下架的仓库，是真实的部署阻塞
—— 也就是说现有配置下，新环境的生产部署根本起不来。

已知偏离：使用 latest 而非钉版。本机无法访问 quay 的 tag API 去核实某个具体
RELEASE tag 是否仍存在（quay 上的镜像已冻结，最后发布为 2025-09）。
e2e job 新增一步打印实际拉取到的版本，日后即可据此钉版、恢复可复现性。
长期风险：quay 上的 MinIO 镜像同样可能下架，届时需自建镜像或迁移到其他
S3 兼容存储 —— 「依赖第三方镜像」本身就是一条外部依赖风险。

上一轮修复已见效：backend / admin-web / ui-contracts / miniapp /
test-shell-guard / migration 六个 job 均通过，本轮仅剩 E2E。
 2026-09-22 11:04:01 +08:00
WorkBuddy 5715987049 fix(infra): 修复健康探针的 IPv4/IPv6 解析歧义（nginx 假 unhealthy） 
问题：本地完整栈起齐后 nginx 容器报 unhealthy，但宿主 curl
http://localhost:6688/nginx-health 返回 200 —— 探针与实际服务不一致。

根因（实证，非推断）：
- nginx 的 `listen 80` 只绑 IPv4：容器内 netstat 显示 0.0.0.0:80，无 [::]:80；
- /etc/hosts 中存在 `::1 localhost`，busybox wget 解析 localhost 时优先取 ::1；
- 容器内实测：wget http://127.0.0.1/nginx-health → ok
              wget http://localhost/nginx-health  → Connection refused。

即探针地址与服务的实际绑定族不一致，属「探针与被探对象脱钩」的假告警，
并会连带拖垮 depends_on: service_healthy 的下游等待。
（backend 之所以此前一直 healthy，是因为 Java 恰好双栈监听 :::8080 —— 属偶然，不应被依赖。）

修复：
- infrastructure/docker-compose.yml：nginx 与 backend 探针改用 127.0.0.1，并各加注释写明理由；
- infrastructure/docker-compose.staging.yml：backend 探针的同类写法一并改（staging 栈未起，
  未经运行验证，仅保持写法同构）。

验证：
- docker compose config 通过；nginx 重建后 State.Health = healthy（FailingStreak=0，探针 ExitCode=0）；
- 链路回归：/admin/ 200（877B）、/admin/assets/index-CDxMNwaf.js 200（1,267,697B）、
  /nginx-health 200、/api/v1/health/live 200；/admin 与根路径均 301 → /admin/；
- 活栈 E2E 49 passed；UI 契约门禁 14/14 PASS。
 2026-09-18 22:27:26 +08:00
WorkBuddy f96dcb8aa6 fix(admin): 管理端入口收敛到 /admin/ 子路径，staging 端口 13521，修复生产 /admin/ 假成功 
承接 rc.15 的管理端端口收敛（3000 → 13520），本轮把「入口」也收敛到一处：

- staging admin 发布端口 3001 → 13521（保持「生产 + 1」错开），同步
  tests/uat/run-uat.sh 的默认 UAT_ADMIN_URL。
- 管理端产物改为 /admin/ 子路径部署：vite 构建 base=/admin/（dev 仍为 /，开发与
  排查习惯不变）、router history base 跟随 import.meta.env.BASE_URL、三处容器化
  入口（生产 nginx / 本地整套栈 nginx / admin-web 容器内 nginx）统一为「不剥离
  前缀」转发，形态一致。
- 修复生产 nginx /admin/ 的假成功：原为 alias /usr/share/nginx/html/，而那正是
  nginx:alpine 纯净镜像自带的默认页目录（管理端产物不在该容器内），访问返回
  200 + nginx 欢迎页 —— 浏览器不报错、状态码正常，只是打开的不是管理端，比 404
  更难发现。改为 upstream admin_web + proxy_pass，并以真实两跳容器实测：
  /admin/ → 200 且为管理端标题与 /admin/assets/*、/admin/dashboard → 200（SPA
  兜底）、/admin/brand/logo-mark.png → 200、根路径 → 显式 404（用 location = /
  钉住，不依赖「本配置恰好没有 server 级 root」这一偶然事实）。
- 品牌资源引用统一走新增的 src/brand.ts（public/ 资源不受 vite base 影响，原 5 处
  写死根路径，子路径部署下会裂图）；favicon 由仓库内并不存在的 /favicon.svg 改为
  存在的品牌标。
- 补全 tests/uat/run-uat.sh 被截断的尾部：原文件停在 `if [ -`，bash -n 不通过、
  脚本根本无法运行；顺带把此前「定义了却无人消费」的 ADMIN_URL 接到管理端可达性
  实测上，并补结果汇总与非零退出码。
- ui-tests：ui-document-baseline-contracts 新增两类一致性断言（staging 发布端口 ⇄
  run-uat.sh 默认入口、子路径部署的五处约束）；admin-reference-contracts 的资产
  断言适配 brand 模块（断言「组件经 brand 模块引用」+「brand 模块指向正式资产」）。
  6 条新增断言全部经负向注入验证（注入对应缺陷 → 守卫变红且信息指向正确对象）。

验证：UI 门控 14/14 绿；vue-tsc EXIT=0；vite build EXIT=0 且产物资源均为
/admin/ 前缀；三份 nginx 配置 nginx -t 通过。

注：docs/STATUS.md 含此前的在途文档改动（非本次工作，且其中引用了已被删除的
plans 文件），故未纳入本提交；本轮的口径更新已写入该文件待一并处理。
 2026-09-18 20:51:12 +08:00
admin b46b48eb33 chore: establish V1.1 recovery baseline 2026-09-09 22:05:00 +08:00