docker 容器文件 hostconfig.json 和 config.v2.json 的区别

在 Docker 的底层存储结构（通常位于/var/lib/docker/containers/<container_id>/）中，hostconfig.json和config.v2.json是两个最核心的元数据文件。

它们共同定义了一个容器的完整状态，但分工明确：一个管“内部逻辑”，一个管“外部资源”。

以下是两者的详细对比与深度解析：

1. 核心区别概览

2. 详细字段对比

📄 config.v2.json：容器的“灵魂”

这个文件定义了容器作为一个软件实体的特征。它很大程度上继承自镜像的配置，并叠加了用户启动时的应用层指令。

• 关键内容：
  • 执行命令：Cmd(命令),Entrypoint(入口点),ArgsEscaped。
  • 环境信息：Env(环境变量数组),Labels(标签)。
  • 工作目录：WorkingDir。
  • 用户身份：User(如root,1000:1000)。
  • 暴露端口：ExposedPorts(仅声明意图，如{"80/tcp":{}}，不包含映射关系)。
  • 卷声明：Volumes(仅声明需要卷的位置，如{"/data":{}}，不包含具体挂载路径)。
  • 健康检查：Healthcheck(测试命令、间隔时间等)。
  • 停止信号：StopSignal(默认SIGTERM)。
  • 镜像引用：Image(使用的镜像 ID 或名称)。

比喻：config.v2.json就像是一份食谱。它规定了这道菜（容器）需要什么原料（环境变量）、怎么做（CMD/Entrypoint）、谁来吃（User）。

📄 hostconfig.json：容器的“躯壳”

这个文件定义了容器作为操作系统进程的特征。它描述了容器如何占用宿主机的物理或逻辑资源。

• 关键内容：
  • 资源限制 (Cgroups)：Memory(内存上限),CpuShares/NanoCpus(CPU配额),BlkioWeight(IO权重),PidsLimit(进程数限制)。
  • 存储挂载：Binds(具体的-v映射，如/host/path:/container/path),Mounts。
  • 网络配置：NetworkMode(bridge/host/none),PortBindings(具体的-p映射，如8080:80),Dns。
  • 安全与权限：Privileged(特权模式),CapAdd/CapDrop(Linux capabilities),SecurityOpt(SELinux/AppArmor),ReadonlyRootfs。
  • 设备映射：Devices(直通硬件设备，如 GPU、串口)。
  • 重启策略：RestartPolicy(always/on-failure)。
  • 日志驱动：LogConfig(json-file/syslog 及其参数)。

比喻：hostconfig.json就像是厨房的环境规定。它规定了这道菜能在多大的灶台做（CPU/内存）、用什么锅（存储挂载）、是否允许明火（特权模式）、做完后盘子放哪（日志/重启）。

3. 生成与修改机制的区别

生成阶段

• config.v2.json：
  1. Docker Daemon 读取镜像的manifest和config。
  2. 合并docker run中指定的应用层参数（如-e ENV=VAL,-w /app）。
  3. 生成最终的 JSON 并持久化。
• hostconfig.json：
  1. Docker Daemon 接收docker run中的资源参数（如-m 512m,-v /data:/data）。
  2. 应用全局默认值（如默认的日志驱动、默认的 ulimit）。
  3. 生成 JSON 并持久化。

修改阶段 (关键差异)

• config.v2.json：
  • 静态：一旦容器创建，此文件极少改变。
  • 无法动态更新：你不能通过docker update修改环境变量、CMD 或 Entry point。要修改这些，必须重建容器(docker rm->docker run)。
• hostconfig.json：
  • 半动态：支持通过docker update命令修改部分字段。
  • 可更新字段：内存限制 (Memory)、CPU 份额 (CpuShares)、重启策略 (RestartPolicy)、日志驱动配置等。
  • 不可更新字段：端口映射 (PortBindings)、卷挂载 (Binds)、网络模式 (NetworkMode)、特权模式 (Privileged)。修改这些仍需重建容器。
  • 机制：当执行docker update时，Daemon 会先修改内核 Cgroups 设置，然后重写hostconfig.json以保存新状态。

4. 实际场景举例

假设你运行以下命令：

dockerrun-d\--namemy_web\-eAPP_ENV=prod\-m512m\-p8080:80\-v/my/data:/usr/share/nginx/html\--restartalways\nginx:latest

在config.v2.json中你会看到：

{"Env":["APP_ENV=prod","PATH=/usr/local/sbin:..."],"Cmd":["nginx","-g","daemon off;"],"Image":"sha256:...","ExposedPorts":{"80/tcp":{}},"Labels":{}}

注意：这里只有APP_ENV，没有内存限制；只有80/tcp的声明，没有8080的映射。

在hostconfig.json中你会看到：

{"Memory":536870912,// 512MB in bytes"RestartPolicy":{"Name":"always"},"PortBindings":{"80/tcp":[{"HostIp":"","HostPort":"8080"}]},"Binds":["/my/data:/usr/share/nginx/html:rw"],"NetworkMode":"bridge","Privileged":false}

注意：这里包含了具体的资源限制、端口映射规则和挂载路径。

5、docker inspect container_id与两个文件的关系

docker inspect的输出内容基本上就是config.v2.json和hostconfig.json这两个文件的合并、格式化及少量加工后的结果。

你可以将docker inspect <container_id>理解为 Docker Daemon 从磁盘读取这两个文件，加载到内存中，然后以标准的 JSON 格式返回给客户端。

以下是详细的映射关系以及**哪些内容在docker inspect中看不到（或表现形式不同）**的详细说明。

5.1、 映射关系对照表

✅ 可以直接看到的对应关系示例

假设你在hostconfig.json中有：

{"Memory":536870912,"Binds":["/data:/app/data:rw"]}

在docker inspect中你会看到：

"HostConfig":{"Memory":536870912,...},"Mounts":[{"Type":"bind","Source":"/data","Destination":"/app/data","Mode":"rw",...}]

假设你在config.v2.json中有：

{"Env":["PATH=/usr/local/sbin:..."],"Cmd":["nginx"]}

在docker inspect中你会看到：

"Config":{"Env":["PATH=/usr/local/sbin:..."],"Cmd":["nginx"],...}

5.2. 哪些内容在docker inspect中“看不到”或“不一样”？

虽然docker inspect涵盖了绝大多数配置，但以下内容不会直接以原始文件的形式出现，或者完全不可见：

❌ A. 内部运行时状态与临时数据

docker inspect展示的是配置（Configuration）和当前状态快照（State Snapshot），而不是所有底层细节。

1. 进程的具体 PID 树：
   • inspect只显示容器主进程的 PID (State.Pid)。
   • 它不显示容器内所有子进程的列表。你需要用docker top或进入容器查看。
2. 实时的网络流量统计：
   • inspect显示网络配置（IP、网关），但不显示实时的 RX/TX 字节数。你需要用docker stats。
3. 文件系统的实时差异层（Diff）：
   • inspect不显示容器可写层中具体哪些文件被修改、删除或新增。你需要用docker diff <container>。
4. 日志内容：
   • inspect只显示日志驱动的配置（如LogConfig），绝不包含容器的标准输出（stdout/stderr）日志内容。你需要用docker logs。

❌ B. 某些底层驱动特定的元数据

1. OverlayFS 的具体层级 ID：
   • 虽然inspect的GraphDriver字段会显示LowerDir,UpperDir,WorkDir的路径，但它不会展示这些目录下具体的文件结构或 inode 信息。
2. Checkpoint 数据：
   • 如果使用了 CRIU 进行容器检查点（Checkpoint/Restore），相关的内存快照文件不会在inspect中体现。

❌ C. 已被弃用或隐藏的字段

1. Links (旧版链接)：
   • 在较新的 Docker 版本中，--link已被弃用。虽然hostconfig.json中可能仍保留Links字段（为了兼容性），但在docker inspect的输出中，它通常为空或被忽略，推荐使用自定义网络。
2. 内部 Go 结构体指针/引用：
   • 原始 JSON 文件中可能包含一些用于 Daemon 内部快速引用的 ID 或指针，这些在序列化给 API 客户端时会被清洗掉，只保留用户可读的数据。

❌ D. 安全性敏感信息的“明文”限制

1. Secrets 和 Configs 的内容：
   • 如果你使用 Docker Swarm 的secrets或configs，docker inspect只会显示它们的 ID 和名称，绝不会显示 secret 的实际内容（密码、密钥等）。这是出于安全考虑。
   • 注意：如果是通过-e PASSWORD=123设置的环境变量，inspect会明文显示在Config.Env中。这是一个常见的安全隐患。

❌ E. 宿主机的内核级 Cgroup 路径细节

• inspect显示资源限制值（如Memory: 512m），但不直接显示该容器在宿主机/sys/fs/cgroup/...下的具体控制文件路径和内容。虽然可以通过CgroupPath字段推断，但具体的 cgroup 文件系统层级结构需要直接在宿主机上查看。

5.3. 如何验证？

你可以自己对比一下：

1. 查看 inspect 输出：

   dockerinspect<container_id>>inspect_output.json

2. 查看原始文件：

   cat/var/lib/docker/containers/<container_id>/hostconfig.jsoncat/var/lib/docker/containers/<container_id>/config.v2.json

3. 对比关键字段：
   你会发现inspect_output.json中的HostConfig对象与hostconfig.json几乎一模一样（除了格式化和可能的默认值填充）。Config对象与config.v2.json也高度一致。

6. 为什么要把它们分开？

1. 解耦应用与环境：

   • 应用逻辑（代码、配置）应与运行基础设施（CPU、内存、网络）解耦。这使得同一个镜像（config相同）可以在开发环境（低资源限制）和生产环境（高资源限制）中使用，只需改变hostconfig。

2. 生命周期管理不同：

   • 应用配置通常在构建镜像或启动时确定，之后保持不变。
   • 资源配置可能需要根据负载动态调整（例如自动扩缩容时调整 CPU 限制），hostconfig的设计支持这种部分热更新。

3. 安全性隔离：

   • hostconfig包含大量涉及宿主机安全的敏感信息（如挂载点、特权标志）。将其分离有助于安全审计工具专门扫描运行时风险，而不必关心应用内部逻辑。

7. 总结与建议

• 调试应用行为（如环境变量不对、启动命令错误）：查看config.v2.json。
• 调试资源问题（如 OOM Killed、端口不通、权限拒绝、挂载失败）：查看hostconfig.json。
• 不要手动编辑这两个文件：Docker Daemon 在内存中维护状态，手动编辑文件会导致内存状态与磁盘状态不一致，可能导致容器无法启动或守护进程崩溃。始终使用docker run,docker update,docker commit等标准命令。