Docker镜像构建速度优化实现

背景

在最近临时支持的项目中，发现项目的构建流程耗时比较长，严重的影响了开发的进度。参照文档要发测试环境的时候，发现10分钟过去了还没有发布完成。项目是通过Docker来构建镜像部署的，所以想看看有没有什么方案，可以对Docker镜像构建进行优化。

现状

Dockerfile是长这样子的：

Dockfile文件分析

以下主要分析Dockerfile构建过程中主要执行的操作

一、基础镜像选择

首先定义了一个基础镜像FROM node:20.18.1-alpine AS base，这里选择了基于Alpine系统的Node.js版本20.18.1作为基础镜像。

二、依赖安装阶段（deps）

• 基于base镜像创建了deps镜像。

• 执行RUN apk add --no - cache libc6 - compat，这是在Alpine系统下安装libc6 - compat库，--no - cache表示不使用缓存。

• 将package.json、yarn.lock*、package - lock.json*、pnpm - lock.yaml*复制到当前工作目录（/app）。

• 根据不同的lock文件类型进行依赖安装：如果存在yarn.lock文件，执行yarn --frozen - lockfile，这是使用Yarn安装依赖并且确保使用lock文件中的版本，以保证可重复性。如果存在package - lock.json文件，执行npm ci，这是使用npm安装依赖并且确保按照package - lock.json中的版本精确安装。如果存在pnpm - lock.yaml文件，先全局安装pnpm（yarn global add pnpm），然后执行pnpm i --frozen - lockfile，同样是按照lock文件安装依赖。如果没有找到任何lock文件，则输出Lockfile not found.并以错误码1退出。

三、构建阶段（builder）

• 基于base镜像创建builder镜像。

• 从deps镜像复制/app/node_modules到当前工作目录下的node_modules。

• 复制当前目录（.）下的所有文件到/app。

• 执行yarn build:test，可能是使用Yarn构建测试版本的项目。

四、运行阶段（runner）

• 基于base镜像创建runner镜像。

• 设置环境变量NODE_ENV为production，表示生产环境。

• 从builder镜像复制/app/public到当前工作目录下的public。

• 从builder镜像复制/app/.next/standalone到当前工作目录下

• 从builder镜像复制/app/.app/.next/static到当前工作目录下的.next/static

构建镜像

通过运行Docker build的命令，我们可以看着在构建镜像的过程中，主要做了什么操作，每个操作耗时分别是多少：

可以看出，Docker镜像打包过程总共花费了614.6s，主要耗时集中在以下几个操作上：

• [internal] load metadata for docker.io/library/node:20.18.1-alpine: 4.4s

• => [internal] load build context: 23.8s

• => transferring context: 712.33MB: 23.8s

• => [deps 1/4] RUN apk add --no-cache libc6-compat: 3.0s

• => [deps 4/4] RUN if [ -f yarn.lock ]; then yarn --frozen-lockfile; elif [ -f package-lock.json ]; then npm ci; eli : 258.1s

• => [builder 2/4] COPY --from=deps /app/node_modules ./node_modules: 35.9s

• => [builder 3/4] COPY . .: 4.7s

• => [builder 4/4] RUN yarn build:test: 234.2s

优化

之前没有太多的Docker镜像打包经验，都是直接build写好的Dockerfile或者是基于开源的Dockerfile进行定制化开发（复制其他项目的拿过来改一下😊），所以搜了一下看看都有哪些优化的方案。单纯从Docker镜像打包来看，可以从以下几个方向入手：

• 使用更小的基础镜像

• 多阶段构建（Multi-stage Builds）

• 利用缓存加速构建

• 减少镜像层数

• 使用.dockerignore文件

• 分层打包（Layered Packaging）

• 静态二进制文件和“临时”基础映像

因为当前的项目已经做了1、2、6，所以我们还可以从4、5、7这三个方面考虑。

优化一：减少文件复制的时间

• 通过添加.dockerignore文件，过滤掉一些非必要的文件，来减少文件复制的时间。

• 我们看到之前的Dockerfile里，有一个复制node_modules的操作，花费了35.9s，可以想办法把这个去掉。

基于以上两点，对项目文件以及Dockerfile进行修改.

一、添加.dockerignore文件

内容如下：

node_modules
.next
src/.DS_Store
.vscode
.husky

二、Dockerfile调整

三、构建看效果

我们可以看到，=> [builder 3/4] COPY . .从 4.7s 降到了 1.8s， => [builder 2/4] COPY --from=deps /app/node_modules ./node_modules 这一步的耗时已经没有了。

优化二：重新构建一个新的镜像作为基础镜像

通过观察Dockerfile，我们发现以node:20.18.1-alpine镜像为基础镜像进行构建的时候，还需要安装libc6-compat，受网络波动的影响libc6-compat有时候下载比较慢。那我们可以把在node:20.18.1-alpine环境下，下载好libc6-compat单独打包成一个镜像，上传到公司内部的镜像仓库中，直接使用这个新镜像来作为基础镜像就可以了。如何构建镜像上传到公司内部镜像仓库，大家可以去看看Docker的教程就可以了，这里就不展开了。

一、Dockerfile调整

二、构建效果

我们可以看到通过构建一个新的镜像上传到内部镜像仓库中使用，不仅镜像下载速度变快了，还可以节省下了 => [deps 1/4] RUN apk add --no-cache libc6-compat下载的时间。

• [internal] load metadata for docker.io/library/node:20.18.1-alpine: 4.4s => 0.7s

• => [internal] load build context: 23.8s => 11.3s

• => transferring context: 712.33MB: 23.8s => 9.9s

• => [deps 1/4] RUN apk add --no-cache libc6-compat: 3.0s => 0s

总结

由于是临时支持了这个项目，在对项目改动不大的情况下去进行了一些尝试，而且仅针对Docker镜像自身构建的优化。通过这次实践来看，这个项目单纯从Docker方面来进行优化，效果相对来说还是不够的，减少了70s左右的时间。整个构建耗时的流程还是在安装依赖以及项目本身的构建上，如果要想显著的提高项目发布速度，还得从这两方面入手。

其他

中间尝试还进行了npm包的下载速度优化，因为这个改动相对来说也比较小。配置国内的npm源，速度确实会提升不少，如果公司内部搭建有完整的私有npm仓库，那速度将会大大提升。

还有另外一种方案，就是利用Docker 多阶段构建来对依赖进行分批下载，下载完成之后再合并到一起进行打包构建，这样子也许可以节省一些时间。

到此这篇关于Docker镜像构建速度优化实现的文章就介绍到这了,更多相关Docker镜像构建速度内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！