[!info] related notes

• 所属 MOC: Daily Use MOC, CI/CD MOC
• 项目级总览: DailyUse 项目单机部署实战（Docker + Caddy + Nginx + PowerSync）
• 前置概念: ACR（容器镜像服务）
• 相关实践: dailyuse-docker-image-build, dailyuse-docker-image-push, dailyuse-docker-image-pull
• 相关部署: deploy-postgresql-on-vm

DailyUse的api端部署

docker 部署（基于镜像仓库部署）

核心思想是：在本地或 CI/CD 流水线中把镜像构建好，推送到仓库，服务器只负责拉取和运行。

服务器上只需要放以下文件：

1. docker-compose.prod.yml
2. .env.production.local（或实际使用的 env 文件）
3. Caddyfile
4. 离线镜像 tar（如果这次部署不走纯在线拉取）

补充一点：

• 当前项目里 web 的 nginx.conf 已经打进 dailyuse-web 镜像，不是线上再额外挂载一份配置。
• 如果你要看整套生产结构，而不是只看 API 镜像部署，请直接看 DailyUse 项目单机部署实战（Docker + Caddy + Nginx + PowerSync）。

流程：

1. 本地/CI环境：运行 docker build 构建镜像 - dailyuse-docker-image-build。
2. 推送：将镜像推送到 Docker Hub、阿里云容器镜像服务或 GitHub Container Registry - dailyuse-docker-image-push。
3. 服务器：运行 docker-compose pull 拉取镜像，然后 up -d 启动 - dailyuse-docker-image-pull。

优点：

• 安全：服务器上没有源代码，避免代码泄露。
• 快速：服务器不需要消耗 CPU/内存去进行 npm install 或编译，启动极快。
• 环境一致：保证了测试环境和生产环境运行的是完全同一个二进制镜像。

现状补充

当前项目已经把业务镜像仓库切到 ACR（容器镜像服务），这解决的是：

• dailyuse-api
• dailyuse-web
• dailyuse-ai-service

这三类业务镜像的发布与拉取稳定性问题。

但这不等于部署过程里“再也不会下载任何镜像”，因为生产编排里还有：

• pgvector/pgvector
• redis
• caddy
• containrrr/watchtower
• journeyapps-powersync-service

这些基础设施镜像仍然可能受 Docker Hub 网络影响。
所以当前更符合实际的经验总结是：

业务镜像优先走 ACR，基础设施镜像必要时走离线导入。