5.6 KiB
OnboardX 双前端域名部署说明
1. 最终访问结构
- 员工入职:https://onboardx.cnzhyx.cn
- 后台管理:https://onboardx-admin.cnzhyx.cn
- 契约锁回调:https://onboardx-api.cnzhyx.cn/api/open/onboarding/qiyuesuo/callback
- 后端仍然只有一套,不需要复制数据库或部署第二套 API。
两个前端是同一份源码的不同构建结果:
- build:admin 生成完整后台,输出到 dist-admin。
- build:public 只生成员工填报、链接失效和 404 页面,输出到 dist-public。
员工域名的容器只转发 /api/open/onboarding/。任何 /api/sys/、/api/biz/ 或其他 API 都会直接返回 404。
2. 本次涉及的配置文件
- Dockerfile.admin:构建、运行完整后台前端。
- Dockerfile.public:构建、运行纯员工入职前端。
- admin.conf:后台前端容器内部 Nginx。
- public.conf:员工前端容器内部 Nginx,并限制公开 API。
- edge-domains.conf.example:服务器最外层三个 HTTPS 域名的参考配置。
- api-public-callback.conf.example:只单独配置 API 回调域名时的精简参考。
3. 上线前准备
3.1 DNS
在域名服务商处确保以下记录都指向同一台服务器公网 IP:
onboardx.cnzhyx.cn
onboardx-admin.cnzhyx.cn
onboardx-api.cnzhyx.cn
3.2 HTTPS 证书
证书必须覆盖新域名 onboardx-admin.cnzhyx.cn。如果已有 *.cnzhyx.cn 通配符证书,可以继续使用。
3.3 后端容器服务名
两个前端容器内部配置默认访问:
http://onboardx-api-svc:5566
因此两个前端容器必须与后端处于同一个 Docker 网络,并且后端在该网络中的名称或别名为 onboardx-api-svc。如果线上服务名不同,只修改 admin.conf 和 public.conf 中的 upstream 地址,不要改公开接口范围。
4. 构建两个前端镜像
在前端项目根目录执行:
docker build -f Dockerfiles/Dockerfile.admin -t onboardx-admin-web:20260915 .
docker build -f Dockerfiles/Dockerfile.public -t onboardx-public-web:20260915 .
VITE_PUBLIC_ONBOARDING_URL 是构建期配置,生产环境已经设置为:
https://onboardx.cnzhyx.cn
以后如果更换员工域名,修改 .env.production 后必须重新构建后台镜像,不能只改 Nginx。
5. 启动两个前端容器
下面仅作为普通 Docker 示例;如果使用宝塔、Portainer、Kubernetes 或云平台,就在对应界面填写相同的镜像、端口和网络关系。
docker run -d --name onboardx-admin-web --restart always --network onboardx-net -p 127.0.0.1:18081:80 onboardx-admin-web:20260915
docker run -d --name onboardx-public-web --restart always --network onboardx-net -p 127.0.0.1:18082:80 onboardx-public-web:20260915
如果现有后端不在 onboardx-net,应让三个容器加入同一个已有网络。不要为了省事把后端所有端口直接暴露到公网。
6. 配置服务器最外层 Nginx
- 复制 edge-domains.conf.example 到服务器 Nginx 的站点配置目录。
- 把证书路径改为服务器上的真实路径。
- 确认端口:
- 18081 是后台前端。
- 18082 是员工前端。
- 15566 是后端映射到服务器本机的端口;如果后端没有映射该端口,应改为实际地址。
- 执行 nginx -t 检查配置。
- 检查通过后执行 nginx -s reload 平滑重载。
服务器最外层 Nginx 只负责域名、HTTPS 和转发。真正的公开 API 白名单在员工前端容器的 public.conf 内再次限制,形成两层保护。
7. 推荐发布顺序
- 先完成 onboardx-admin.cnzhyx.cn 的 DNS 和证书。
- 启动后台前端容器,确认新后台域名登录及业务功能正常。
- 启动员工前端容器,但先不要发送新链接。
- 将原来的 onboardx.cnzhyx.cn 切换到员工前端容器。
- 打开一次员工域名,确认显示“入职链接无效”。
- 从后台复制一条有效链接,用电脑和安卓手机各走一遍。
- 最后确认契约锁回调仍然成功。
员工域名以前部署过后台 PWA。本次公开构建会发布一个自销毁 Service Worker,自动注销旧 PWA 并清理旧缓存。老手机第一次打开时可能自动刷新一次;若仍看到旧页面,关闭该页面后重新打开即可。
8. 安卓下载处理
- 普通桌面和 iOS 浏览器通过不携带后台凭证的文件流下载。
- 安卓及安卓 WebView 直接访问同域公开文件接口,避免 blob: 下载被系统 WebView 拦截。
- 安卓微信如果不支持文件接管,页面会提示用户点击右上角“在浏览器打开”后重新下载。
- 后台 PWA 的 Service Worker 不再拦截 /api/,所以文件接口不会错误回退成 index.html。
9. 上线验收清单
- 访问 https://onboardx.cnzhyx.cn/,只显示“入职链接无效”。
- 访问 /#/onboarding/fill 但不带 Token,自动进入链接无效页。
- 修改 Token 任意一个字符,提示链接不存在或无效。
- 公开域名访问 /api/sys/ 返回 404。
- 公开域名访问 /api/biz/ 返回 404。
- 公开域名不能出现后台登录页、菜单、员工档案或系统管理页面。
- 后台生成的员工链接始终以 https://onboardx.cnzhyx.cn 开头。
- onboardx-admin.cnzhyx.cn 的登录、上传、下载和业务操作正常。
- 安卓 Chrome、安卓微信、桌面浏览器均测试合同下载。
- 契约锁回调地址保持不变且能正常更新签署状态。
10. 回滚原则
后台前端和员工前端可以分别回滚到各自上一个镜像版本。不要把员工域名重新指向完整后台作为临时回滚方案,否则会重新暴露后台入口。若员工端出现故障,应只回滚 onboardx-public-web 镜像。