Docker Engine v29 正式将 containerd 镜像存储定位为新安装的默认后端，这一变更标志着 Docker 存储架构进入新阶段。对于在 Linux 主机上直接运行 Docker Engine 的开发者与运维人员理清这一变更的技术细节、评估迁移策略，以及理解对现有工作负载的潜在影响，将是确保容器基础设施稳定运行的关键。
变更背景与技术动因
containerd 最初作为 Docker Engine 的核心组件被拆分，随后捐赠给云原生计算基金会（CNCF），现已成为行业标准的容器运行时，广泛服务于 Kubernetes 及各类容器平台。Docker 多年前已在容器执行层面引入 containerd，但在镜像层管理上仍沿用传统的 graph driver 存储后端。随容器生态演进，containerd 发展出独立的镜像内容存储与快照管理框架，该框架在模块化、性能及生态兼容性方面具有显著优势。
Docker 桌面版在过去一年中已默认采用 containerd 镜像存储。Docker Engine v29 将这一默认配置引入 Moby 引擎，意味着在 Linux 服务器上进行全新安装时，镜像层与内容管理将经由 containerd 完成，而非传统的 graph driver。官方明确指出，此次变更仅影响新进行安装的系统；现有主机不会被强制迁移，但可选择主动迁移以保持与新环境的统一。
存储路径的实质性变化
新安装模式下，镜像数据不再存放于 /var/lib/docker 目录结构，而是迁移至 /var/lib/containerd。这意味着镜像层、快照及内容元数据的存储位置发生了根本性改变。对于依赖特定路径进行监控、备份或安全审计的运维流程，这一变更需要重新评估现有工具链的适配性。
传统 graph driver 存储结构中的镜像层、容器层及卷数据在新架构下具有完全不同的组织方式。containerd 采用的内容存储与快照机制更接近现代容器运行时的标准实践，但这也意味着此前基于 /var/lib/docker 编写的自动化脚本、监控探针或备份策略可能需要相应调整。官方同时保留了对 legacy graph driver 的支持，虽然已标记为弃用，但在 v29 版本中仍可通过配置选项显式启用。
迁移路径与兼容性考量
对于现有 Docker 主机，官方提供了自愿迁移的选项。用户可通过配置文件或启动参数主动启用 containerd 镜像存储，将现有的镜像与容器内容迁移至新存储后端。Docker 官方承诺将发布完整迁移指南，帮助团队将存量内容转移至 containerd 存储。然而，由于两种存储模型在元数据组织与层管理机制上存在差异，迁移过程需要谨慎规划，建议在非生产环境完成验证后再应用于生产系统。
需要特别说明的是，Docker Desktop 用户无需采取任何行动 —— 桌面版的产品更新会自动包含 Engine 变更。本次公告仅面向在 Linux 主机上直接运行 Docker Engine（社区版）的用户群体。对于这些用户，理解存储后端差异、提前规划迁移步骤，将在后续版本完全移除 graph driver 时避免被动。
工程实践建议
针对此次变更，建议生产环境运维团队采取以下行动：首先，在测试环境部署 v29 新安装，验证监控、备份与安全工具链与 /var/lib/containerd 路径的兼容性；其次，梳理依赖存储路径的自研脚本或第三方工具，评估是否需要更新配置或替换方案；第三，若计划在新主机上部署 Docker v29，应在部署文档中明确标注新的存储路径约定，便于团队统一认知；最后，对于有标准化存储架构需求的企业，可在测试环境中尝试从现有 graph driver 迁移至 containerd 存储，评估迁移风险与停机窗口需求。
资料来源：本文技术细节参考 Docker 官方博客发布的 Engine v29 公告及 Docker Engine 存储配置文档。