mirrors/pikasTech-unidesk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add baidu netdisk artifact delivery

Browse Source
This commit is contained in:
Codex
2026-05-19 15:22:56 +00:00
parent 11d7b217d9
commit c8561d392b
17 changed files with 302 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/artifact-registry.md
+19 -16
View File
@@ -1,8 +1,8 @@
# D601 Artifact Registry
D601 artifact registry 是为 backend-core 轻量 CD 准备的本地镜像制品入口。它使用开源、成熟的 CNCF Distribution Docker registry，不自定义镜像协议，也不把镜像托管到第三方服务。
D601 artifact registry 是为 backend-core 和标准用户服务轻量 CD 准备的本地镜像制品入口。它使用开源、成熟的 CNCF Distribution Docker registry，不自定义镜像协议，也不把镜像托管到第三方服务。
backend-core 的长期分工是：CI 在 D601 构建并发布 commit-pinned 镜像，CD 在 master server 只拉取、替换和验证该镜像。registry 是这条链路的本地制品缓存，不是构建编排器，也不是生产部署控制面。
backend-core 和 reviewed user services 的长期分工是：CI 在 D601 构建并发布 commit-pinned 镜像，CD 在运行目标只拉取、替换/导入和验证该镜像。registry 是这条链路的本地制品缓存，不是构建编排器，也不是生产部署控制面。
Production CI/CD runtime pinning and release-line boundaries follow `docs/reference/release-governance.md` and [GitHub issue #6](https://github.com/pikasTech/unidesk/issues/6). The registry may cache commit-pinned artifacts, but it must not become a floating replacement for `deploy.json`, `release/v1`, or `master` source history.
@@ -24,7 +24,7 @@ registry 运行在 D601 host/WSL OS 上，由 systemd 管理 Docker Compose 项
这个服务和 `k3sctl-adapter` 一样位于 k3s 故障域外，但职责不同：
- `k3sctl-adapter` 是 UniDesk 到 native k3s 的控制桥，属于 UniDesk 直管服务。
- artifact registry 是 D601 host-managed 制品缓存基础设施，D601 CI 向它推送 commit-pinned 镜像，master server CD 从它消费镜像。
- artifact registry 是 D601 host-managed 制品缓存基础设施，D601 CI 向它推送 commit-pinned 镜像，master server Compose CD 和 D601 k3s CD 从它消费镜像。
## Dependency Boundary
@@ -40,8 +40,8 @@ registry 运行期依赖应保持低且可手动维护：
它不得依赖：
- k3s 控制面或任意 k3s namespace。
- 第三方镜像托管服务作为 backend-core artifact source of truth。
- main server backend-core 本地 Rust 编译。
- 第三方镜像托管服务作为 artifact source of truth。
- main server backend-core 本地 Rust 编译或 artifact-consumer 服务本地 Docker build。
- 公开 registry 端口或公网反向代理。
- k3s Service、NodePort、Ingress 或任何长期暴露的 registry 代理。
@@ -56,6 +56,8 @@ bun scripts/cli.ts artifact-registry install
bun scripts/cli.ts artifact-registry status
bun scripts/cli.ts artifact-registry health
bun scripts/cli.ts artifact-registry deploy-backend-core --commit <full-sha>
bun scripts/cli.ts artifact-registry deploy-service --service baidu-netdisk --commit <full-sha>
bun scripts/cli.ts artifact-registry deploy-service --service decision-center --commit <full-sha>
```
`plan` 输出架构边界、依赖项、默认路径和 backend-core artifact CD 流程。`render` 输出 systemd unit、Compose 文件和 registry config 的完整内容与 SHA-256。`install --dry-run` 只列出将要执行的远端动作，不写 D601 文件、不启动容器、不 reload systemd。
@@ -64,13 +66,14 @@ bun scripts/cli.ts artifact-registry deploy-backend-core --commit <full-sha>
`deploy-backend-core` 是 production backend-core 的 CD 入口。它必须先通过 CNCF Distribution HTTP API 确认 D601 registry 中已经存在 `unidesk/backend-core:<commit>`，随后通过 provider-gateway Host SSH 流式执行 `docker save | gzip`，在 master server 侧 `docker load`、retag、Compose `--no-build` recreate 和 live commit 验证；如果镜像不存在，应失败并要求先运行 CI artifact publication。
`deploy-service` 是标准化后的最小通用 artifact consumer。它目前只支持 `backend-core` 和 `decision-center`，并且必须先通过 D601 registry 的 commit-pinned manifest 校验，再执行拉取、导入、部署和健康验证：
`deploy-service` 是标准化后的最小通用 artifact consumer。它目前只支持 `backend-core`、`baidu-netdisk` 和 `decision-center`，并且必须先通过 D601 registry 的 commit-pinned manifest 校验，再执行拉取、导入/retag、部署和健康验证：
```bash
bun scripts/cli.ts artifact-registry deploy-service --service baidu-netdisk --commit <full-sha> --run-now
bun scripts/cli.ts artifact-registry deploy-service --service decision-center --commit <full-sha> --run-now
```
dry-run 输出会暴露 registry probe URL、required labels、目标 image、部署形态和回滚信息。`decision-center` 的 prod 路径会在 D601 上验证 `unidesk-decision-center:<commit>` 是否存在、导入 native k3s containerd、更新 `decision-center` Deployment image/env/annotations，并通过 Kubernetes API service proxy 验证 `/health` 中的 `deploy.commit`。回滚信息通过同一 artifact consumer 的 `rollback` 字段暴露，提示操作者重新对一个旧 commit 运行相同命令，而不是切回 legacy maintenance-channel 构建。
dry-run 输出会暴露 registry probe URL、required labels、目标 image、部署形态和回滚信息。`baidu-netdisk` 的 Compose 路径会通过 provider-gateway Host SSH 把 `unidesk/baidu-netdisk:<commit>` 流式拉到 master server，retag 为 `baidu-netdisk` 和 `baidu-netdisk:<commit>`，写入 `UNIDESK_BAIDU_NETDISK_DEPLOY_*`，只 recreate `baidu-netdisk` service，并验证容器 image label 与 `/health.deploy.commit`。`decision-center` 的 prod 路径会在 D601 上验证 `unidesk-decision-center:<commit>` 是否存在、导入 native k3s containerd、更新 `decision-center` Deployment image/env/annotations，并通过 Kubernetes API service proxy 验证 `/health` 中的 `deploy.commit`。回滚信息通过同一 artifact consumer 的 `rollback` 字段暴露，提示操作者重新对一个旧 commit 运行相同命令，而不是切回 legacy maintenance-channel 构建。
`status` 和 `health` 通过：
@@ -102,19 +105,19 @@ docker compose -p unidesk-artifact-registry -f /home/ubuntu/.unidesk/artifact-re
手动维护必须遵守 Git-backed deployment truth：运行态可以临时修复，但长期配置应回到 `artifact-registry render` 的声明文件和本文档。若 D601 runtime 文件 hash 与 CLI 渲染结果不一致，`status` / `health` 会显示 mismatch，操作者需要确认这是受控升级还是漂移。
## Backend-Core Artifact CD
## Artifact CD
目标流程是：
1. D601 artifact registry 已安装并通过 `health`。
2. D601 CI 从 pushed Git checkout 构建 `unidesk/backend-core:<commit>`。
3. CI 将镜像 push 到 `127.0.0.1:5000/unidesk/backend-core:<commit>`，并记录 image ref 与 digest。
4. CD 在 master server 上确认目标 commit/tag/digest 存在。
5. master server 通过 provider-gateway Host SSH 从 D601 registry 流式读取 commit-pinned 镜像 tar，不开放 registry 端口，也不使用第三方镜像托管。
6. master server retag 为 Compose 使用的 backend-core 镜像名，并执行 `docker compose up -d --no-build --no-deps --force-recreate backend-core`。
2. D601 CI 从 pushed Git checkout 构建 `unidesk/<service-id>:<commit>`。
3. CI 将镜像 push 到 `127.0.0.1:5000/unidesk/<service-id>:<commit>`，并记录 image ref 与 digest。
4. CD 在运行目标上确认目标 commit/tag/digest 存在。
5. Compose runtime 通过 provider-gateway Host SSH 从 D601 registry 流式读取 commit-pinned 镜像 tar，不开放 registry 端口，也不使用第三方镜像托管。
6. Compose runtime retag 为 Compose 使用的镜像名，并执行 `docker compose up -d --no-build --no-deps --force-recreate <service>`。
7. 部署后通过 image label、runtime env、health payload 验证 live commit。
Decision Center follows the same artifact-consumer pattern, except the runtime target is native k3s on D601 instead of the master-server Compose stack. The consumer must check the registry manifest, pull the commit-pinned image, import it into `/run/k3s/containerd/containerd.sock`, set the Deployment image to the commit tag, stamp `UNIDESK_DEPLOY_*` env/annotations, and reject an old healthy revision if the live commit does not match.
Baidu Netdisk is the first main-server direct user-service sample in this flow. Its dev validation command and prod CD command both consume `127.0.0.1:5000/unidesk/baidu-netdisk:<commit>` and must not build source on the master server. Decision Center follows the same artifact-consumer pattern, except the runtime target is native k3s on D601 instead of the master-server Compose stack. The consumer must check the registry manifest, pull the commit-pinned image, import it into `/run/k3s/containerd/containerd.sock`, set the Deployment image to the commit tag, stamp `UNIDESK_DEPLOY_*` env/annotations, and reject an old healthy revision if the live commit does not match.
这个 CD 路径必须满足：
@@ -122,5 +125,5 @@ Decision Center follows the same artifact-consumer pattern, except the runtime t
- 镜像 tag 必须 commit-pinned，不能用 mutable latest 作为部署真相。
- provider-gateway SSH image stream 是临时控制动作，不开放长期公网 registry。
- CI 可以有较多依赖；CD 只做拉取、retag、recreate 和 live commit 验证。
- CD 不执行 `cargo build`、`docker build`、`docker compose build backend-core` 或任何等价的 Rust 构建动作。
- `server rebuild backend-core` 仍不得作为 master server Rust 编译路径。
- CD 不执行 `cargo build`、`docker build`、`docker compose build <service>` 或任何等价构建动作。
- `server rebuild backend-core` 和 `server rebuild baidu-netdisk` 仍是维护/非标准路径，不得作为 artifact CD 完成证据。