单文件挂载的两个前提
把宿主上的单个文件挂进容器常用来注入配置文件。这里有两个前提必须清楚:源文件要预先存在;绑定是按 inode 建立的,因此宿主侧的编辑方式会影响容器能否看到更新。用重写型编辑器保存时可能替换掉原 inode,容器里挂载的仍是旧文件,表现为配置改了却不生效。
基本信息
| 用途 | 把单个文件挂载进容器 |
|---|---|
| 典型写法 | 源文件路径加容器内路径,通常带只读选项 |
| 本质 | 按 inode 绑定,源文件必须预先存在 |
| 常见陷阱 | 重写型编辑器替换 inode 导致更新不可见 |
| 排查方式 | 在容器内读取文件内容做核对 |
典型使用场景
- 向应用注入配置文件
- 挂载证书或密钥文件
- 临时替换某个单文件做验证
- 排查配置改了但不生效的问题
- 决定单文件挂载还是目录挂载
挂载与核对
挂载与核对
touch $PWD/config.yml # 源文件必须先存在
docker run --rm -v $PWD/config.yml:/app/config.yml:ro alpine cat /app/config.yml
# 用重写型编辑器保存后,再核对容器内看到的内容
docker exec <容器> cat /app/config.yml
docker inspect -f '{{json .Mounts}}' <容器> | head -c 300 # 核对挂载来源情形与处理
| 情形 | 结果 | 处理 |
|---|---|---|
| 源文件不存在 | 被创建为同名目录 | 先创建文件再挂载 |
| 编辑器重写 inode | 容器仍读旧文件 | 重建容器或改用目录挂载 |
| 带只读选项 | 容器内不可修改 | 配置注入的推荐做法 |
| 目录挂载 | 目录内文件变更可见 | 需要频繁更新时优先选择 |
保存时替换 inode 是这类问题的主因:重启容器重建挂载即可恢复,长期方案通常是改用目录挂载。
源文件不存在时挂载会创建同名目录,容器里把目录当文件读取会直接报错,排查时容易只盯着应用日志。
实践建议
- 挂载前确认源文件存在,必要时先创建占位文件
- 频繁更新的配置优先挂载目录,而不是单个文件
- 需要避免容器误改时统一加只读选项
- 改动后进容器读取一次内容,确认变更真的可见