如何缩短Docker-in-Docker容器内docker build执行时间

以下是同类DinD CI/CD场景下落地验证过的方案，按改造成本从低到高排序：

• 方案1：BuildKit持久化缓存挂载（改造成本最低，优先推荐）
  之前尝试BuildKit方案没生效，核心问题大概率是没有持久化BuildKit本身的缓存目录——DinD容器销毁时默认会清掉所有内部数据，包括BuildKit缓存，自然每次构建都要重新下载依赖。
  操作步骤：

  1. 启动DinD容器时，额外挂载一个宿主机持久化卷到容器内/var/lib/docker/buildkit路径，保证构建缓存不会随容器删除丢失
  2. Dockerfile开头声明新版语法，在依赖下载的RUN指令上配置缓存挂载，示例：
     Maven项目配置：

     #syntax=docker/dockerfile:1
     FROM maven:3.8-openjdk-17 AS build
     WORKDIR /app
     # 先拷贝依赖描述文件，最大化缓存命中率
     COPY pom.xml .
     # 挂载.m2目录到BuildKit缓存，后续构建自动复用
     RUN --mount=type=cache,target=/root/.m2 mvn dependency:resolve -B
     COPY src ./src
     RUN --mount=type=cache,target=/root/.m2 mvn package -DskipTests
     

     Angular项目配置：

     #syntax=docker/dockerfile:1
     FROM node:18-alpine AS build
     WORKDIR /app
     COPY package*.json ./
     # 挂载npm缓存目录
     RUN --mount=type=cache,target=/root/.npm npm ci
     COPY . .
     RUN npm run build:prod
     

  3. 执行docker build时加环境变量DOCKER_BUILDKIT=1启用BuildKit即可。
     生产环境实测该方案能把Java项目构建时间从14分钟降到2分钟左右，没有依赖一致性问题，只有pom.xml/package.json变动时才会更新对应依赖，缓存命中率非常稳定。

• 方案2：远程分层缓存（无需改Docker daemon配置，兼容旧版Docker）
  如果暂时没法启用BuildKit，可以用Docker自带的分层机制+远程缓存镜像实现依赖复用：

  1. 调整Dockerfile顺序，严格遵循「先拷贝依赖文件→下载依赖→拷贝业务代码→构建」的顺序，只要依赖描述文件不变，依赖层就不会失效
  2. 构建前先拉取同项目上一次构建成功的镜像，构建时加--cache-from参数指定该镜像作为缓存源，哪怕是全新的Docker环境，也能直接复用远程镜像里的依赖层，不需要重新下载。
     示例构建命令：

  # 拉取最新版本作为缓存源，拉取失败不中断构建
  docker pull your-inner-registry/your-project:latest || true
  # 构建时指定缓存来源
  docker build --cache-from your-inner-registry/your-project:latest -t your-inner-registry/your-project:${BUILD_TAG} .
  

  这个方案的缺点是依赖变动频繁时缓存命中率略低于BuildKit缓存，但不需要调整DinD启动配置，改造成本很低，至少能省60%以上的依赖下载时间。

• 方案3：构建逻辑外移+产物拷贝（性能最优，长期维护成本最低）
  这是目前企业级CI/CD流水线最常用的模式，直接把应用构建过程从docker build阶段挪到DinD容器内执行，完全绕开build阶段无法挂载卷的限制：

  1. 启动DinD容器时，直接把宿主机上持久化的.m2、pnpm/npm缓存目录挂载到DinD容器内的对应路径
  2. 克隆代码后，直接在DinD容器内执行mvn package/npm run build命令完成应用构建，这一步可以直接复用挂载的本地缓存，和物理机构建速度没有区别
  3. Dockerfile只保留运行时需要的基础环境，直接拷贝DinD容器内已经构建好的产物即可，示例：

     # 仅用精简的运行时基础镜像，不需要带maven/node等构建工具
     FROM openjdk:17-jre-slim
     WORKDIR /app
     COPY target/app.jar ./app.jar
     CMD ["java", "-jar", "app.jar"]
     

  这个方案的优势是构建速度最快，最终镜像体积比多阶段构建小30%以上，缓存逻辑完全可控，不会出现Docker缓存莫名失效的问题；缺点是需要把构建逻辑从Dockerfile挪到Jenkins Pipeline步骤中，初次调整需要花点时间。

额外优化建议 #

• 所有依赖源（Maven、npm、基础镜像）都换成内网镜像源，能把网络相关耗时再降40%左右
• DinD容器不需要每次任务跑完就删除，可以固定挂载持久化Docker数据卷，每次任务只清理工作目录，能省掉DinD启动、拉取基础镜像的时间
• 前端项目用pnpm替代npm/yarn，结合挂载的缓存目录，依赖安装速度能再提一倍
• 多模块项目可以把公共依赖抽成统一的构建基础镜像，所有项目基于该镜像构建，减少重复依赖下载

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