解读

面试官抛出此题，表面看是命令行为，实则考察候选人对 镜像分层机制、可重复性、安全合规、CI/CD 可追溯性 的综合理解。国内大厂在落地“不可变基础设施”时，普遍禁止随意 commit，因此回答必须点出“层如何来、为什么大、为什么脏、如何治理”。

知识点

1. 联合文件系统（UnionFS）：镜像=只读层堆叠，容器=只读层+可写层。
2. commit 动作：把容器最上方的可写层 以只读方式固化 成新层，生成全新镜像 ID，原镜像其余层保持不变。
3. 层内容：包含所有 文件系统增量（新增、修改、删除记录），以及提交时刻的 环境变量、默认命令、元数据。
4. 层大小：可写层若产生大文件、日志、缓存、临时包，则新层同等膨胀。
5. 层不可变：一旦 commit，该层进入本地 layer store，无法原地修改，后续只能再叠加新层，导致“洋葱式”臃肿。
6. 安全风险：
   • 可能残留 源码、密钥、数据库密码、SSH 私钥；
   • 非 root 用户权限可能被改回 root；
   • 基础镜像漏洞随 commit 被“快照”下来，无法通过更新基础镜像修复。
7. 可追溯性：commit 生成的镜像 无 Dockerfile、无构建上下文，不符合国内监管对“可审计、可回滚”的要求，难以通过等保 2.0 测评。
8. 性能与缓存：新层无法利用 Docker build 缓存，后续构建全量复制，拉长 CI 时间。

答案

docker commit 的本质是把容器顶层的可写层 冻结成一个新的只读层，并与原有镜像层链式串联，生成全新镜像。
步骤：

1. 暂停容器（可不停，但会捕获不一致状态）；
2. 将可写层中的文件系统差异（增删改）打包成 tar；
3. 计算 SHA256，生成新层 ID；
4. 在本地镜像元数据里注册新配置对象，形成新镜像 ID。

潜在风险

• 体积失控：日志、调试文件、包缓存被一并快照，镜像轻松突破 GB；
• 敏感数据泄露：临时写入的 .env、*_key.pem 被固化，推送仓库即泄露；
• 配置漂移：手动安装软件、修改启动脚本，导致“同名镜像不同内容”，破坏环境一致性；
• 安全基线失守：commit 后无法关联 SBOM，漏洞扫描工具只能看到“黑盒”，等保测评直接判负；
• 回滚困难：缺少 Dockerfile，无法重新构建，只能依赖备份镜像，违反金融、电信行业可审计要求；
• 缓存失效：CI 流水线无法复用层，构建时长翻倍，在云原生场景下直接拉低发布效率。

因此，国内生产环境普遍用 Dockerfile + 多阶段构建 + ARG/SECRET 隔离 替代 commit，仅在应急调试场景临时使用，并立即通过 dive 或 syft 做层分析，确认无敏感数据后再考虑是否入库。

拓展思考

1. 如果必须保留 commit，如何最小化风险？

   • 在容器内先执行 yum clean all && rm -rf /var/cache、find /tmp -type f -delete，再 commit；
   • 使用 --change='USER <uid>' 强制非 root；
   • 立即 docker scan <新镜像> 并输出 SBOM，上传至公司 Harbor 的“待审核”项目，通过 OPA Gatekeeper 校验无 Critical 漏洞 后才允许转正式项目。

2. 如何证明 commit 的镜像与线上事故无关？

   • 在 commit 前后分别 docker diff 导出文件列表，存入审计日志；
   • 利用 docker inspect 提取容器启动命令、环境变量，与变更单比对，确保无未授权修改。

3. 未来彻底淘汰 commit 的技术路径：

   • 全面采用 BuildKit 缓存挂载（RUN --mount=type=cache）替代运行时安装；
   • 使用 Tekton 或 GitLab CI 的“不可变基础设施”模板，构建产物仅允许从 Dockerfile 产出；
   • 通过 镜像签名与策略引擎（Kyverno/Notation） 阻断任何无 Dockerfile 来源的镜像进入生产集群，实现“commit 零信任”。