上一篇已经完成第 5 个实验。本篇聚焦“容器日志与调试”，目标不是背下一组命令，而是建立一套能迁移到不同语言、不同 CI 和不同运行环境的判断方法：先分清状态归属，再冻结输入，最后用可重复证据决定是否交付。所有 Python 示例只依赖标准库，可单独保存运行；Docker 命令也不依赖本系列其他文件。
一、痛点：把“容器能跑”改写成可验收问题
围绕容器日志与调试，最常见的误判是把一次成功启动当成完成。启动只证明某个时刻创建了进程，没有回答输入是否可追溯、数据放在哪里、失败会不会扩散以及重建后是否还能恢复。工程验收必须写成可观察事实，例如“用一次故障注入从请求 ID 找到错误、退出码和资源曲线，并能在容器消失后保留证据”。事实包含动作、边界和预期结果，换一台机器仍能执行；“看起来正常”“应该没问题”则不能进入发布记录。
先画四层边界：镜像保存构建产物和默认元数据，容器承载一次运行实例，Docker 运行时装配网络、卷、资源和权限，外部系统负责仓库、密钥、监控与备份。出现问题时先问状态属于哪层，再选择工具。这样做的价值是故障定位可迁移：无论应用是 Python、Go 还是 Java，都不会用重建镜像修复卷权限，也不会用重启容器掩盖仓库身份漂移。
实验输入至少记录 Engine 与 Compose 版本、CPU 架构、基础镜像标签和 digest、构建参数、运行参数及代码提交。标签是可移动指针，digest 才能标识具体内容；环境变量只能记录名称和非敏感值，令牌不得进入文档、镜像历史或控制台。每次实验只改变一个变量，否则即使结果改善，也无法解释因果。
二、原理：用状态、身份和生命周期解释行为
本篇的核心模型是：容器应把事件写到标准输出；关联 ID 串起请求，inspect、events 和 stats 分别回答配置、生命周期与资源问题。它解释了为什么同一份应用代码，在构建、启动、停止、删除和重建时会表现不同。命令只是模型的观测入口；如果不知道要证明什么，inspect 输出再长也只是噪声。
推荐把检查分为三类。身份检查回答“运行的究竟是哪份产物”，应关联提交、digest 和配置指纹；行为检查回答“正常路径和停止路径是否符合契约”，应覆盖健康、请求、信号和退出码；边界检查回答“资源、权限、网络和持久化是否限制在预期范围”。三类证据缺一不可：身份正确但行为错误不能发布，行为正确但身份不可追溯也无法安全回滚。
本篇重点使用 docker logs、events、stats 与 inspect。工具选择必须跟着问题走：配置问题先看声明展开和 inspect，生命周期问题看 events 与退出码，资源问题看 cgroup 和时间序列，网络问题从进程监听、容器 DNS、端口发布逐层向外排查。由内向外能减少猜测，也避免一上来就清缓存、删卷或使用高权限参数。
下面的程序把三项关键假设编码成确定性检查，并生成短指纹。它不访问 Docker，因此任何装有 Python 3.10+ 的机器都能先验证验收逻辑；真实项目只需把列表替换为采集到的事实。
fromdataclassesimportdataclassfromhashlibimportsha256@dataclass(frozen=True)classCheck:name:strexpected:strchecks=[Check("log","json"),Check("request_id","enabled"),Check("probe","/healthz"),]defverify(item:Check)->bool:returnbool(item.name.strip()anditem.expected.strip())passed=0foriteminchecks:ok=verify(item)passed+=int(ok)print(f"{item.name}:{item.expected}[{'ok'ifokelse'fail'}]")fingerprint=sha256("|".join(f"{x.name}={x.expected}"forxinchecks).encode()).hexdigest()[:12]print(f"summary:{passed}/{len(checks)}")print(f"fingerprint:{fingerprint}")运行输出：
log: json [ok] request_id: enabled [ok] probe: /healthz [ok] summary: 3/3 fingerprint: 36440a8c01fa输出中的指纹用于比较实验输入，不是安全签名。真正交付还应保存完整配置、工具版本和镜像 digest，并将证据关联到代码评审或发布记录。关键点是先过滤硬约束，再比较性能或便利性；任何安全、持久化或可恢复性要求失败，都不能靠“总体得分不错”抵消。
三、实现：完成一个独立、可清理的实验
以下脚本来自原主题实验，可在空目录中执行。执行前先阅读涉及的镜像、端口和清理对象；团队环境要给实验资源加唯一项目前缀，避免误操作同名容器。脚本的意义不是复制粘贴，而是示范固定顺序：准备输入、创建资源、观察结果、保存证据，最后只清理本实验明确创建的对象。
set-euproject_dir="$PWD/docker-lab-276"mkdir-p"$project_dir"cd"$project_dir"dockerversion--format'client={{.Client.Version}} server={{.Server.Version}}'dockerinfo--format'driver={{.Driver}} rootless={{.SecurityOptions}}'dockerrun--name"lab-276"--rm\--read-only\--tmpfs/tmp:rw,noexec,nosuid,size=16m\--cap-drop ALL\--security-opt no-new-privileges\--memory128m\--cpus0.50\alpine:3.20sh-c' printf "container=%s\n" "$(hostname)" printf "user=%s\n" "$(id -u)" printf "kernel=%s\n" "$(uname -s)" test -r /etc/alpine-release printf "status=healthy\n" 'dockerimage inspect alpine:3.20\--format'image_id={{.Id}} layers={{len .RootFS.Layers}}'dockerps--filter"name=lab-276"--format'{{.Names}}'printf'lab=276 status=completed\n'运行后不要只截取最后一行。应保存展开后的配置、inspect 摘要、健康状态、业务请求结果、停止耗时和退出码；涉及数据时还要做“写入—删除容器—重建—读取”，涉及发布时则做“按 digest 拉取—校验—切回上一 digest”。这些动作把抽象承诺变成以后能复跑的回归用例。
第二个标准库程序演示统一的证据门禁。四类证据都通过才接受本次实验；实际 CI 可以从 JSON 文件读取检查结果，但判定规则仍应保持简单、明确和确定。
fromdataclassesimportdataclass@dataclass(frozen=True)classEvidence:name:strpassed:booldetail:stritems=[Evidence("配置",True,"输入已冻结"),Evidence("行为",True,"关键路径可重复"),Evidence("边界",True,"失败模式已验证"),Evidence("回退",True,"恢复步骤已演练"),]failed=[itemforiteminitemsifnotitem.passed]foriteminitems:state="PASS"ifitem.passedelse"FAIL"print(f"{state}{item.name}:{item.detail}")print(f"result={'reject'iffailedelse'accept'}")运行输出：
PASS 配置: 输入已冻结 PASS 行为: 关键路径可重复 PASS 边界: 失败模式已验证 PASS 回退: 恢复步骤已演练 result=accept这套门禁可直接迁移：为每个服务维护同样的四类证据，但让 detail 指向真实日志、指标或制品。新增检查时先说明它防止哪种故障，再决定阻断还是告警；否则检查会快速膨胀成无人理解的仪式。
四、踩坑：让失败暴露在发布之前
本主题尤其要防止：进入容器手改文件；无限增长本地日志；只记录异常文本不记录上下文。这些做法短期看似省事，代价却被推迟到重建、扩容或事故时支付。修复原则不是增加无限重试，而是让依赖有明确就绪信号，让写入位置和权限可说明，让版本身份不可变，并为所有外部调用设置超时和有限退避。
调试时禁止进入运行中容器手工修补后宣布恢复，因为修改只存在于该实例，重建即丢失，也没有评审记录。正确做法是先采集现场，再在 Dockerfile、Compose 或配置源中修复，构建新产物并重跑同一验收。临时诊断容器应使用同一网络和受控权限，用完即删，不要把 curl、shell 和管理员工具永久塞进生产镜像。
还要区分“健康”和“就绪”。进程存活不代表迁移完成，下游端口开放不代表查询可成功。健康检查应便宜、稳定且验证关键路径，同时避免把外部系统的短暂波动放大成重启风暴。应用自身仍要处理依赖晚到、连接断开和优雅停止，编排工具不能替业务代码补齐这些语义。
五、验证：留下能够支持发布和回滚的证据
本篇最终验收是：用一次故障注入从请求 ID 找到错误、退出码和资源曲线，并能在容器消失后保留证据。此外还要确认配置展开无警告，进程以预期用户运行，敏感信息未进入日志，停止信号能到达一号进程，资源和网络边界符合声明。失败项要记录实际值、期望值和复现命令，不能只写“失败”。
回滚对象必须是上一份已验收的镜像 digest 与兼容配置，而不是现场重新构建旧提交。若包含数据库变化，采用扩展再收缩：先增加向后兼容结构，再切换应用，观察稳定后才删除旧字段。发布前真的执行一次回退，才能发现旧镜像读取新数据、密钥版本或代理配置不兼容的问题。
把上述实验纳入 CI 后，开发机和生产环境共享验收语义，只替换容量、凭据和网络边界。下一篇会在本篇证据基础上推进到系列第 7 个主题。
参考来源
- Docker Docs：Docker overview
- Docker Docs：Dockerfile reference
- Docker Docs：Compose file reference
- OCI：Open Container Initiative Specifications
👍 觉得有用就点个赞 + 收藏，方便回头查阅；有疑问直接在评论区留言，我看到都会回。
🚀 本文属于《Docker 容器化实战》系列，持续更新，关注不迷路。
📌 文章里的代码都能直接跑。想要可直接 clone 的完整工程 + 配套部署脚本 / 踩坑清单？评论一声或发邮件到cj2664@qq.com，我免费发你。
如果你正好在做类似系统、或有工程化难题想找人做，也欢迎邮件聊一句——我按实际情况评估，能落地的就接单或出方案。评论和邮件都能直接找到我，不用跳别的平台。
