Nodejs Docker 鏡像體積優化實踐

你討厭部署你的應用程序花費很長時間嗎? 對於單個容器來講,超過gb並非最佳實踐。每次部署新版本時都要處理數十億字節,這對咱們來講並不太合適。node

本文將經過Nodejs程序展現如何優化Docker鏡像的幾個簡單步驟,使它們更小、更快、更適合生產環境。git

簡單的一段Node.js項目

首先寫一段基於express的簡單web服務器程序github

// 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並寫入如下代碼web

# Dockerfile
FROM node

COPY . /home/app 
RUN cd /home/app && npm install 
WORKDIR /home/app 
CMD ['npm', 'start'] 複製代碼

執行面試

  • docker build -t myapp .
  • docker images

結果

能夠看到這段最簡單的nodejs程序有920MB,請不要這樣作。接下來咱們將逐步的減小這個鏡像的體積。docker

優化docker生產環境鏡像

  • 使用Node.js Alpine 鏡像

    大幅減少鏡像體積的最簡單和最快的方法是選擇一個小得多的基本鏡像。Alpine是一個很小的Linux發行版,能夠完成這項工做。只要選擇Node.js的Alpine版本,就會有很大的改進。express

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

    build以後 npm

    結果

    能夠看到整整減小了800MB,這是一個很是大的優化。json

  • 生成環境下不打包開發的依賴包

    但咱們還能繼續優化。咱們正在安裝全部依賴項,即便咱們最終只須要生成環境下的依賴包。若是隻打包生產環境的以來不會怎麼樣,繼續改進一下。緩存

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

    build以後

    結果

    咱們又減小了6MB,由於咱們目前只有一個開發依賴,能夠想象在一個正常的項目中這也將是很是大的優化。

  • 使用基礎版本的 Alpine 鏡像組合Nodejs

    若是咱們使用基礎版本的 Alpine 鏡像,而後本身安裝Nodejs結果會怎麼樣呢?

    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'] 複製代碼

    build以後

    結果

    如今只剩下了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倍!而且後續的 build 速度也大大提高。

每一條 FROM 指令都是一個構建階段,多條 FROM 就是多階段構建,雖然最後生成的鏡像只能是最後一個階段的結果,可是,可以將前置階段中的文件拷貝到後邊的階段中,這就是多階段構建的最大意義。

在上面的Dockerfile文件中,咱們先 copy 了package.json,而後 npm install,在第二階段構建時,咱們直接 copy 了第一階段已經下載好的node_moduls,在下一次 build 時,若是沒有新增依賴,docker將使用緩存中的node_modules,這樣就減小了部署的時間。

使用 docker inspect imageId命令 咱們能夠看到,雖然咱們有多個指令,可是最終的鏡像也只有5層,這就是層的共享機制。

使用多階段構建能夠充分利用Docker鏡像的緩存,大大減小最終部署到生產環境的時間。

結論

在實際生產環境中,沒有任何理由使用gb大小的鏡像,若是你確實須要提升部署速度,而且被緩慢的CI/CD所困擾,那麼多階段構建將會是一個很是有幫助的方法

但願這篇簡短的文章對考慮使用Docker進行基於Node.js的應用程序開發或部署的人有些許幫助。

查看原文

關注github每日一道面試題詳解

相關文章
相關標籤/搜索