docker inspect 是干什么的
docker inspect 输出容器、镜像、网络与卷的完整状态，格式是结构化数据，因此可以用模板参数只取关心的字段。排查时它给出的都是事实：退出码是多少、是不是被内存限制杀掉、重启了几次、挂了哪些目录、端口实际映射到哪里，比反复重启试错快得多。
基本信息
| 基本语法 | docker inspect [选项] 容器或镜像或网络或卷 |
|---|---|
| 状态字段 | 运行状态、退出码、是否因内存超限被终止、启动与结束时间 |
| 网络字段 | 分配的地址、端口映射、所属网络与网卡的配置 |
| 挂载字段 | 每个挂载的来源、目标路径与读写模式 |
| 配置字段 | 环境变量、重启策略、入口命令、资源限制 |
| 提取方式 | 用 -f 配合模板语法只输出需要的字段，避免翻整段输出 |
典型使用场景
- 查退出原因：确认退出码与是否被内存限制终止，判断是应用错误还是资源不足
- 确认挂载是否正确：核对宿主路径与容器路径，排查配置文件为何没生效
- 核对端口映射：确认宿主端口实际绑定到哪个容器端口、监听在哪个地址
- 核对环境变量：确认时区、连接串等注入项与预期一致
- 查重启策略与次数：判断容器是否在反复重启，以及重启是否会自动拉起
- 核查资源限制：确认内存与 CPU 限制是否设置，以及是否与编排配置一致
- 看时间线：用启动与结束时间把容器行为与其他日志对齐
常用提取字段
| 字段 | 含义 | 判读要点 |
|---|---|---|
| .State.Status | 当前状态 | running、exited、restarting 等 |
| .State.ExitCode | 退出码 | 非零代表异常退出，需结合日志看原因 |
| .State.OOMKilled | 是否内存超限被杀 | 为真时先调内存限制再看应用 |
| .RestartCount | 重启次数 | 持续增长说明进程反复退出 |
| .Mounts | 挂载列表 | 来源与目标写错会导致配置不生效 |
| .NetworkSettings.Ports | 端口映射 | 为空说明没有发布端口 |
| .Config.Env | 环境变量 | 敏感信息也会出现在这里，注意保护输出 |
常用提取命令
常用提取命令
docker inspect -f "{{.State.Status}} exit={{.State.ExitCode}} oom={{.State.OOMKilled}}" myapp
docker inspect -f "{{.RestartCount}}" myapp # 看重启次数
docker inspect -f "{{range .Mounts}}{{.Source}} -> {{.Destination}}{{\"\n\"}}{{end}}" myapp
docker inspect -f "{{json .NetworkSettings.Ports}}" myapp # 端口映射
docker inspect -f "{{json .Config.Env}}" myapp | head -c 400 # 环境变量
# 模板写错时先原样输出一次，照着字段名再写模板排障先从状态字段看事实：退出码、是否内存超限、重启次数这三项能快速把方向分成应用问题与资源问题两类。
镜像的检查结果也能看：能确认入口命令、工作目录、暴露端口与构建时的层信息，用来核对镜像是否符合预期。
输出里包含环境变量，可能带密钥与连接串：截图或粘贴到工单前先过滤，避免把凭据扩散出去。
模板语法写错会直接报错，遇到报错时先不加模板原样输出，找到字段的真实路径再回头写模板。
取字段的常见做法
- 先原样输出一次确认字段路径，再写模板提取所需内容
- 把退出码、是否内存超限、重启次数三项放在一起看
- 核对挂载来源与目标路径，配置不生效常与此有关
- 核对环境变量的注入结果，时区与连接串最常见
- 输出里包含敏感信息，分享给他人前先做过滤
- 把关键字段导出留档，便于与其他实例逐项对比