docker inspect 是什么
docker inspect 输出容器、镜像、网络、卷等对象的完整元数据，格式是 JSON。它同时包含创建时的静态配置与运行时的实时状态：启动命令、环境变量、挂载、网络地址、退出码、重启次数、内存上限都能在这里读到，是排障与自动化取值的主力命令。
基本信息
| 语法 | docker inspect [选项] NAME|ID [NAME|ID...] |
|---|---|
| 类型限定 | --type container|image|network|volume，对象重名时用来消除歧义 |
| 模板取值 | -f 或 --format 用 Go 模板抽取字段，免去翻整段 JSON |
| 附加信息 | -s 附带文件系统相关的大小统计 |
| 输出结构 | 单个对象输出数组，多个对象输出数组的多元素 |
典型使用场景
- 故障定位：查退出码、是否被内存超限杀死、重启次数，判断崩溃性质
- 核对运行配置：确认实际挂载了哪些目录、注入了哪些环境变量、接了哪个网络
- 自动化取值：在脚本里抽出容器地址或状态，做健康判断与流量切换
- 核对镜像元数据：看镜像的架构、入口点、暴露端口与层摘要
- 排查网络问题：读容器的网络设置、地址与网关，判断是解析问题还是路由问题
常用示例
常用示例
docker inspect web # 完整输出，内容较长
docker inspect -f '{{.State.Status}} {{.State.ExitCode}}' web # 只看状态与退出码
docker inspect -f '{{.State.OOMKilled}} {{.RestartCount}}' web # 是否被超限杀死
docker inspect -f '{{json .Config.Env}}' web # 只取环境变量
docker inspect --type image nginx:1.27-alpine | head -30 # 看镜像元数据头部关键字段逐项读法
| 字段 | 含义 | 怎么用 |
|---|---|---|
| State.Status | 当前状态：运行中 / 已退出 / 已创建 / 已暂停 | 与列表命令对照，确认容器真实状态 |
| State.ExitCode | 主进程退出码 | 非零说明异常退出，按应用语义解读 |
| State.OOMKilled | 是否因内存超限被杀死 | 为真时要调内存上限或找内存泄漏 |
| RestartCount | 累计自动重启次数 | 数值持续增长说明存在崩溃循环 |
| Config.Env | 注入容器的环境变量 | 核对配置是否生效，注意里面可能含敏感值 |
| Mounts | 已生效的挂载点 | 确认数据目录是卷还是宿主目录绑定 |
| NetworkSettings.Networks | 容器接入的网络与地址 | 判断容器之间能否直接互访 |
| HostConfig.RestartPolicy | 重启策略与最大重试次数 | 确认生产容器是否配了自动拉起 |
把结果用起来
- 先小范围试一次模板字段，确认存在再固化进脚本，跨版本升级时字段位置可能变化
- 对象名可能同时命中容器与镜像，脚本里显式写出类型限定更安全
- 需要多字段时一次取多个模板表达式，减少反复调用
- 输出内容可能包含环境变量与内部地址，贴到工单前先过滤敏感项
容器、镜像、卷、网络都支持 inspect，字段结构各不相同；不确定字段名时先不带模板输出一次，看清结构再写模板。
镜像的仓库摘要只有在镜像来自远端仓库后才会出现，本地直接构建的镜像通常为空，需要先推送或拉取一次才能按摘要引用。
排查时的取值顺序
- 先看状态与退出码，判断容器是运行中、正常结束还是异常退出，这决定后面往哪个方向查
- 再看是否被内存超限杀死与重启次数，崩溃循环与资源不足的处理方式完全不同
- 接着核对挂载与环境变量，配置没有按预期注入是服务起不来的常见原因
- 然后看网络与地址，确认容器接在哪个网络、能否解析到依赖服务
- 最后看健康检查与启动时间，长时间未就绪往往指向依赖阻塞而不是镜像问题