Node服務怎麼進行Docker鏡像化？極致優化詳解

這段時間在開發一個騰訊文檔全品類通用的HTML 動態服務，為了方便各品類接入的生成與部署，也順應上雲的趨勢，考慮使用Docker 的方式來固定服務內容，統一進行製品版本的管理。這篇文章就將我在服務 Docker 化的過程中累積起來的優化經驗分享出來，供大家參考。 【相關教學推薦：nodejs影片教學】

以範例開頭，大部分剛接觸Docker 的同學應該都會這樣寫專案的Dockerfile，如下所示：

FROM node:14
WORKDIR /app

COPY . .
# 安装 npm 依赖
RUN npm install

# 暴露端口
EXPOSE 8000

CMD ["npm", "start"]

構建，打包，上傳，一氣呵成。然後看下鏡像狀態，臥槽，一個簡單的node web 服務體積居然達到了驚人的1.3 個G，並且鏡像傳輸與構建速度也很慢：

要是這個鏡像只需要部署一個實例也就算了，但是這個服務得提供給所有開發同學進行高頻集成並部署環境的（實現高頻集成的方案可參見我的上一篇文章）。首先，鏡像體積過大必然會對鏡像的拉取和更新速度造成影響，整合體驗會變差。其次，專案上線後，同時在線的測試環境實例可能成千上萬，這樣的容器記憶體佔用成本對於任何一個項目都是無法接受的。必須找到優化的方法解決。

發現問題後，我就開始研究 Docker 的最佳化方案，準備給我的鏡像動手術了。

node 專案生產環境最佳化

首先開刀的是當然是前端最為熟悉的領域，對程式碼本身體積進行最佳化。之前開發專案時使用了 Typescript，為了圖省事，專案直接使用 tsc 打包產生 es5 後就直接運作起來了。這裡的體積問題主要有兩個，一個是開發環境 ts 原始碼並未處理，用於生產環境的 js 程式碼也未經壓縮。

另一個是引用的 node_modules 太臃腫。仍然包含了許多開發調試環境中的 npm 包，如 ts-node，typescript 等等。既然打包成 js 了，這些依賴自然就該去除。

一般來說，由於服務端程式碼不會像前端程式碼一樣暴露出去，運行在實體機上的服務更多考慮的是穩定性，也不在乎多一些體積，因此這些地方一般也不會做處理。但是 Docker 化後，由於部署規模變大，這些問題就非常明顯了，在生產環境下需要最佳化的。

對於這兩點的優化的方式其實我們前端非常熟悉了，不是本文的重點就粗略帶過了。第一點，使用 Webpack babel 降級並壓縮 Typescript 原始碼，如果擔心錯誤排查可以加上 sourcemap，不過對於 docker 映像來說有點多餘，一會兒會說到。對於第二點，梳理 npm 套件的 dependencies 與 devDependencies 依賴，移除不是必要存在於運行時的依賴，方便生產環境使用 npm install --production 安裝依賴。

優化專案映像體積

使用盡量精簡的基礎映像

我們知道，容器技術提供的是作業系統層級的進程隔離，Docker 容器本身就是一個運行在獨立作業系統下的進程，也就是說，Docker 映像需要打包的是一個能夠獨立運作的作業系統級環境。因此，決定鏡像體積的一個重要因素就顯而易見了：打包進鏡像的 Linux 作業系統的體積。

一般來說，減少依賴的作業系統的大小主要需要考慮從兩個方面下手，第一個是盡可能去除Linux 下不需要的各類工具庫，如python，cmake, telnet等。第二個是選取更輕量級的 Linux 發行版系統。正規的官方鏡像應該會依據上述兩個因素對每個發行版提供閹割版本。

以 node 官方提供的版本 node:14 為例，預設版本中，它的運作基礎環境是 Ubuntu，是一個大而全的 Linux 發行版，以保證最大的兼容性。移除了無用工具庫的依賴版本稱為 node:14-slim 版本。而最小的鏡像發行版稱為 node:14-alpine。 Linux alpine 是一個高度精簡，僅包含基本工具的輕量級 Linux 發行版，本身的 Docker 映像只有 4～5M 大小，因此非常適合製作最小版本的 Docker 映像。

在我們的服務中，由於運行該服務的依賴是確定的，因此為了盡可能的縮減基礎鏡像的體積，我們選擇 alpine 版本作為生產環境的基礎鏡像。

分级构建

这时候，我们遇到了新的问题。由于 alpine 的基本工具库过于简陋，而像 webpack 这样的打包工具背后可能使用的插件库极多，构建项目时对环境的依赖较大。并且这些工具库只有编译时需要用到，在运行时是可以去除的。对于这种情况，我们可以利用 Docker 的分级构建的特性来解决这一问题。

首先，我们可以在完整版镜像下进行依赖安装，并给该任务设立一个别名（此处为build)。

# 安装完整依赖并构建产物
FROM node:14 AS build
WORKDIR /app

COPY package*.json /app/
RUN ["npm", "install"]
COPY . /app/

RUN npm run build

之后我们可以启用另一个镜像任务来运行生产环境，生产的基础镜像就可以换成 alpine 版本了。其中编译完成后的源码可以通过--from参数获取到处于build任务中的文件，移动到此任务内。

FROM node:14-alpine AS release
WORKDIR /release

COPY package*.json /
RUN ["npm", "install", "--registry=http://r.tnpm.oa.com", "--production"]

# 移入依赖与源码
COPY public /release/public
COPY --from=build /app/dist /release/dist

# 启动服务
EXPOSE 8000

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

Docker 镜像的生成规则是，生成镜像的结果仅以最后一个镜像任务为准。因此前面的任务并不会占用最终镜像的体积，从而完美解决这一问题。

当然，随着项目越来越复杂，在运行时仍可能会遇到工具库报错，如果曝出问题的工具库所需依赖不多，我们可以自行补充所需的依赖，这样的镜像体积仍然能保持较小的水平。

其中最常见的问题就是对node-gyp与node-sass库的引用。由于这个库是用来将其他语言编写的模块转译为 node 模块，因此，我们需要手动增加g++ make python这三个依赖。

# 安装生产环境依赖（为兼容 node-gyp 所需环境需要对 alpine 进行改造）
FROM node:14-alpine AS dependencies

RUN apk add --no-cache python make g++
COPY package*.json /
RUN ["npm", "install", "--registry=http://r.tnpm.oa.com", "--production"]
RUN apk del .gyp

详情可见：https://github.com/nodejs/docker-node/issues/282

合理规划 Docker Layer

构建速度优化

我们知道，Docker 使用 Layer 概念来创建与组织镜像，Dockerfile 的每条指令都会产生一个新的文件层，每层都包含执行命令前后的状态之间镜像的文件系统更改，文件层越多，镜像体积就越大。而 Docker 使用缓存方式实现了构建速度的提升。若 Dockerfile 中某层的语句及依赖未更改，则该层重建时可以直接复用本地缓存。

如下所示，如果 log 中出现Using cache字样时，说明缓存生效了，该层将不会执行运算，直接拿原缓存作为该层的输出结果。

Step 2/3 : npm install
 ---> Using cache
 ---> efvbf79sd1eb

通过研究 Docker 缓存算法，发现在 Docker 构建过程中，如果某层无法应用缓存，则依赖此步的后续层都不能从缓存加载。例如下面这个例子：

COPY . .
RUN npm install

此时如果我们更改了仓库的任意一个文件，此时因为npm install层的上层依赖变更了，哪怕依赖没有进行任何变动，缓存也不会被复用。

因此，若想尽可能的利用上npm install层缓存，我们可以把 Dockerfile 改成这样：

COPY package*.json .
RUN npm install
COPY src .

这样在仅变更源码时，node_modules的依赖缓存仍然能被利用上了。

由此，我们得到了优化原则：

• 最小化处理变更文件，仅变更下一步所需的文件，以尽可能减少构建过程中的缓存失效。

• 对于处理文件变更的 ADD 命令、COPY 命令，尽量延迟执行。

构建体积优化

在保证速度的前提下，体积优化也是我们需要去考虑的。这里我们需要考虑的有三点：

• Docker 是以层为单位上传镜像仓库的，这样也能最大化的利用缓存的能力。因此，执行结果很少变化的命令需要抽出来单独成层，如上面提到的npm install的例子里，也用到了这方面的思想。

• 如果镜像层数越少，总上传体积就越小。因此，在命令处于执行链尾部，即不会对其他层缓存产生影响的情况下，尽量合并命令，从而减少缓存体积。例如，设置环境变量和清理无用文件的指令，它们的输出都是不会被使用的，因此可以将这些命令合并为一行 RUN 命令。

RUN set ENV=prod && rm -rf ./trash

3. Docker cache 的下载也是通过层缓存的方式，因此为了减少镜像的传输下载时间，我们最好使用固定的物理机器来进行构建。例如在流水线中指定专用宿主机，能是的镜像的准备时间大大减少。

当然，时间和空间的优化从来就没有两全其美的办法，这一点需要我们在设计 Dockerfile 时，对 Docker Layer 层数做出权衡。例如为了时间优化，需要我们拆分文件的复制等操作，而这一点会导致层数增多，略微增加空间。

这里我的建议是，优先保证构建时间，其次在不影响时间的情况下，尽可能的缩小构建缓存体积。

以 Docker 的思维管理服务

避免使用进程守护

我们编写传统的后台服务时，总是会使用例如 pm2、forever 等等进程守护程序，以保证服务在意外崩溃时能被监测到并自动重启。但这一点在 Docker 下非但没有益处，还带来了额外的不稳定因素。

首先，Docker 本身就是一个流程管理器，因此，进程守护程序提供的崩溃重启，日志记录等等工作 Docker 本身或是基于 Docker 的编排程序（如 kubernetes）就能提供了，无需使用额外应用实现。除此之外，由于守护进程的特性，将不可避免的对于以下的情况产生影响：

• 增加进程守护程序会使得占用的内存增多，镜像体积也会相应增大。

• 由于守护进程一直能正常运行，服务发生故障时，Docker 自身的重启策略将不会生效，Docker 日志里将不会记录崩溃信息，排障溯源困难。

• 由于多了个进程的加入，Docker 提供的 CPU、内存等监控指标将变得不准确。

因此，尽管 pm2 这样的进程守护程序提供了能够适配 Docker 的版本：pm2-runtime，但我仍然不推荐大家使用进程守护程序。

其实这一点其实是源自于我们的固有思想而犯下的错误。在服务上云的过程中，难点其实不仅仅在于写法与架构上的调整，开发思路的转变才是最重要的，我们会在上云的过程中更加深刻体会到这一点。

日志的持久化存储

无论是为了排障还是审计的需要，后台服务总是需要日志能力。按照以往的思路，我们将日志分好类后，统一写入某个目录下的日志文件即可。但是在 Docker 中，任何本地文件都不是持久化的，会随着容器的生命周期结束而销毁。因此，我们需要将日志的存储跳出容器之外。

最简单的做法是利用 Docker Manager Volume，这个特性能绕过容器自身的文件系统，直接将数据写到宿主物理机器上。具体用法如下：

docker run -d -it --name=app -v /app/log:/usr/share/log app

运行 docker 时，通过-v 参数为容器绑定 volumes，将宿主机上的 /app/log 目录（如果没有会自动创建）挂载到容器的 /usr/share/log 中。这样服务在将日志写入该文件夹时，就能持久化存储在宿主机上，不随着 docker 的销毁而丢失了。

当然，当部署集群变多后，物理宿主机上的日志也会变得难以管理。此时就需要一个服务编排系统来统一管理了。从单纯管理日志的角度出发，我们可以进行网络上报，给到云日志服务（如腾讯云 CLS）托管。或者干脆将容器进行批量管理，例如Kubernetes这样的容器编排系统，这样日志作为其中的一个模块自然也能得到妥善保管了。这样的方法很多，就不多加赘述了。

k8s 服务控制器的选择

镜像优化之外，服务编排以及控制部署的负载形式对性能的影响也很大。这里以最流行的Kubernetes的两种控制器（Controller）：Deployment 与 StatefulSet 为例，简要比较一下这两类组织形式，帮助选择出最适合服务的 Controller。

StatefulSet是 K8S 在 1.5 版本后引入的 Controller，主要特点为：能够实现 pod 间的有序部署、更新和销毁。那么我们的制品是否需要使用 StatefulSet 做 pod 管理呢？官方简要概括为一句话：

Deployment 用于部署无状态服务，StatefulSet 用来部署有状态服务。

这句话十分精确，但不易于理解。那么，什么是无状态呢？在我看来，StatefulSet的特点可以从如下几个步骤进行理解：

• StatefulSet管理的多个 pod 之间进行部署，更新，删除操作时能够按照固定顺序依次进行。适用于多服务之间有依赖的情况，如先启动数据库服务再开启查询服务。

• 由于 pod 之间有依赖关系，因此每个 pod 提供的服务必定不同，所以 StatefulSet 管理的 pod 之间没有负载均衡的能力。

• 又因为 pod 提供的服务不同，所以每个 pod 都会有自己独立的存储空间，pod 间不共享。

• 为了保证 pod 部署更新时顺序，必须固定 pod 的名称，因此不像 Deployment 那样生成的 pod 名称后会带一串随机数。

• 而由於pod 名稱固定，因此跟StatefulSet 對接的Service 中可以直接以pod 名稱作為存取域名，而不需要提供 Cluster IP，因此跟隨StatefulSet 對接的Service 被稱為Headless Service。

透過這裡我們就應該明白，如果在k8s 上部署的是單一服務，或是多服務間沒有依賴關係，那麼Deployment 一定是簡單而又效果最佳的選擇，自動調度，自動負載平衡。而如果服務的啟動停止必須滿足一定順序，或是每一個 pod 所掛載的資料 volume 需要在銷毀後依然存在，那麼建議選擇 StatefulSet。

本著如無必要，勿增實體的原則，強烈建議所有執行單一服務工作負載採用 Deployment 作為 Controller。

寫在結尾

一通研究下來，差點把一開始的目標忘了，趕緊將 Docker 重新建構一遍，看看優化成果。

可以看到，對於鏡像體積的最佳化效果還是不錯的，達到了 10 倍左右。當然，如果專案中不需要如此高版本的 node 支持，還能進一步縮小大約一半的鏡像體積。

之後鏡像倉庫會對存放的鏡像檔案做一次壓縮，以 node14 打包的鏡像版本最終被壓縮到了 50M 以內。

當然，除了看得到的體積資料之外，更重要的最佳化其實在於，從實體機導向的服務到容器化雲端服務在架構設計層面上的轉變。

容器化已經是看得見的未來，作為一名開發人員，要時刻保持對前沿技術的敏感，積極實踐，才能將技術轉化為生產力，為專案的進化做出貢獻。

更多node相關知識，請造訪：nodejs 教學！

以上是Node服務怎麼進行Docker鏡像化？極致優化詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章！