参考链接:
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 /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 /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 /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 /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://wp.cmyr.ltd/archives/how-to-optimize-the-volume-of-the-dock-under-node-js
- 版权声明: 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
欢迎关注我的其它发布渠道
发表回复
要发表评论,您必须先登录。