全局视角的观点是，为什么要看这两个文件

痛点 1：在升级或迁移 Docker 时担心后端实现变化会导致现有脚本、CI/CD 流程崩溃。

Docker 镜像管理正经历历史性的后端迁移

• 老后端: daemon/images/ —— 基于自研的 graph driver，自管 layerStore / imageStore / refStore。
• 新后端: daemon/containerd/ —— 直接复用 containerd 的 image store + content store + snapshotter，默认方法已改为此处。

两个后端实现了完全相同的接口，所以 daemon 主流程、API 路由、CLI 命令感知不到后端切换。这正是经典的门面模式+ 策略模式。

学习这两个文件的价值：

1. 理解“接口隔离”daemon 主流程不依赖具体后端。只依赖 ImageService 接口，这是 Docker 能完成大规模重构的关键。
2. 理解“门面”的意义: images.ImageService 与 containerd.ImageService 各自都是一组复杂子程序的门面
3. 理解“迁移代价”: 两个实现各自独立，如何保证行为等价是工程上的主要挑战。不过，

至于门面契约，daemon.ImageService 接口概览

// ImageService is a temporary interface to assist in migration to
// containerd image-store. This interface should not be considered stable。// and may change over time.
type ImageService interface {
// ===== Images =====
PullImage
PushImage
CreateImage
ImageDelete
ExportImage
LoadImage
Images
LogImageEvent
CountImages
ImagePrune
ImportImage
TagImage
GetImage
ImageHistory
CommitImage
SquashImage
ImageInspect
ImageDiskUsage
// ===== Layers =====
GetImageAndReleasableLayer
CreateLayer
CreateLayerFromImage
GetLayerByID
LayerStoreStatus
GetLayerMountID
ReleaseLayer
GetContainerLayerSize
Changes
// ===== Windows =====
GetLayerFolders
// ===== Build =====
MakeImageCache
CommitBuildStep
// ===== Or =====
DistributionServices
Children
Cleanup
StorageDriver
UpdateConfig}

接口的五个语义分组

“Temporary Interface” 的工程含义 

*痛点 2*：在迁移期间，一些方法在新后端并不存在对应实现，导致代码报错或功能缺失。

• SquashImage、GetLayerMountID 在 containerd 后端没有自然对应，可能在未来被移除或重设计。
• Apollo 团队提醒：接口在迁移期会演化，调用方不应把它当作稳定 API 依赖。
• Docker 主流程仍然依赖该抽象，这正是用 “抽象换取演进空间” 的典型实践。

再看老后端门面，images.ImageService

type ImageService struct {
containers containerStore
distributionMetadataStore metadata.Store
downloadManager *xfer.LayerDownloadManager
eventsService *daemonevents.Events
imageStore image.Store
layerStore layer.Store
pruneRunning atomic.Bool
referenceStore refstore.Store
registryService distribution.RegistryResolver
uploadManager *xfer.LayerUploadManager
leases leases.Manager
content content.Store
contentNamespace string
}

构造函数这方面，

func NewImageService *ImageService {
log.G.Debugf
...
return &ImageService{
containers: config.ContainerStore。distributionMetadataStore: config.DistributionMetadataStore,downloadManager: xfer.NewLayerDownloadManager(config.LayerStore,config.MaxConcurrentDownloads,xfer.WithMaxDownloadAttempts),eventsService: config.EventsService,imageStore: &imageStoreWithLease{
至于Store，config.ImageStore,leases: config.Leases,ns: config.ContentNamespace,},layerStore: config.LayerStore,referenceStore: config.ReferenceStore,registryService: config.RegistryService,uploadManager: xfer.NewLayerUploadManager,leases: config.Leases,content: config.ContentStore,contentNamespace: config.ContentNamespace,}
}

装饰器模式的观点是，

*痛点 3*：担心手动管理 lease 会出错导致资源泄漏。装饰器为所有写入操作自动包装 lease，免去手动介入。

• The original a.image.Store)只负责镜像元数据读写。
• imageStoreWithLease` 在外层套了一层 lease 管理。使得写操作自动绑定 containerd lease，从而保证元数据与 content 生命周期一致。
• "门面 + 装饰器" 两种模式叠加，实现了调用方无感知的 lease 管理。
\

老后端依赖关系图\*

graph LR;subgraph images.ImageService
iS --> lS;iS --> rS，iS --> dM;其实，iS --> uM;iS --> ev，lS --> gD;怎么说呢，gD --> cs;end，

*痛点 4*：如果自行实现 layer/store，会陷入底层细节泥潭。Docker 已经帮你封装好这些细节，只需通过门面调用即可。

典型门面方法示例——CreateLayer
func CreateLayer {
var img *image.Image
if container.ImageID!= "" {
containerImg,err := i.imageStore.Get
if err!= nil { return nil,err }
img = containerImg
}
rwOpts := &layer.CreateRWLayerOpts{
MountLabel: container.MountLabel,InitFunc: initFunc。StorageOpt: container.HostConfig.StorageOpt,}
return i.CreateLayerFromImage
}


*痛点 5*：想要自己拼装层时不必了解底层图形驱动和引用管理细节，只需传入容器对象和初始化函数即可。

新后端门面这方面，
type ImageService struct {
client *containerd.Client
images c8dimages.Store
content content.Store
containers container.Store
snapshotterServices mapsnapshots.Snapshotter
snapshotter string
registryHosts docker.RegistryHosts
registryService distribution.RegistryResolver
eventsService *daemonevents.Events
pruneRunning atomic.Bool
refCountMounter snapshotter.Mounter
idMapping user.IdentityMapping
policyVerifier func
identity imageIdentityState
defaultPlatformOverride platforms.MatchComparer
}


说到构造函数。New Service

func NewServ ic e *Ima geSer vice{
service := &Im ageServ ice{
client :conf ig .Client,images :conf ig .Client .Imag eSe rvice,conten t :conf ig .Client .Conte ntSt ore,snap sh otterSer vices :map snapshots.Snapshot ter{ conf ig .Snapsh otter :conf ig .Clie nt.Snapsh ot service,},...
}
service.startI mageIden tityCacheRefresh // 背景 goroutine
return service}



*痛点 6*：想一次性获取所有底层服务却找不到入口？
只需要一个 `containerd.Client` 实例。即可获得 images、content、snapshot 等全部子程序，无需分别实例化。

多 Snapshotter 懒加载机制 – `snapshotterServic e` 

func snapsh otte rServi ce snapshots.Sna pshot ter{
s,ok :=i.snap shot terServi ces
if!ok{ s =i.clien t.Snapsho tser vice
i.snap sho tte rServic es=s }
return s}



*痛点 7*：业务场景需要不同文件程序，但默认只能使用一种？此映射表让你按需创建并缓存任意 snapshotter，实现灵活切换。

同一接口，两种实现——对照表 


方法
老后端 
新后端 



CountImages
i.imageStor e.Len )
i.client.ListImages + digest 去重 )<\/ td><\/ tr>

LayerSt oreStatus
i.layerStor e.DriverStatus
返回占位符 {{"driver-type"。"SnapshotPlugin"}}<\/ td><\/ tr>

GetLay erMountID
i.layerSto re.GetMountID
NotImplemented<\/span>\<\/ td><\/ tr>

Cleanup
i.layerSto re.Cleanup
停止身份缓存刷新并关闭 cache backend<\/ td><\/ tr>

StorageDriver
i.layerStor e.DriverName
snapshotter 名称<\/ td><\/ tr>
<\/tbody>







关键差异解读 – CountImages 示例 

// 老后端：
func CountImages int { return i.imageSto re.Len }
// 新后端：
func CountImages int {
imgs,err := i.client.ListImages
if err!= nil { return0 }
uniq := mapstruct{}{}
for _,im := range imgs { uniq = struct{}{} }
return len
}



*痛点 8*：担心统计结果不一致？老实现直接读取本地 map，新实现因为容器可能出现多 tag。需要按 digest 去重才能匹配 Docker “独立镜像数”的语义。

PullImage 深度对比 – 门面+策略最佳案例 

*痛点 9*：在 CI 中经常看到 Pull 卡住或失败回滚异常，不知道到底是哪个层出了问题？下面两段代码展示了老旧与新版在错误处理和资源回收上的根本区别。

老后端 PullImage 

func PullIm age error {
if len>1 { return cerrdefs.ErrInvalidArgument.WithMessage }
// 调用 docker 自己实现的 distribution.Pull …至于err，= i.pullIm ageWi thReference
// 手动清理下载 manager、临时层等…return err}





使用内部 distribution.Pull 完全自行完成 HTTP 拉取与层写入；手动维护下载并发与失败回滚逻辑。<\/ li>

所有写入直接落到 layerSt ore 与 imageSt ore若中途失败，需要自行删除残留层。<\/ li>
<\/ul>




func PullIm age{
if len>1{ return cerrdefs.ErrInvalidArgument.WithMessage}
ctx。done,:= i.withLease// 自动绑定 lease
defer done
if!reference.IsNameOnly{ return i.pullTag} // 单 tag 拉取
tags,:=distribution.Tags
for 。t:=range tags{
ref,:=reference.WithTag
if err:=i.pullTag;err，=nil{return err}
}
return nil}





通过 containerd lease 把本次拉取涉及的所有 blob 自动绑定到临时 lease；失败时 lease 自动 GC，无需额外清理代码。<\/ li>

真正拉取工作交给 client.Pull 完成，Docker 不再自己实现 HTTP 协议栈。<\/ li>

若没有指定 tag。会先列出所有 tag 再循环拉取，实现了 “docker pull redis” 的兼容行为。<\/ li>
<\/ul>





差异小结 



错误回滚： 老版必须手动删除已下载但未完整校验的层；新版 rely on lease 自动 GC。<\/ li>

并发控制： 老版通过 xfer.LayerDownloadManager；新版交给 containerd 内部调度。<\/ li>

进度上报： 两者均保持相同签名。将进度写入 OutStream，不影响已有 CLI 脚本。<\/ li>
<\/ul>





子门面及其作用 – 小模块的大价值 

imageIdentityState ：身份映射子门面