OpenShip v0.4.7 服务器迁移验收清单

目标容器已经运行，但数据库、证书或后台任务还没通过验证。 最快解法：不要把迁移流程完成当成验收通过，切流前逐项留下容器、数据卷、密钥、域名、任务和回滚证据。

谁适合使用这份清单

如果你准备把现有 Docker 应用迁移到新服务器，需要确认每个服务都能重新部署，而不是只看到首页可以打开。 如果你负责生产环境换节点，重点应放在数据边界、证书切换、队列重复消费和旧节点回退，而不是控制台上的绿色状态。 如果团队准备采购持续在线节点，这份清单可以直接作为新环境的交付与验收口径。

提醒： OpenShip 官方 Changelog 显示，v0.4.7 于 2026 年 7 月 28 日发布，并改进了远程 Docker 迁移链路；这说明迁移过程更可靠，但不等于你的业务数据、密钥和后台任务已经通过生产验收。(官方 Changelog)

最后更新于 2026 年 8 月 3 日，数据核实自 OpenShip 官方 Changelog、官方仓库 README 与 Docker 数据卷文档；下次发布新的迁移版本、改变容器接管逻辑，或调整数据卷与证书迁移方式时，应重新复核。

迁移边界与证据包

验收前先建立一份“迁移前快照”，否则迁移失败后你很难判断是新节点的问题，还是源端本来就存在遗漏。至少保存以下内容：

• OpenShip 实际运行版本、控制平面运行方式和目标服务器标识；
• 源端与目标端的主机名、SSH 账户、Docker 版本和部署时间；
• 仓库中的 Compose 定义、环境变量清单、镜像标签与构建参数；
• 迁移前所有服务，包括当前没有容器但生产需要的服务；
• 数据库备份文件、数据卷清单、对象存储清单和恢复入口；
• 当前域名、DNS 记录、证书状态、定时任务和队列消费者；
• 旧节点的启动方式、回退命令和允许继续服务的时间边界。

OpenShip v0.4.7 的迁移逻辑会把 Compose 中未运行的服务纳入迁移计划，并会对 build: 服务重新构建、对 image: 服务重新拉取；因此你不能只拿 docker ps 的结果作为迁移范围。迁移后的服务状态还需要与真实容器匹配，而不是只读取数据库里的旧状态。

建议将证据保存到一个只读目录，例如：

mkdir -p migration-evidence/{source,target,rollback}

docker ps -a > migration-evidence/source/containers.txt
docker images --digests > migration-evidence/source/images.txt
docker volume ls > migration-evidence/source/volumes.txt
docker network ls > migration-evidence/source/networks.txt

对于关键容器，再使用 docker inspect 保存完整配置。该命令可以读取容器、镜像、网络和数据卷等对象的底层信息，适合核对挂载、端口、环境变量和健康状态。(Docker inspect 官方文档)

容器与镜像状态

真实运行状态

迁移完成后，先不要看控制台缓存，直接登录目标服务器检查：

docker ps -a
docker compose ps
docker inspect <container_name>
docker logs --tail=200 <container_name>

每个服务都要留下四类证据：

1. 容器名称或 ID 与 OpenShip 服务记录能够对应；
2. 当前状态为 running，而不是短暂启动后反复退出；
3. 健康检查为 healthy，或者有等价的应用层探针；
4. 端口、网络、挂载路径与源端设计一致。

只看“容器存在”是不够的。一个容器可能处于持续重启、健康检查失败或端口未发布状态，而控制台仍然显示服务已经创建。

受控重新部署

至少选择一个无状态 Web 服务和一个依赖数据库的服务，执行一次受控重新部署：

• build: 服务：确认目标节点可以重新构建，不依赖源服务器上的临时缓存；
• image: 服务：确认目标节点可以拉取准确镜像，不能只依赖本地残留镜像；
• 数据库服务：确认重新部署不会覆盖或初始化已有数据；
• 代理服务：确认重新部署后没有重复容器、重复端口或错误路由。

通过标准是：重新部署完成后，服务数量没有异常增加，原有域名仍指向正确服务，应用日志没有出现连接旧节点、找不到卷或缺少环境变量的错误。

如果控制台显示旧容器已停止，但网站仍然可以访问，先在目标主机执行真实状态检查，再查看 OpenShip 的服务匹配日志。v0.4.7 的 Changelog 特别提到，过去可能出现控制台显示停止、实际容器仍在提供服务的情况；同时，错误启动操作还可能产生重复容器。(OpenShip 版本说明)

数据库与数据卷完整性

数据不丢的判断方式

Docker 数据卷会独立于容器生命周期存在，删除容器并不等于删除命名卷；但这也意味着“卷还在”不等于“应用能正确使用卷”。Docker 官方文档将数据卷备份、恢复和迁移作为独立操作处理，并建议通过归档与恢复验证迁移结果。(Docker 数据卷官方文档)

你需要分别验证：

• 数据库：表结构、关键表记录、最近写入记录、索引或迁移版本；
• 对象存储：文件数量、关键对象、访问权限和签名地址；
• 数据卷：卷名称、挂载目标、属主权限、应用能否读写；
• 缓存与队列：是否允许丢失、是否必须清空、是否会重复消费；
• 上传文件：应用页面能否读取迁移前已经存在的文件。

不要使用“文件夹大小相同”作为唯一标准。文件大小可能因为压缩、临时文件或数据库整理而变化，真正有价值的是业务抽样和恢复结果。

写入、重启与恢复测试

按照下面顺序执行，避免测试本身制造不可控写入：

1. 在新节点访问一个关键业务页面，读取迁移前已经存在的数据；
2. 创建一条可识别的测试记录或上传一个测试文件；
3. 从应用侧读取这条记录，确认数据库连接和权限正常；
4. 重启应用容器，重新读取测试记录；
5. 重启数据库或目标节点，在维护窗口内再次读取；
6. 使用最新备份恢复到隔离实例，执行一次查询和应用连接测试；
7. 删除测试数据，并保存恢复日志、时间戳和操作者记录。

第二张表可直接作为验收记录模板：

配置与外部依赖

迁移中最容易遗漏的不是容器，而是“容器启动后才会用到”的配置。请逐项核对：

• 数据库连接字符串是否指向目标网络中的服务名；
• 加密密钥、会话密钥、Webhook 密钥是否完整；
• 仓库凭据是否已经落在正确环境，而不是只存在你的本地电脑；
• 外部 API 的来源 IP、回调地址和权限范围是否已更新；
• 对象存储、邮件、支付或模型接口是否能从新节点访问；
• 管理后台、数据库端口和 Docker Socket 是否没有意外暴露。

通过标准不是“环境变量数量相同”，而是关键用户路径真的能完成一次完整调用。例如 AI SaaS 需要同时验证登录、提交请求、异步任务执行、结果保存和再次读取；只打开首页只能证明代理层通了。

OpenShip 官方仓库说明，容器化控制平面可能需要访问主机 Docker Socket，因此这类部署应只放在可信主机上；迁移后要重新检查 Socket 权限、管理端口和防火墙规则。(OpenShip 官方仓库)

方案选择对比

域名、证书与长连接

切流前，用测试域名或本地 hosts 将请求指向新节点，依次验证：

• HTTP 是否能正确跳转或返回预期响应；
• HTTPS 证书的域名、链路和有效期是否正确；
• 代理头中的协议、主机名和客户端 IP 是否符合应用预期；
• WebSocket 是否能建立、保持并正常断开；
• 健康检查是否访问真实业务路径，而不是只访问静态首页；
• 证书自动续期所需的域名验证路径是否仍然可达。

OpenShip 官方流程说明，域名路由和 Let’s Encrypt 证书是在应用启动后配置的；因此“容器已经运行”与“域名已经可用”是两个不同验收项。(OpenShip 官方工作流程) Let’s Encrypt 的 HTTP-01 验证要求 ACME 客户端能够通过指定域名访问挑战文件，所以 DNS、入口代理和端口转发必须在证书测试中一起验证。(Let’s Encrypt 验证类型说明)

记录 DNS 切换时间、旧节点继续服务时间和回退截止时间。不要在确认新节点完全可用前关闭旧节点，也不要让新旧节点同时处理同一组定时任务。

后台任务与切流纪律

AI SaaS 经常有网页请求之外的后台组件，例如队列消费者、定时同步、邮件发送、向量索引和账单任务。迁移时应先画出任务清单，标记每个任务属于：

• 可以并行运行；
• 必须单实例运行；
• 可以暂停后补偿；
• 发生重复执行会造成数据或费用问题。

切流前暂停旧节点的定时任务和队列消费者，或者为新节点设置明确的消费者接管时间。切流后观察任务是否被新节点消费，检查失败重试、死信队列和执行日志；如果新旧节点都出现消费者活动，却没有唯一的租约或锁，先暂停其中一侧。

推荐按以下 5 步完成正式切流：

1. 冻结代码、配置和数据库结构变更；
2. 完成新节点的容器、镜像、数据卷和密钥验收；
3. 用测试域名验证 HTTPS、WebSocket 和关键用户路径；
4. 暂停旧节点任务，切换 DNS 或入口路由；
5. 验证登录、核心请求、后台任务、监控告警和回滚入口。

验收记录可以放进 kvmboot 帮助中心，将命令输出、恢复日志和 DNS 时间线集中保存；如果团队需要讨论临时节点的并行验证方式，可通过 kvmboot 联系页面确认交付与运维边界。

回滚证据与关闭条件

只有同时满足以下条件，才适合释放旧服务器：

• 旧节点仍能启动原有容器或恢复原有部署；
• 新节点的数据库写入边界已经记录；
• 备份已经在隔离环境恢复成功；
• DNS、证书和代理切换时间已经留档；
• 队列、定时任务和 WebSocket 没有出现重复处理；
• 你实际验证过从新节点切回旧节点，而不是只保存一个回滚按钮；
• 回滚后关键用户路径仍然可用。

如果新节点已经产生新数据，回滚前必须先决定是双向同步、导出增量，还是接受某个维护窗口内的数据回放。没有数据边界的回滚，表面上是恢复服务，实际上可能覆盖新写入或造成订单、任务和会话状态不一致。

优点与限制

✅ 适合直接迁移的情况：

• 应用镜像和 Compose 定义清晰；
• 数据库有可验证的备份；
• 旧节点可以保留一段时间；
• 队列和定时任务能够暂停或切换；
• 团队有人可以在切流窗口内观察日志。

❌ 不适合直接切换的情况：

• 只有一份未验证的数据库备份；
• 数据卷依赖本地路径，但没有记录挂载关系；
• 证书只存在旧服务器，无法重新签发；
• 新旧节点会同时消费同一队列；
• 业务依赖固定 IP、物理接口或未记录的防火墙白名单；
• 旧服务器必须立即销毁，无法提供回退路径。

与手工复制容器相比，OpenShip v0.4.7 的远程 Docker 迁移改进，主要价值在于减少 SSH 到 Docker 桥接异常、错误状态判断和服务遗漏；但它不能替你确认业务数据是否完整，也不能替你决定后台任务的唯一执行边界。官方能力声明应当作为操作入口，真正的通过结论必须来自你保存的验收证据。

迁移 FAQ

怎样确认 Docker 应用迁移后没有遗漏关键数据？

不要只比较迁移前后的数据卷名称或备份任务状态。你需要完成数据库表数量核对、业务记录抽样、对象存储文件抽样，并执行写入、读取、重启后再次读取；最后还要在隔离环境完成一次备份恢复，才能证明数据链路可用。

控制台显示容器停止，但网站仍能访问时先查什么？

先以目标主机上的真实 Docker 状态为准，使用 docker ps、docker inspect 和日志确认实际承载请求的容器，再检查 OpenShip 的服务匹配记录。不要立即点击启动，否则可能创建重复容器，导致端口、网络或数据卷指向错误。

更换服务器时，域名和 HTTPS 证书应如何安排？

切流前先用测试域名或本地 hosts 指向新节点，分别验证 HTTP、HTTPS、代理头和 WebSocket。确认新节点能完成证书签发或续期所需的域名验证后，再缩短 DNS 缓存时间并记录切换窗口，同时保留旧节点继续服务到业务验证结束。

数据库和持久化卷都复制完后，哪些结果才算通过？

通过标准不是卷已复制或数据库容器已运行，而是应用能读取关键数据、完成一次真实写入，重启后数据仍在，后台任务不会重复消费，且独立备份可以恢复到临时实例。任何一项没有证据，都只能算迁移完成，不能算生产验收通过。

新节点异常时，旧服务器还能不能作为回退入口？

可以，但前提是旧节点没有被提前清理，DNS 或代理切换边界已记录，数据库写入窗口已经明确，而且你实际演练过回滚。若新旧节点同时消费队列或接收定时任务，切回前必须先暂停其中一侧，否则回滚可能带来重复执行和数据覆盖。

如果你当前的服务器无法同时保留旧环境，又不想把生产切换变成一次性赌博，临时租用独立节点完成双轨迁移通常比直接覆盖原机器更稳妥。当前方案的主要问题往往不是 Docker 本身，而是旧节点无法保留、磁盘快照恢复时间不可控，以及切流后没有足够空间做回滚验证；使用 kvmboot 的独立节点，可以先把新环境作为隔离验收目标，完成数据恢复、重启和回切演练后，再决定是否关闭原服务器。你可以先查看 kvmboot 美国东部节点，按迁移窗口评估临时使用，而不是在没有回退证据时直接替换生产节点。