Node.js Docker镜像体积优化实战：从920MB到51MB的演进

Node.js Docker镜像体积优化实践

你是否曾为应用程序漫长的部署过程感到困扰？对于单个容器而言，体积超过GB级别显然并非最佳实践。每次发布新版本时都要传输数十亿字节的数据，这种低效的部署方式亟待改进。

本文将通过一个Node.js程序为例，展示几个简单的步骤来优化Docker镜像，使其体积更小、构建更快，从而更适用于生产环境。

简单的一段Node.js项目

首先，我们编写一个基于Express框架的简单Web服务器程序。

// package.json
{
  "name": "docker-test",
  "version": "1.0.0",
  "description": "",
  "main": "app.js",
  "scripts": {
    "start": "node app"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "express": "^4.16.4"
  },
  "devDependencies": {
    "eslint": "^5.16.0"
  }
}

// app.js
const express = require('express')
const app = express()
app.get('/', function(req, res){
  res.send('hello world')
})
app.listen(3000)

在项目根目录下新建Dockerfile，并写入以下配置代码。

# Dockerfile
FROM node
COPY . /home/app
RUN cd /home/app && npm install
WORKDIR /home/app
CMD ['npm', 'start']

执行构建命令。

• docker build -t myapp .
• docker images

执行上述命令后可以看到，这段最简单的Node.js程序生成的镜像体积高达920MB。请避免在生产环境中采用这种做法，接下来我们将逐步减少这个镜像的体积。

优化Docker生产环境镜像

使用Node.js Alpine镜像

大幅减小镜像体积最简单且高效的方法是选用体积更小的基础镜像。Alpine Linux是一个轻量级的Linux发行版，非常适合此场景。只要选择Node.js的Alpine版本，就能获得显著的体积缩减效果。

FROM node:alpine
COPY . /home/app
RUN cd /home/app && npm install
WORKDIR /home/app
CMD ['npm', 'start']

构建完成后的结果。

可以看到镜像体积整整减少了800MB，这是一个非常显著的优化成果。

生产环境下不打包开发依赖包

但我们仍有优化空间。当前配置安装了所有依赖项，即便最终运行只需生产环境依赖。如果只打包生产环境所需的依赖，体积会进一步减小，让我们继续改进。

FROM node:alpine
  COPY . /home/app
  RUN cd /home/app && npm install --production
  WORKDIR /home/app
  CMD ['npm', 'start']

再次构建后的结果。

我们又减少了6MB，因为目前我们只有一个开发依赖。可以想象，在一个正常规模的项目中，这种优化带来的体积缩减将更加巨大。

使用基础版本的Alpine镜像组合Node.js

如果我们直接使用基础版本的Alpine镜像，并手动安装Node.js，结果会如何呢？

FROM alpine:latest
  RUN apk add --no-cache --update nodejs nodejs-npm
  COPY . /home/app
  RUN cd /home/app && npm install --production
  WORKDIR /home/app
  CMD ['npm', 'start']

构建完成后的结果。

现在镜像体积仅剩65MB，相比初始状态已减少了10倍以上。

多阶段构建

• Docker镜像是分层的，Dockerfile中的每条指令都会创建一个新的镜像层。这些层可以被复用和缓存。当Dockerfile指令修改、复制的文件变化或构建变量不同时，对应的镜像层缓存会失效，且该层之后的所有缓存也会随之失效。
• 因此，我们可以合并RUN指令，但需注意，只能合并那些变化频率一致的指令。
• 应将变化最少的部分放在Dockerfile的前面，以充分利用镜像缓存机制。
• 通过最小化镜像层的数量，我们可以获得更小的最终镜像。

在上述示例中，源代码会频繁变化，导致每次构建镜像时都需要重新安装NPM模块，这显然不是我们期望的结果。因此，我们可以先拷贝package.json，然后安装NPM模块，最后再拷贝其余源代码。这样，即使源代码发生变化，也无需重新安装NPM模块。

FROM alpine AS builder
  WORKDIR /home/app
  RUN apk add --no-cache --update nodejs nodejs-npm
  COPY package.json package-lock.json ./
  RUN npm install --production

  FROM alpine
  WORKDIR /home/app
  RUN apk add --no-cache --update nodejs nodejs-npm
  COPY --from=builder /usr/src/app/node_modules ./node_modules
  COPY . .
  CMD [ 'npm', 'start' ]

最终镜像体积仅为51MB，相比初始状态大约减少了17倍！并且后续的构建速度也大幅提升。

每一条FROM指令代表一个构建阶段，多条FROM指令即构成多阶段构建。虽然最终生成的镜像仅包含最后一个阶段的结果，但可以将前置阶段中的文件拷贝到后续阶段中，这正是多阶段构建的核心价值。

在上面的Dockerfile文件中，我们先拷贝了package.json并执行npm install。在第二阶段构建时，直接拷贝了第一阶段已下载好的node_modules。在下一次构建时，如果没有新增依赖，Docker将使用缓存中的node_modules，从而减少了部署时间。

使用docker inspect imageId命令查看，虽然我们有多个指令，但最终镜像仅有5层，这就是层的共享机制。

使用多阶段构建可以充分利用Docker镜像的缓存，大大减少最终部署到生产环境的时间。

结论

在实际生产环境中，没有理由使用GB级别的镜像。如果你确实需要提高部署速度，并且被缓慢的CI/CD流程所困扰，那么多阶段构建将是一个非常有效的方法。

希望这篇简短的文章对考虑使用Docker进行基于Node.js的应用程序开发或部署的人有所帮助。

以上就是Node.js Docker镜像体积优化实践详解的详细内容，更多关于Node.js Docker镜像优化的资料请关注本站其它相关文章！