Docker 排障：构建、退出、网络与存储 · 升级后数据归零的恢复与复盘

返回分篇目录

升级后数据归零的恢复与复盘

以下演练将Docker 双服务计数项目的变更、失败证据和恢复验收串起来；先熟悉配套示例中的Context、store/gateway、项目名与 counter 卷。演练未执行。

故障场景与影响

重新部署后服务正常启动，但计数或业务数据回到初始值。

先记录首次异常时间、受影响对象和最近变更，区分个别对象失败与整条管理链路异常。以下是排查演练，不是已发生事故的实测记录。

按证据定位原因

1. 保存新旧容器的镜像标识、Compose 项目名和挂载信息，核对应用实际读写的容器路径。
2. 对比卷名、bind mount 的宿主机路径和目标路径；项目名变化可能关联到另一组卷。
3. 区分旧卷仍存在但没有挂载、数据写进容器可写层、卷已被删除三种情况，再核对最近备份。

恢复步骤与验收

暂停写入，保留当前与旧数据副本。确认旧卷完好时按正确映射重新部署；需要恢复备份时写入独立目标并检查一致性，不在未知数据上反复初始化。

验收：检查升级前样本仍可读取，新增数据在容器重建后仍存在，并从备份恢复到独立卷。记录数据格式与镜像版本的兼容关系，不能仅以容器 running 结案。

将触发条件、直接原因、修复动作、恢复证据和后续检查写入同一份复盘，明确每项后续工作的负责人。机制参考：官方说明。

一次发布如何描述

Docker 复盘 模型 应包含构建输入→镜像引用→容器配置→进程→网络/卷→业务结果。仅记下“docker compose up 成功”无法证明就绪、持久性或恢复。把每个箭头写成可检查的问题：构建上下文有什么、digest 是否一致、PID 1 是否接收信号、服务名是否正确、数据写到哪里。

本例可以通过文件阅读确认 gateway 不写 SQLite、健康检查不递增计数、宿主只发布回环、数据只落在 /data；却不能凭阅读确认镜像可拉取、卷驱动权限表现、实际停止时间和端到端请求成功。这些需要读者未来自行运行验证。

场景题：升级后归零

Docker 升级 数据 问题：换了项目目录后计数变为 1，工程师准备重新拉旧镜像。更好的第一步是什么？答案：先核对项目名和卷名。本例显式 name: m5-docker，普通换目录应仍指同一项目；若读者使用 -p 覆盖项目名，就会创建另一个卷。旧镜像不能恢复被删的卷，也不能让新项目自动绑定旧卷。

进一步追问：若项目名未变呢？依次检查 volume 挂载目标、是否曾清理卷、数据文件是否可访问与应用是否改了路径。只有确认旧数据不可用，才转入备份恢复，不要先销毁现有对象。

场景题：健康却报错

Docker 健康 就绪 问题：Compose 在 store healthy 后启动 gateway，为什么一分钟后请求仍可能 503？答案：健康是时间点观测，依赖在之后可能停止、磁盘满或变慢；depends_on 没有把应用变成持续可用系统。gateway 的超时和 503 让故障可见，生产还需重连、容量和告警。不能把“启动顺序正确”写成“以后始终可用”。

场景题：秘密与缓存

问题：使用 secret mount 后是否可以允许任意来源的 Dockerfile？答案：不可以。RUN 指令可以主动发送或复制秘密，挂载机制只是避免常规持久化路径，不隔离恶意构建逻辑。应审阅构建来源、缩短凭据寿命、限制访问范围与出口，并避免把秘密写到构建日志。

问题：替换 token 后构建走了缓存是否异常？答案：秘密内容本身不保证触发缓存失效，需要用非敏感产物版本表达真正的输入变化。

完成标准与下一步

读者应能画出 store/gateway 的地址边界，解释 image 与 container、EXPOSE 与 ports、可写层与 volume、healthy 与业务就绪的差别，并能提出不会毁坏证据的下一步检查。要写“已运行通过”，还必须亲自记录版本、平台、构建引用、请求结果、重建后持久数据与清理行为。

原文审阅取舍见 migration/knowledge-rebuild/m5/orchestration/audit.json：深入手册继续承担查阅，课程承担连续解释；旧部署、公司地址和版本快照已按逐篇审阅结果保留独有参考，或移入编辑归档并保留兼容入口，不当作今天的安装答案；见 migration/knowledge-rebuild/legacy-cleanup/audit.json。