部署指南

最后更新:2026-03-14 · 负责人:DevOps

本文汇总了 Python/FastAPI + React 技术栈当前可用的部署路径,取代此前散落在 docs/dockerdocs/ops 下的说明。后续所有部署变更都应先更新本页,再回填到其他引用位置。

Compose 深入附录

/zh/docker/compose-v2/ 用来承接更底层的容器拓扑细节。本页只保留推荐部署路径,把过细的 实现说明推到附录里。

1. 拓扑矩阵

TargetRecommended StackCompose/K8s entrypointNotes
本地开发 / QADocker Composedocker compose up --build(可选 ./scripts/tests/run_docker_integration.sh使用本地构建和 .env.example 默认值,适合单人贡献流程。
小团队(<15 users)单机 Docker Composedocker compose -f docker-compose.ghcr.yml --env-file .env.prod pull && docker compose -f docker-compose.ghcr.yml --env-file .env.prod up -d拉取 GHCR 中预构建的 backend/celery/frontend 镜像,并配合 Traefik/Caddy 反向代理。
StagingDocker Compose + Playwright smoke与小团队方案相同,并在 CI 中加 pnpm test:e2e-smoke复用生产 secrets,用于 release candidate 验收。
ProductionKubernetes(Kustomize 或 Helm)kubectl apply -k deploy/k8s(manifests 仍在 WIP)将 API + worker pods 分布到多节点,并使用托管 Postgres/Redis。

2. 部署前检查

  1. Secrets 与配置:复制 .env.example.env,生成 32-byte ENCRYPTION_KEY,并设置唯一的 Postgres 凭据。若使用 Compose 部署,可以提交 .env.prod.example 用于复现,但真实 secrets 必须放在 vault 中。
  2. 制品:优先使用 .github/workflows/docker-publish.yml 发布到 GHCR 的镜像;只有在验证尚未发布的本地改动时,才回退到 docker compose -f docker-compose.build.yml build
  3. 数据库:运行 uv run alembic upgrade head(Compose 入口已自动执行),并确认迁移能在目标数据库上成功完成。
  4. 健康检查端点:确保编排平台可以访问 /healthz/metrics。Prometheus 抓取示例见 运维监控

3. 部署配方

3.1 本地与 QA(Docker Compose)

cp .env.example .env
docker compose up --build
  • 会启动 FastAPI(backend)、Celery worker/beat、PostgreSQL、Redis,以及静态前端容器。
  • 若只验证后端:docker compose up backend celery-worker celery-beat postgres redis -d
  • 集成 smoke(与 CI 同拓扑):scripts/tests/run_docker_integration.sh --full-run --fresh
  • 热更新、bind mounts 等额外覆盖项在 docker-compose.override.example.yml
  • 启动后,打开 UI,在 Providers 中添加真实 provider,导入数据集,并在 Settings 中按需调整工作区运行时策略。

3.2 生产 Compose(单机)

  1. 创建 .env.prod,填入强化后的 secrets(例如用 openssl rand -hex 32 生成 ENCRYPTION_KEY,数据库密码也使用随机值)。
  2. 拉取已发布镜像并启动:docker compose -f docker-compose.ghcr.yml --env-file .env.prod pull && docker compose -f docker-compose.ghcr.yml --env-file .env.prod up -d
  3. 前端容器会反向代理 /apibackend:8000;若 TLS 在其他层终止,请设置 BACKEND_ORIGIN,确保 SPA 指向正确主机名。
  4. 夜间备份:docker exec postgres pg_dump -Fc -f /backups/$(date +%F).dump eval752

3.3 Kubernetes(多节点)— WIP

虽然仓库尚未提供官方 manifests,参考拓扑已经确定:

  • 使用你偏好的工具(Helm/Kustomize)部署镜像;各工作负载分别运行在独立 Deployment 中(apicelery-workercelery-beat)。
  • 使用托管 PostgreSQL(RDS、Cloud SQL、Flexible Server)和托管 Redis/KeyDB,以降低持久化运维成本。
  • 通过 SealedSecret / ExternalSecret 接入 vault secrets,并使用带 TLS 的 Ingress 暴露 /api

任务 P3-OPS-004 负责产出并发布官方 manifests;在它完成前,请把 Compose 中的环境变量映射进你自己的集群部署工具。

3.4 云平台基础组件

CloudContainersDatabaseCacheNetworking
AWSECS/Fargate 或 EKSAurora PostgreSQLElastiCache(Redis)ALB + ACM TLS
AzureContainer Apps / AKSAzure Database for PostgreSQLAzure Cache for RedisApplication Gateway
GCPCloud Run / GKECloud SQL for PostgreSQLMemorystoreCloud Load Balancing + Certificate Manager

4. 验证清单

  1. 针对已部署前端运行 pnpm test:e2e-smoke(或完整 pnpm test:e2e)。
  2. 访问 /metrics,确认 Prometheus target 抓取成功且耗时 <10 秒。
  3. 通过 UI 运行一个样例数据集,并确认 Celery 更新能在 5 秒内通过 SSE 到达前端。
  4. 验证备份链路:模拟 docker compose exec postgres pg_isready 失败,并确认告警触发。

5. 故障排查速查表

SymptomLikely CauseFix
password authentication failed for user "eval752"POSTGRES_PASSWORD 与已有 volume 不一致复用旧密码,或 docker compose down -v 后重建 volume。
Frontend 在 /api/* 上出现 404VITE_API_BASE_URL 不匹配或代理配置错误使用正确环境变量重建前端,或修复反向代理对 /api 的转发。
Celery 无法启动redis 服务不健康或凭据错误检查 .env 中的 redis:// 值,并使用正确密码重建容器。
GitHub Pages 上的文档页面无样式,且所有 JS/CSS/图片请求都 404Rspress 的 base / siteUrl 路径大小写与仓库真实名称不一致(例如 /Eval_752//eval_752/docs/rspress.config.ts 与真实仓库名保持一致,最好直接从 GITHUB_REPOSITORY 推导 Pages URL,然后重新构建并部署文档站。
文档部署流水线遗漏配置或资源改动缓存 key 未包含 Rspress 配置、docs 源码或 docs 脚本查看 .github/workflows/deploy-docs.yml,确认缓存 key 哈希覆盖 docs/**scripts/docs/** 以及 docs 的 package.json / lockfile。

6. 相关参考

  • ../docker/compose-v2.md:Compose 布局与入口点深度说明
  • 配置说明:完整环境变量参考,与本页保持同步
  • 安全手册:secrets、TLS 与事件响应加固清单
  • specs/3_tasks.md#PX-GOV-012:跟踪文档统一化工作的任务项