很多团队的大模型应用是先在一台本地机器上跑起来的：Docker 一起，能演示、能给内部用，但机器性能、网络、备份都不达标。等到要正式对外服务，就得整站搬到独立服务器。麻烦在于这套东西不是「重装一遍」就行——历史会话、知识库向量、加密密钥、插件凭据都长在数据卷和配置里，搬错一样，表现是「页面能打开，但历史记录打不开、知识库变空」。
这个项目要搬的是 3 个应用、9 个知识库、84 份文档、全部历史会话与 5 个插件，业务不能停，且必须能随时退回旧环境。验收标准因此定为两条：迁移后数据条数逐项一致，端到端问答效果不变。
一是整站打包：生成 MANIFEST 与每个文件的 sha256 指纹，包传到目标机后可校验完整性。二是目标机预检 8 项：系统版本、资源、Docker、端口占用、防火墙、外网连通、包完整性、时区。三是数据卷修权：按镜像实际运行的 uid 修正属主，避免容器起来后写不进数据。四是密钥迁移：把加密密钥写回配置，否则历史凭据全部解不开。五是服务拉起与验收：14 个镜像、17 个容器，执行五层验收脚本——容器状态、接口健康、数据条数、向量与插件、端到端问答。六是回滚方案：旧环境原封不动保留，出问题可在十分钟内切回。
我负责打包、预检、迁移实施、验收脚本编写和运维手册，客户提供目标服务器与账号权限。技术栈是 Docker、Docker Compose、Dify、Linux，数据落在 PostgreSQL 与 Redis 卷上。难点有三个，都是实际踩到的：一是 Windows 上打的包没有 UNIX 属主，容器起来后写卷失败，需要按镜像运行 uid 重建属主（api 1001、postgres 70、redis 999）；二是密钥不迁移，页面能开但历史凭据全解不开，这一步最容易漏；三是虚拟机 NAT 的端口映射要在宿主机侧配置，容器内怎么看都是通的。这三个坑和 12 条故障速查都写进了运维手册，交付时一并给出。
评论