Files
pikasTech-unidesk/docs/reference/codex-deploy.md
T
2026-05-16 13:56:37 +00:00

4.9 KiB
Raw Blame History

Code Queue Deploy

bun scripts/cli.ts codex deploy <commitId> 是兼容入口。新的正式部署入口是 bun scripts/cli.ts deploy apply --service code-queue;兼容入口会生成一个只包含 Code Queue repo 与 commit 的临时 desired manifest,再调用同一个 deploy reconciler。命令只在主 server 工作区执行;它会立即返回异步 job id,后台 job 通过 backend-core 的 host.ssh dispatch 在 D601 完成实际部署。

Command

bun scripts/cli.ts deploy apply --service code-queue
bun scripts/cli.ts codex deploy <commitId>
bun scripts/cli.ts job status <jobId> --tail-bytes 30000
  • commitId 必须是已经 push 到 remote 的 7-40 位 hex commit SHA。
  • --provider-id D601 是默认值;当前部署路径只支持 D601 active instance。
  • --timeout-ms N 控制后台部署总超时,默认 900000
  • --skip-build 不再支持;target-side Docker build 是强制步骤。

Pipeline

部署 job 的步骤固定为:

  1. 对 Code Queue 部署先确保 PostgreSQL 中存在 unidesk_deploy_ssh_identities(id='github.com'),该记录保存 GitHub deploy SSH identity 的 private key、public key fingerprint 和 github.com known_hosts 行。codex deploy 会用主 server 当前 /root/.ssh/id_ed25519 种子化这条记录,然后通过 backend-core /ws/ssh 交互通道把 identity 流式分发到 D601 WSL /home/ubuntu/.ssh/id_ed25519id_ed25519.pubknown_hosts,并在 D601 侧执行 ssh -T git@github.com 验证;secret 不得写入 host.ssh task payload、deploy 日志、Docker image 或 Kubernetes Secret。
  2. 在 D601 的 deploy cache 中通过本机 provider-gateway WS egress proxy 执行 git fetch remote,并用 git archive <commitId> 导出 tracked files 到一次性 export 目录;不得让 D601 直连 GitHub,也不得临时创建 SSH SOCKS、公网 master proxy 或 backend-core/provider-ingress fallback。
  3. rsync --delete 同步导出的 repo 到 /home/ubuntu/cq-deploy,保留 .state/logs/.git/node_modules/dist/
  4. 在 D601 用目标 Docker daemon 的本地 BuildKit builder 构建 unidesk-code-queue:d601,复用 D601 上已有基础镜像、inline cache 和 Code Queue build-baseprovider-gateway WS egress 是唯一允许的构建代理通道,只作为本次 build 的环境变量与 build-arg 注入,并配合本次 build 的 --network host 让 RUN 阶段访问 D601 宿主 loopback proxy,不能污染 D601 宿主 Docker/HTTP proxy 配置,不能新建 SSH SOCKS、公网 master proxy 或直连 fallback。
  5. docker save 镜像并导入原生 k3s containerddocker save unidesk-code-queue:d601 | sudo ctr --address /run/k3s/containerd/containerd.sock -n k8s.io images import -
  6. kubectl apply -f src/components/microservices/k3sctl-adapter/k3s/code-queue.k8s.yaml,其中包含 Code Queue 和 d601-tcp-egress-gateway
  7. 将解析后的 40 位 remote commit 写入 deployment/code-queueCODE_QUEUE_DEPLOY_COMMIT / CODE_QUEUE_DEPLOY_REQUESTED_COMMIT,并记录到 Deployment annotation。
  8. kubectl -n unidesk rollout restart deployment/d601-tcp-egress-gateway deployment/code-queue 并等待 rollout 完成。
  9. 通过 backend-core 的真实微服务代理读取 Code Queue /health,强制校验 deploy.commit 等于本次解析出的 remote commit;如果健康的是旧服务或旧 Pod,job 必须失败。

Observability

codex deploy 本身不阻塞等待部署结束。返回 JSON 中的 statusCommandtailCommand 是唯一状态入口。后台 job 的 stderr 是 JSONL progress,每个长步骤会记录远端 /tmp/unidesk-deploy-*.log 和 sentinel 文件;失败时 job status 会显示最后日志尾部。

job statussucceeded 时,部署 job 已经完成 live commit 验证。需要人工复核时可用以下命令确认 deploy.commit

bun scripts/cli.ts microservice health code-queue
bun scripts/cli.ts microservice proxy code-queue '/api/tasks/overview?limit=5&transcriptLimit=1&compact=1&afterSeq=0&preferId='

Boundaries

Code Queue 由 D601 k3s/k8s 控制面代管,不再通过 server rebuild 或手工 docker compose up 作为正式部署路径。codex deploy 可以在 Code Queue 自身正在执行任务时运行;服务重启后由 restart-recovery 恢复任务状态,不能等待当前 Code Queue task 退出后再部署。

TCP Egress Gateway

D601 k3s Pod 不能依赖主 server 公开 15432/4255 作为直连 TCP 入口;PostgreSQL 也不会自动使用 HTTP proxy 环境变量。code-queue.k8s.yaml 因此提供一个通用 d601-tcp-egress-gateway

  • Pod 内业务只访问集群内 Service:d601-tcp-egress-gateway.unidesk.svc.cluster.local:15432:4255
  • gateway 通过 D601 provider-gateway egress proxy 的 HTTP CONNECT 转发到底层 TCP 目标。
  • 新增 TCP 依赖时只扩展 TCP_EGRESS_ROUTES,不要在业务容器里散落公网直连地址或 ad hoc 隧道脚本。