关于docker buildx du中Shared属性的判定逻辑及优化方法咨询

一、Shared: true/false的判定依据 #

Shared字段标识镜像层是否被多个构建实体（构建任务、镜像、buildx缓存实例）复用，判定逻辑如下：

• 当某一层的哈希值被至少两个不同的构建记录、镜像或者buildx缓存条目引用时，Shared会显示true。
• 如果该层仅被当前查询范围内的单个构建目标（比如某个特定镜像、某次独立构建任务）独占使用，没有其他任何构建实体依赖它，就会显示false。
• 缓存存储类型也会影响这个标记：使用共享缓存后端（如远程registry、共享本地目录、云存储缓存）的层，更容易被多个构建实例访问到，因此更大概率标记为true；而单个builder实例的私有本地缓存中的层，通常仅被该实例的构建任务使用，更可能是false。

二、如何增加可共享的内容 #

如果希望提升层的共享率，减少重复构建和存储空间占用，可以从以下几个方向入手：

• 配置共享缓存后端：
  创建buildx builder实例时指定共享缓存，让不同构建任务能共用缓存层。例如：

  docker buildx create --use --cache-from type=registry,ref=my-registry/cache-repo --cache-to type=registry,ref=my-registry/cache-repo,mode=max
  

  这样所有通过该builder执行的构建，都会从远程registry拉取可复用层，并将新生成的层推送到共享缓存中。

• 优化Dockerfile的层复用性：
  将不变的操作（比如安装系统依赖、语言包管理器依赖）放在Dockerfile的靠前位置，比如先COPY package.json再RUN npm install，后续修改业务代码时，不会重新生成依赖层，这个层就能被多次构建共享。

• 提取通用基础镜像：
  如果多个项目或构建任务有重复的步骤（比如都需要安装nginx、python3等），可以将这些通用步骤打包成一个基础镜像，让所有相关构建都基于这个基础镜像。基础镜像的所有层都会被引用它的构建共享。

• 构建时指定缓存来源：
  在执行docker buildx build时，通过--cache-from参数指定已有的镜像或缓存源，复用其中的层。例如：

  docker buildx build --cache-from my-app:latest --tag my-app:v1.0.0 .
  

• 清理孤立缓存层：
  定期执行docker buildx prune清理没有被任何构建实体引用的孤立层，剩下的缓存层基本都是被多个任务共享的，也能让后续的docker buildx du结果更准确反映共享状态。

内容的提问来源于stack exchange，提问作者Archimedes Trajano