已配置.dockerignore的Node.js应用Docker镜像体积过大问题咨询

问题相关截图 #

• Dockerfile截图：
• 镜像文件截图：

体积过大的常见原因 #

• 基础镜像选型过重：默认使用完整版node镜像、带构建依赖的系统镜像，仅基础镜像体积就可达数百MB甚至1GB以上
• 未使用多阶段构建，冗余内容残留：构建过程中安装的开发依赖、中间编译产物、包管理缓存、源码文件全部保留在最终镜像中，额外占用大量空间
• 依赖安装引入开发包：即使本地node_modules被.dockerignore忽略，若容器内执行npm install未添加生产参数，会将devDependencies中的构建工具、测试依赖全部装入镜像
• 镜像分层冗余：Dockerfile中大量分散的RUN、COPY指令会产生多余分层，每层的修改都会累加体积，无法自动抵消

通用优化方法 #

• 更换轻量基础镜像：生产环境优先选择alpine系列镜像，node:alpine、nginx:alpine体积普遍在100MB以内，比完整版镜像小80%以上
• 采用多阶段构建：将构建流程和运行镜像分离，第一阶段使用带构建能力的镜像完成依赖安装、代码编译，第二阶段仅拷贝运行必需的最终产物到轻量运行镜像中，完全丢弃构建阶段的所有冗余文件
• 安装依赖时过滤开发包：执行包安装命令时添加生产标识，比如npm install --production、pnpm install --prod，仅安装项目运行必需的依赖
• 清理冗余缓存：安装系统依赖、项目依赖后立刻清理缓存，比如npm执行npm cache clean --force，alpine系统执行rm -rf /var/cache/apk/*
• 合并Dockerfile指令：将多个连续的RUN指令合并为一条，减少不必要的镜像分层，降低分层额外开销

webpack+tree shaking优化可行性 #

该方案完全可行，优化效果非常明显：

• 生产模式下webpack会自动开启tree shaking能力，剔除项目中未被引用的死代码，配合代码压缩可将源码体积缩小60%以上
• 结合多阶段构建可实现极致体积优化：第一阶段在容器内完成webpack打包，第二阶段仅需要拷贝打包后的最终产物，不需要把完整的node_modules放入最终镜像。如果是前端项目，可直接使用nginx:alpine托管静态资源，最终镜像体积可控制在10MB以内
• 注意需将webpack的运行模式设置为production，同时项目代码遵循ES模块规范，才能保证tree shaking正常生效

内容的提问来源于stack exchange，提问作者arga wirawan