docker commit 是什么
commit 把容器可写层的当前内容固化成一个新镜像，可以理解为给运行中的容器拍快照。它在应急与实验场景很实用：容器里手工修好了配置、装好了依赖，先提交成镜像把状态保住。但要清楚它的代价——提交产物没有构建历史、内容不可复现、容易夹带日志与临时文件，所以正规交付路径仍然是把改动写回 Dockerfile 重新构建。
基本信息
| 语法 | docker commit [选项] 容器 [仓库[:标签]] |
|---|---|
| 常用选项 | -a 作者、-m 提交说明、-c 追加 Dockerfile 指令、--pause=false 不暂停容器 |
| 默认行为 | 提交前暂停容器以保证文件系统一致性 |
| 提交内容 | 可写层相对基础镜像的全部改动 |
| 提交内容不含 | 挂载卷里的数据、容器网络与运行期设置 |
| 校验方式 | docker history 新镜像 查看层来源 |
典型使用场景
- 调试现场快照：保留崩溃前的文件系统状态供事后分析
- 应急修复留痕：先在容器里验证修复有效，再决定是否写回 Dockerfile
- 实验性改造：在容器里试装依赖，确认可行后据此整理构建脚本
- 移交排查材料：把问题容器提交成镜像交给他人复现
- 临时产出物提取：把容器内的产物目录做成镜像再用 docker create 拷出
提交与核对
提交与核对
# 提交并标注作者与说明，方便日后追溯来源
docker commit -a ops -m '排查现场：配置改回默认' web app/web:debug-20261013
# 提交时改启动命令（等价于追加一条 CMD）
docker commit -c 'CMD ["node","server.js"]' web app/web:snapshot
# 核对新镜像的层构成：能看到多出一层未标注来源的提交层
docker history app/web:snapshot
# 对比体积变化，判断是否夹带了日志与缓存
docker images --format '{{.Repository}}:{{.Tag}} {{.Size}}' | grep app/web选项怎么用
| 选项 | 作用 | 适用时机 |
|---|---|---|
| -a | 记录作者 | 团队协作追溯 |
| -m | 提交说明 | 说明改动原因与时间 |
| -c | 追加构建指令 | 补 CMD/ENV/EXPOSE 等 |
| --pause=false | 不暂停直接提交 | 容器不能暂停或要求无中断 |
| --change 反复使用 | 可叠加多条指令 | 一次补齐多项配置 |
为什么提交产物不可复现：它来自运行时文件系统的实际内容，同一份 Dockerfile 无法重复出完全一致的结果，构建历史里也看不到改动来源，团队接手时无从判断镜像里到底装了什么。
提交出来的镜像里会包含容器运行期间写入的日志、缓存、临时文件甚至密钥，作为交付镜像前必须逐项清理或改用重新构建的方式。