参考链接：
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
替换为
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 。可以自动动手试试！
总结
本文介绍了如何优化 Docker 下 Node.js 项目的体积。首先，通过分段构建和精简依赖的方法可以减小镜像体积。分段构建可以通过多个阶段构建来只保留生产环境所需的依赖，而精简依赖可以通过只下载生产环境依赖来减少体积。然而，仅使用npm i --production无法显著减小镜像体积，因为在 Node.js 生态中，依赖的体积是随项目对数增长的。为了解决这个问题，可以使用工具如@vercel/nft来分析真正使用到的依赖，并复制到指定目录，从而减小镜像体积。最终，通过正确的精简依赖的方法，可以得到一个体积更小的 Node.js 镜像。
【总结由 Chat LangChain 生成】
本文作者：草梅友仁
本文地址：https://blog.cmyr.ltd/archives/be640cee.html
版权声明：转载请注明出处！
