docker - 最小化 Docker-in-Docker 容器内的 `docker build` 执行时间

Question

用例:

我们在 Jenkins 中有几个“发布作业”build 和 push 应用程序的 Docker 镜像到 docker registry，更新各种文件中的项目版本，最后将发布标签推送到相应的 Git 存储库。整个过程在一个隔离的 Docker-in-Docker 容器中运行，这意味着每次执行这些 Jenkins 作业时，Docker 缓存都是完全空白的。

简而言之: Jenkins 实例 --> 启动 DinD 容器 --> Git 存储库被克隆到 DinD 容器内 --> 包含实际构建过程的多层 Dockerfile正在构建的应用程序 --> 将 docker 镜像推送到注册表 --> 将发布推送到 Git。

问题:

虽然这种隔离一方面有助于避免一些问题，但另一方面它使整个 docker 构建过程特别慢。

docker pull 和 docker push 进程肯定会在一定程度上造成这种延迟，但这是一个网络速度问题，我们无法处理 atm。

然而，造成这种延迟的另一个原因是，因为实际应用程序(maven 或 angular)是在一个“干净”的 docker 容器中构建的，其中 .m2 或 node_modules 目录每次都是空的，每次运行时必须下载/安装所有依赖项。显然，我们可以从 Jenkins 将 .m2 存储库挂载到 DinD 容器中，但是在此 DinD 容器中构建的图像将无法访问它。

我们尝试tar .m2 和 node_modules 目录，通过 Dockerfile COPY 它们在图像中，untar 它们并移动 他们到正确的路径，但此解决方法最多可保存 1-2 分钟。我们还尝试使用 buildkit 缓存 Maven 依赖项，例如https://www.baeldung.com/ops/docker-cache-maven-dependencies#caching-using-buildkit但这显然不是我们所需要的。

据我所知，不可能在 docker build 上挂载卷，这将是我们“空白缓存”情况下的理想解决方案。

有没有人遇到过类似的问题并找到了解决方法？

一般来说，如果您有任何关于如何最大限度地减少发布作业的执行时间并优化整个流程的建议，我们将不胜感激。

提前谢谢你。

Answer 1

就像评论中提到的 SiHa 一样，您可以拥有一个内部包含预构建依赖项的图像。这就是我可能会做的:

例如，使用轻量级的 node:16-alpine 图像(用于项目的 angular 部分)，从 github 克隆代码(使用 depth= 1 以加快速度)，运行 npm install 并将图像推送到您的存储库。在更新依赖项之前，您不必更改此图像。

在您的日常构建中，下载此镜像并克隆 github 代码，仅运行 npm run build，因为 node_modules 文件夹已在镜像中。使用 FROM 将构建的代码复制到您的最终图像。

使用轻量级图像而不是克隆整个存储库应该会加快很多速度，并且使用具有预构建依赖项的图像可能比在图像中复制/提取依赖项更快 - 取决于硬件和网络速度。