背景

在最近臨時支持的項目中，發(fā)現(xiàn)項目的構建流程耗時比較長，嚴重的影響了開發(fā)的進度。參照文檔要發(fā)測試環(huán)境的時候，發(fā)現(xiàn)10分鐘過去了還沒有發(fā)布完成。項目是通過Docker來構建鏡像部署的，所以想看看有沒有什么方案，可以對Docker鏡像構建進行優(yōu)化。

現(xiàn)狀

Dockerfile是長這樣子的：

Dockfile文件分析

以下主要分析Dockerfile構建過程中主要執(zhí)行的操作

一、基礎鏡像選擇

首先定義了一個基礎鏡像FROM node:20.18.1-alpine AS base，這里選擇了基于Alpine系統(tǒng)的Node.js版本20.18.1作為基礎鏡像。

二、依賴安裝階段（deps）

• 基于base鏡像創(chuàng)建了deps鏡像。

• 執(zhí)行RUN apk add --no - cache libc6 - compat，這是在Alpine系統(tǒng)下安裝libc6 - compat庫，--no - cache表示不使用緩存。

• 將package.json、yarn.lock*、package - lock.json*、pnpm - lock.yaml*復制到當前工作目錄（/app）。

• 根據(jù)不同的lock文件類型進行依賴安裝：如果存在yarn.lock文件，執(zhí)行yarn --frozen - lockfile，這是使用Yarn安裝依賴并且確保使用lock文件中的版本，以保證可重復性。如果存在package - lock.json文件，執(zhí)行npm ci，這是使用npm安裝依賴并且確保按照package - lock.json中的版本精確安裝。如果存在pnpm - lock.yaml文件，先全局安裝pnpm（yarn global add pnpm），然后執(zhí)行pnpm i --frozen - lockfile，同樣是按照lock文件安裝依賴。如果沒有找到任何lock文件，則輸出Lockfile not found.并以錯誤碼1退出。

三、構建階段（builder）

• 基于base鏡像創(chuàng)建builder鏡像。

• 從deps鏡像復制/app/node_modules到當前工作目錄下的node_modules。

• 復制當前目錄（.）下的所有文件到/app。

• 執(zhí)行yarn build:test，可能是使用Yarn構建測試版本的項目。

四、運行階段（runner）

• 基于base鏡像創(chuàng)建runner鏡像。

• 設置環(huán)境變量NODE_ENV為production，表示生產(chǎn)環(huán)境。

• 從builder鏡像復制/app/public到當前工作目錄下的public。

• 從builder鏡像復制/app/.next/standalone到當前工作目錄下

• 從builder鏡像復制/app/.app/.next/static到當前工作目錄下的.next/static

構建鏡像

通過運行Docker build的命令，我們可以看著在構建鏡像的過程中，主要做了什么操作，每個操作耗時分別是多少：

可以看出，Docker鏡像打包過程總共花費了614.6s，主要耗時集中在以下幾個操作上：

• [internal] load metadata for docker.io/library/node:20.18.1-alpine: 4.4s

• => [internal] load build context: 23.8s

• => transferring context: 712.33MB: 23.8s

• => [deps 1/4] RUN apk add --no-cache libc6-compat: 3.0s

• => [deps 4/4] RUN if [ -f yarn.lock ]; then yarn --frozen-lockfile; elif [ -f package-lock.json ]; then npm ci; eli : 258.1s

• => [builder 2/4] COPY --from=deps /app/node_modules ./node_modules: 35.9s

• => [builder 3/4] COPY . .: 4.7s

• => [builder 4/4] RUN yarn build:test: 234.2s

優(yōu)化

之前沒有太多的Docker鏡像打包經(jīng)驗，都是直接build寫好的Dockerfile或者是基于開源的Dockerfile進行定制化開發(fā)（復制其他項目的拿過來改一下??），所以搜了一下看看都有哪些優(yōu)化的方案。單純從Docker鏡像打包來看，可以從以下幾個方向入手：

• 使用更小的基礎鏡像

• 多階段構建（Multi-stage Builds）

• 利用緩存加速構建

• 減少鏡像層數(shù)

• 使用.dockerignore文件

• 分層打包（Layered Packaging）

• 靜態(tài)二進制文件和“臨時”基礎映像

因為當前的項目已經(jīng)做了1、2、6，所以我們還可以從4、5、7這三個方面考慮。

優(yōu)化一：減少文件復制的時間

• 通過添加.dockerignore文件，過濾掉一些非必要的文件，來減少文件復制的時間。

• 我們看到之前的Dockerfile里，有一個復制node_modules的操作，花費了35.9s，可以想辦法把這個去掉。

基于以上兩點，對項目文件以及Dockerfile進行修改.

一、添加.dockerignore文件

內(nèi)容如下：

node_modules
.next
src/.DS_Store
.vscode
.husky

二、Dockerfile調(diào)整

三、構建看效果

我們可以看到，=> [builder 3/4] COPY . .從 4.7s 降到了 1.8s， => [builder 2/4] COPY --from=deps /app/node_modules ./node_modules 這一步的耗時已經(jīng)沒有了。

優(yōu)化二：重新構建一個新的鏡像作為基礎鏡像

通過觀察Dockerfile，我們發(fā)現(xiàn)以node:20.18.1-alpine鏡像為基礎鏡像進行構建的時候，還需要安裝libc6-compat，受網(wǎng)絡波動的影響libc6-compat有時候下載比較慢。那我們可以把在node:20.18.1-alpine環(huán)境下，下載好libc6-compat單獨打包成一個鏡像，上傳到公司內(nèi)部的鏡像倉庫中，直接使用這個新鏡像來作為基礎鏡像就可以了。如何構建鏡像上傳到公司內(nèi)部鏡像倉庫，大家可以去看看Docker的教程就可以了，這里就不展開了。

一、Dockerfile調(diào)整

二、構建效果

我們可以看到通過構建一個新的鏡像上傳到內(nèi)部鏡像倉庫中使用，不僅鏡像下載速度變快了，還可以節(jié)省下了 => [deps 1/4] RUN apk add --no-cache libc6-compat下載的時間。

• [internal] load metadata for docker.io/library/node:20.18.1-alpine: 4.4s => 0.7s

• => [internal] load build context: 23.8s => 11.3s

• => transferring context: 712.33MB: 23.8s => 9.9s

• => [deps 1/4] RUN apk add --no-cache libc6-compat: 3.0s => 0s

總結

由于是臨時支持了這個項目，在對項目改動不大的情況下去進行了一些嘗試，而且僅針對Docker鏡像自身構建的優(yōu)化。通過這次實踐來看，這個項目單純從Docker方面來進行優(yōu)化，效果相對來說還是不夠的，減少了70s左右的時間。整個構建耗時的流程還是在安裝依賴以及項目本身的構建上，如果要想顯著的提高項目發(fā)布速度，還得從這兩方面入手。

其他

中間嘗試還進行了npm包的下載速度優(yōu)化，因為這個改動相對來說也比較小。配置國內(nèi)的npm源，速度確實會提升不少，如果公司內(nèi)部搭建有完整的私有npm倉庫，那速度將會大大提升。

還有另外一種方案，就是利用Docker 多階段構建來對依賴進行分批下載，下載完成之后再合并到一起進行打包構建，這樣子也許可以節(jié)省一些時間。

到此這篇關于Docker鏡像構建速度優(yōu)化實現(xiàn)的文章就介紹到這了,更多相關Docker鏡像構建速度內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論