2023-12-11 如何优化 Docker 下 Node.js 项目的体积

参考链接：

docker-minimize：https://github.com/CaoMeiYouRen/docker-minimize

RSSHub：https://github.com/DIYgod/RSSHub

Docker 镜像体积优化：https://blog.cmyr.ltd/archives/e0dc9e5a.html

前言

在很久以前，我写过一篇博客 Docker 镜像体积优化来说明如何 Docker 镜像体积，但实际上，那篇文章有一个遗漏的地方，那就是：只说明了如何优化 Node.js 运行时的体积，而没有说明如何优化包含 node_modules 依赖的体积。

现在，本文将补上这最后一个关键点。

在开始解释 RSSHub 的 Dockerfile 之前，先看下常见的优化 Docker 下 Node.js 项目的体积的方案。

一、分段构建

对比以下两个 Dockerfile 的差异

方案一

FROM caomeiyouren/alpine-nodejs:1.1.0 as builder

WORKDIR /home/app

COPY package.json .npmrc /home/app/

RUN pnpm i

COPY . /home/app

RUN pnpm run build

EXPOSE 3000

CMD ["pnpm", "start"]

方案二

# 阶段一：构建阶段
FROM caomeiyouren/alpine-nodejs:1.1.0 as builder

WORKDIR /home/app

COPY package.json .npmrc /home/app/

RUN pnpm i

COPY . /home/app

RUN pnpm run build

# 阶段二：生产阶段
FROM node:20-alpine

WORKDIR /home/app

COPY --from=builder /home/app /home/app

EXPOSE 3000

CMD ["node", "dist/main"]

可以看到，相比方案一，方案二采用了分阶段构建的方法。

在这种情况下，最终的构建产物中将只保留生产环境所需的依赖，而不需要开发环境、构建环境下的依赖

具体的体积差异参考下图。

392MB vs 338MB，可见还是有一定差距的。

二、精简依赖

例如，将

npm i

替换为

1	npm i --production

此时会只下载生产环境依赖，可以减少部分体积。

但在这里，我要揭示一个真相，那就是，在 Node.js 生态中，使用 npm i --production替换npm i无法减小多少镜像体积！！！

有图为证。

此处以 docker-minimize 项目作为例子。

虽然实际上用的 pnpm ，但原理类似。

caomeiyouren/alpine-nodejs 是我个人封装的一个精简版 Node.js 镜像，比官方的 node:alpine 体积还小。

1. npm i 的情况

# 阶段一：构建阶段
FROM caomeiyouren/alpine-nodejs:1.1.0 as builder

WORKDIR /home/app

COPY package.json .npmrc /home/app/

RUN pnpm i

使用 docker images 查看镜像体积可见，体积达到了 391MB！

那么接下来我们来看看使用 npm i --production会不会减小镜像体积。

2. npm i –production

# 阶段一：构建阶段
FROM caomeiyouren/alpine-nodejs:1.1.0 as builder

WORKDIR /home/app

COPY package.json .npmrc /home/app/

RUN pnpm i --production

可以看到，在使用了pnpm i --production后，镜像体积为 390MB，相比之前的镜像体积竟然只减少了1MB！

要知道， docker-minimize 中使用的devDependencies数目是非常多的，在减去这些之后居然还没有减少！

问题出在了哪里？

通过 npm i –production 精简依赖存在的问题

实际上，在 Node.js 项目中，node_modules 的体积一般是随项目对数增长的，即依赖越多，node_modules 体积增长的越缓慢。

这又是为什么？

原因在于，无论是 npm、yarn 还是 pnpm，无一例外的都采用了多种方案来复用 node_modules 中存在的相同依赖，以减少 node_modules 的总体积，故 node_modules 的体积不是随依赖数目线性增加的，而是对数增长。

可以简单的理解为，安装的依赖越多，新增的依赖和原有依赖存在相同依赖的可能性更大。

读者可以点开 node_modules 看看，依赖的数目是不是惊人的多。如果使用 pnpm 请点开 node_modules/.pnpm。

所以，这就导致了明明使用了npm i --production，减少的体积却没多少。

RSSHub 精简依赖的思路

那么问题来了，RSSHub 是做了什么才让他们的镜像体积这么小的？

答案就在他们的这个 minify-docker.js 脚本里。

/* eslint-disable no-console */
const fs = require('fs-extra');
const path = require('path');
const { nodeFileTrace } = require('@vercel/nft');
// !!! if any new dependencies are added, update the Dockerfile !!!

const projectRoot = path.resolve(process.env.PROJECT_ROOT || path.join(__dirname, '../..'));
const resultFolder = path.join(projectRoot, 'app-minimal'); // no need to resolve, ProjectRoot is always absolute
const files = ['lib/index.js', 'api/vercel.js'].map((file) => path.join(projectRoot, file));

(async () => {
    console.log('Start analyzing, project root:', projectRoot);
    const { fileList: fileSet } = await nodeFileTrace(files, {
        base: projectRoot,
    });
    let fileList = Array.from(fileSet);
    console.log('Total touchable files:', fileList.length);
    fileList = fileList.filter((file) => file.startsWith('node_modules/')); // only need node_modules
    console.log('Total files need to be copied (touchable files in node_modules/):', fileList.length);
    console.log('Start copying files, destination:', resultFolder);
    return Promise.all(fileList.map((e) => fs.copy(path.join(projectRoot, e), path.join(resultFolder, e))));
})().catch((err) => {
    // fix unhandled promise rejections
    console.error(err, err.stack);
    process.exit(1);
});

接下来让我们看一下这个脚本做了什么。

const { nodeFileTrace } = require('@vercel/nft');
const { fileList: fileSet } = await nodeFileTrace(files, {
    base: projectRoot,
});
fileList = fileList.filter((file) => file.startsWith('node_modules/'));
return Promise.all(fileList.map((e) => fs.copy(path.join(projectRoot, e), path.join(resultFolder, e))));

整体而言，这个脚本就做了一件事，使用 @vercel/nft分析依赖，获取所有真正使用到的依赖，然后保留其中以node_modules/开头的文件，复制到指定的目录。

而这个脚本，才是今天要说的重点！

正确的精简依赖的方法

本人在 RSSHub 脚本的基础上又改了下，使之可以适配更多的项目，做到开箱即用！具体参考：minify-docker.js

将 minify-docker.js放在项目根目录的 scripts 文件夹下，例如scripts/minify-docker.js。

然后在 Dockerfile 中这样写。

# 阶段一：构建阶段
FROM caomeiyouren/alpine-nodejs:1.1.0 as builder

WORKDIR /home/app

COPY package.json .npmrc /home/app/

RUN pnpm i

COPY . /home/app

RUN pnpm run build

# 阶段二：缩小阶段
FROM caomeiyouren/alpine-nodejs:1.1.0 as docker-minifier

WORKDIR /home/app

RUN pnpm add @vercel/nft@0.24.4 fs-extra@11.2.0 --save-prod

COPY --from=builder /home/app /home/app

RUN export PROJECT_ROOT=/home/app/ && \
    node /home/app/scripts/minify-docker.js && \
    rm -rf /home/app/node_modules /home/app/scripts && \
    mv /home/app/app-minimal/node_modules /home/app/ && \
    rm -rf /home/app/app-minimal

# 阶段三：生产阶段
FROM caomeiyouren/alpine-nodejs:1.1.0

ENV NODE_ENV production

WORKDIR /home/app

COPY --from=docker-minifier /home/app /home/app

EXPOSE 3000

CMD ["pnpm","run", "start"]

此时你就能得到一个体积非常小的 Node.js 镜像！仅仅 106MB！，差不多是之前的四分之一！

完整的项目请参考：docker-minimize 。可以自动动手试试！

三、最小化运行时

在看完上述 Dockerfile 后，你可能会注意到，我在构建环境和生产环境都使用了caomeiyouren/alpine-nodejs:1.1.0这个镜像作为基础。

在 caomeiyouren/alpine-nodejs中，安装了 Node.js、Npm、Git、Pnpm 等构建环境的必须软件，但在生产环境中，只需要 Node.js 就够了，所以还存在减少体积的空间。

所以可以将生产环境的基础镜像改成 caomeiyouren/alpine-nodejs-minimize，这是一个由我自己打包的最小化 Node.js 镜像，比官方的node:alpine镜像体积还要小很多！

# 阶段三：生产阶段
FROM caomeiyouren/alpine-nodejs-minimize:1.0.0

ENV NODE_ENV production

WORKDIR /home/app

COPY --from=docker-minifier /home/app /home/app

EXPOSE 3000

CMD ["node", "dist/main.js"]

没图没真相，参考下图可知，本人打包的 Node.js 镜像在压缩后比官方的还要小 22MB！

总结

本文介绍了如何优化 Docker 下 Node.js 项目的体积。首先，通过分段构建和精简依赖的方法可以减小镜像体积。分段构建可以通过多个阶段构建来只保留生产环境所需的依赖，而精简依赖可以通过只下载生产环境依赖来减少体积。然而，仅使用npm i --production无法显著减小镜像体积，因为在 Node.js 生态中，依赖的体积是随项目对数增长的。为了解决这个问题，可以使用工具如@vercel/nft来分析真正使用到的依赖，并复制到指定目录，从而减小镜像体积。最终，通过正确的精简依赖的方法，可以得到一个体积更小的 Node.js 镜像。

【总结由 Chat LangChain 生成】

本文作者：草梅友仁
本文地址： https://blog.cmyr.ltd/archives/be640cee.html
版权声明：转载请注明出处！