2.0 KiB
部署
生产基线
- 运行拓扑:
Caddy + Docker Compose - 目标主机:
root@cn-console.svc.plus - 域名:
cn-console.svc.pluscn-console.onwalk.net
- 前端独立发布流水线:
.github/workflows/service_release_frontend-deploy.yml
运行方式
前端镜像在 GitHub Actions 中完成构建并推送到镜像仓库,目标主机只负责拉取镜像和启动容器,不在机器上本地构建。
yarn prebuild 现在只生成 console 自己的营销内容工件。/docs 与 /blogs 不再把 knowledge/ 或 Markdown 文档打进前端镜像,而是在请求时通过服务端 docsServiceClient 从 docs.svc.plus 拉取渲染后的内容。
当前方案尽量以静态模式运行:
- Caddy 直接服务
/_next/static/*与public/里的静态资源,并配合frontend_static共享卷。 - Next.js standalone 容器只承接动态页面、认证接口和代理接口,
frontend-assets任务会把所有静态文件(包括哈希后的 CSS/JS)拷贝到frontend_static。 docs.svc.plus是 docs/blog 的运行时内容源,浏览器不会直接访问它。
发布由 .github/workflows/service_release_frontend-deploy.yml 驱动,CI 构建/推送镜像、渲染包含 DOCS_SERVICE_URL / DOCS_SERVICE_INTERNAL_URL 的 .env.runtime,然后将 docker-compose.yml、Caddyfile 与运行时环境文件发送到主机。随后控制平面工作流 .github/workflows/service_release_apiserver-deploy.yml 通过 scripts/github-actions/update-release-dns.sh 更新 Cloudflare DNS,使 cn-console.svc.plus 与别名 cn-console.onwalk.net 指向更新后的环境。
这是针对弱 IO 单机主机 root@cn-console.svc.plus 的部署权衡:主机不会在本地构建镜像,只需登录 GHCR、拉取 dashboard 镜像、解包静态资源到 frontend_static,再通过 docker compose 启动 dashboard 与 caddy。
docs.svc.plus 已经是前端 docs/blog 内容的独立服务。
相关文档
usage/deployment.mdgovernance/release-process.mddevelopment/dev-setup.md