背景

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

現(xiàn)狀

Dockerfile是長(zhǎng)這樣子的：

Dockfile文件分析

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

一、基礎(chǔ)鏡像選擇

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

二、依賴安裝階段（deps）

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

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

• 將package.json、yarn.lock*、package - lock.json*、pnpm - lock.yaml*復(fù)制到當(dāng)前工作目錄（/app）。

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

三、構(gòu)建階段（builder）

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

• 從deps鏡像復(fù)制/app/node_modules到當(dāng)前工作目錄下的node_modules。

• 復(fù)制當(dāng)前目錄（.）下的所有文件到/app。

• 執(zhí)行yarn build:test，可能是使用Yarn構(gòu)建測(cè)試版本的項(xiàng)目。

四、運(yùn)行階段（runner）

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

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

• 從builder鏡像復(fù)制/app/public到當(dāng)前工作目錄下的public。

• 從builder鏡像復(fù)制/app/.next/standalone到當(dāng)前工作目錄下

• 從builder鏡像復(fù)制/app/.app/.next/static到當(dāng)前工作目錄下的.next/static

構(gòu)建鏡像

通過(guò)運(yùn)行Docker build的命令，我們可以看著在構(gòu)建鏡像的過(guò)程中，主要做了什么操作，每個(gè)操作耗時(shí)分別是多少：

可以看出，Docker鏡像打包過(guò)程總共花費(fèi)了614.6s，主要耗時(shí)集中在以下幾個(gè)操作上：

• [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)化

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

• 使用更小的基礎(chǔ)鏡像

• 多階段構(gòu)建（Multi-stage Builds）

• 利用緩存加速構(gòu)建

• 減少鏡像層數(shù)

• 使用.dockerignore文件

• 分層打包（Layered Packaging）

• 靜態(tài)二進(jìn)制文件和“臨時(shí)”基礎(chǔ)映像

因?yàn)楫?dāng)前的項(xiàng)目已經(jīng)做了1、2、6，所以我們還可以從4、5、7這三個(gè)方面考慮。

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

• 通過(guò)添加.dockerignore文件，過(guò)濾掉一些非必要的文件，來(lái)減少文件復(fù)制的時(shí)間。

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

基于以上兩點(diǎn)，對(duì)項(xiàng)目文件以及Dockerfile進(jìn)行修改.

一、添加.dockerignore文件

內(nèi)容如下：

node_modules
.next
src/.DS_Store
.vscode
.husky

二、Dockerfile調(diào)整

三、構(gòu)建看效果

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

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

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

一、Dockerfile調(diào)整

二、構(gòu)建效果

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

• [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

總結(jié)

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

其他

中間嘗試還進(jìn)行了npm包的下載速度優(yōu)化，因?yàn)檫@個(gè)改動(dòng)相對(duì)來(lái)說(shuō)也比較小。配置國(guó)內(nèi)的npm源，速度確實(shí)會(huì)提升不少，如果公司內(nèi)部搭建有完整的私有npm倉(cāng)庫(kù)，那速度將會(huì)大大提升。

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

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

最新評(píng)論