選擇一個(gè)Node的Docker映像看起來像是一件小事，但是映像的大小和潛在漏洞可能會(huì)對(duì)你的CI/CD流程和安全造成重大的影響。那我們要如何選擇一個(gè)最好Node.js Docker映像呢？

我們在使用FROM node:latest或只是FROM node時(shí)，很容易忽略他潛在的風(fēng)險(xiǎn)。如果你不知道整體的安全風(fēng)險(xiǎn)並且把他引入了CI/CD的流程中，那無疑是加劇了這個(gè)風(fēng)險(xiǎn)。 【相關(guān)教學(xué)推薦：nodejs影片教學(xué)、程式設(shè)計(jì)教學(xué)】

#下面這個(gè)範(fàn)例非常典型，你可以從很多教學(xué)或部落格文章看到這個(gè)Node. js Dockerfile的配置。 但是這個(gè)Dockerfile的配置存在很大的問題，非常不推薦這樣使用：

FROM node
WORKDIR /usr/src/app
COPY . /usr/src/app
RUN npm install
CMD "npm" "start"

譯者註：如果需要跳過分析直接看結(jié)論，請直接滑到文末。

一個(gè)可供選擇Node.js Docker映像

當(dāng)你建立一個(gè)Node.js映像的時(shí)候，其實(shí)有很多選擇。其中就包含了Node.js核心團(tuán)隊(duì)維護(hù)的官方Docker映像，以及從特定的基礎(chǔ)映像中選取的特殊Node.js映像版本。還可以選擇其他的，例如穀歌在distroless專案上構(gòu)建的Node.js應(yīng)用程序，或者是Docker官方團(tuán)隊(duì)提供的一個(gè)名為scratch的鏡像。

在這些Node.js的Docker映像中，哪一個(gè)是最適合你的呢？

讓我們一個(gè)一個(gè)的去分析，了解更多他們的好處和潛在風(fēng)險(xiǎn)。

作者註：在這篇文章中，我將會(huì)比較18.2.0這個(gè)版本的Node.js鏡像，他的發(fā)佈時(shí)間是2022年6月左右。

預(yù)設(shè)的Node.js映像

我們先從維護(hù)的node映像開始。它是由進(jìn)行正式地維護(hù)的，包含了一些基礎(chǔ)的鏡像tag。這些tag對(duì)應(yīng)到不同的底層發(fā)行版（Debian、Ubuntu、Alpine）以及不同版本的Node.js運(yùn)行時(shí)本身。還有針對(duì)不同CPU架構(gòu)的特定版本tag，例如amd64和arm64x8（新版蘋果的M1）。

Debian發(fā)行版中最常見的node鏡像，例如bullseye或buster，他們都是基於由另一個(gè)團(tuán)隊(duì)維護(hù)的buildpack-deps的。
當(dāng)你基於這個(gè)預(yù)設(shè)的node映像建立Node.js Docker映像時(shí)會(huì)發(fā)生什麼事？

FROM node

使用docker build --no-cache -f Dockerfile1 -t dockerfile1建構(gòu)映像時(shí)，就會(huì)出現(xiàn)下面這些：

• #我們沒有指定Node .js運(yùn)行時(shí)版本，所以node是node:last的一個(gè)別名，他的版本指向的是18.2.0
##這個(gè)Node.js Docker映像大小是952MB

這個(gè)最新的Node.js映像的依賴和安全漏洞足跡是什麼？我們可以用

docker scan dockerfile1來運(yùn)行一個(gè)Synk-powered容器，就會(huì)得到下面的結(jié)果：

共有409個(gè)依賴項(xiàng)- 這些是使用作業(yè)系統(tǒng)套件管理員偵測到的開源程式庫，例如
• curl/libcurl4、git/git-man、imagemagick/imagemagick-6-common。
共有289個(gè)安全問題在這些依賴中被發(fā)現(xiàn)，例如，
• Buffer Overflows、use-after-free errors、out-of-bounds write等。
Node.js 18.2.0運(yùn)行時(shí)版本容易出現(xiàn)7個(gè)安全問題。例如，
• DNS Rebinding、HTTP Request Smuggling、Configuration Hijacking

##譯者註：

• Buffer Overflows - 緩沖區(qū)溢出
• Use After Free - 一種內(nèi)存破壞漏洞，通常存在于瀏覽器中
• out-of-bounds write - 越界寫入
• DNS Rebinding - DNS重綁定攻擊
• HTTP Request Smugglin - HTTP請求夾帶攻擊技術(shù)
• Configuration Hijacking - 配置劫持

你真的需要在Node.js鏡像中給你的應(yīng)用提供wget、git、curl嗎？在Node.js Docker鏡像中，有成百上千個(gè)依賴和工具，而這些依賴又對(duì)應(yīng)著成百上千個(gè)漏洞。Node.js運(yùn)行時(shí)的特性對(duì)應(yīng)著7個(gè)不同的安全漏洞，給潛在攻擊留下了很大的空間?？偟膩碚f，情況并不是很樂觀。

Node.js Docker Hub選項(xiàng)node:buster vs node:bullseye

如果你在Node.js Docker Hub倉庫上瀏覽可用tags，你將會(huì)發(fā)現(xiàn)有兩個(gè)Node.js鏡像tags - node:buster和node:bullseye。

這兩個(gè)Docker鏡像tags都基于Debian發(fā)行版。buster鏡像tag對(duì)應(yīng)著Debian10，將會(huì)在2022年8月到2024年進(jìn)入到他的End of Life日期，所以buster不是一個(gè)很好的選擇。bullseye鏡像tag對(duì)應(yīng)著Debian11，被當(dāng)做Debian的當(dāng)前穩(wěn)定版本，預(yù)計(jì)EOL日期為2026年6月。

譯者注：

• End of Life。特指產(chǎn)品壽命的結(jié)束，通常縮寫為EOL。

因此，十分建議你將所有新的和現(xiàn)有的Node.js Docker鏡像從node:buster遷移到node:bullseye或者其他合適的可替代版本。
我們先構(gòu)建一個(gè)新的Node.js Docker鏡像基于：

FROM node:bullseye復(fù)制代碼

如果你構(gòu)建了這個(gè)Node.js Docker鏡像tag并且與之前使用node:latest的結(jié)果進(jìn)行比較，將會(huì)得到完全相同的大小、依賴數(shù)量和發(fā)現(xiàn)的漏洞。原因是node、node:latest、node:bullseye全部指向了同一個(gè)正在構(gòu)建的Node.js鏡像tag。

Node.js鏡像tag瘦身

官方的Node.js團(tuán)隊(duì)還維護(hù)了一個(gè)顯式地針對(duì)功能性Node.js環(huán)境所需工具的鏡像tag并且不會(huì)存在其他的東西。

這個(gè)Node.js鏡像tags是通過slim鏡像tag變量來引用的，比如node:bullseye-slim，或者帶有Node.js指定版本，像node:14.19.2 -slim。

我們再來基于Debian的當(dāng)前穩(wěn)定版本的bullseye構(gòu)建一個(gè)Node.jsslim鏡像：

FROM node:bullseye-slim

• 鏡像的大小已經(jīng)急劇下降，從接近1GB的容器鏡像降到246MB的鏡像大小
• 掃描他的內(nèi)容也顯示了整體軟件足跡的大幅下降，只有97個(gè)依賴項(xiàng)和56個(gè)漏洞。

就容器鏡像大小和安全狀況而言，node:bullseye-slim已經(jīng)是一個(gè)比較好的起點(diǎn)了。

一個(gè)LTS的Node.js Docker鏡像

到目前為止，我們的Node.js Docker鏡像基于當(dāng)前版本的Node.js，即Node.js18。但是根據(jù)Node.js的發(fā)布時(shí)間表，這個(gè)版本直到2022年10月才進(jìn)入正式的Active LTS狀態(tài)。

譯者注：LTS - Long-term support，即長期支持版本。

如果我們總是依賴于我們正在構(gòu)建的Node.js Docker鏡像中的LTS版本的話會(huì)怎么樣？我們先更新這個(gè)Docker鏡像tag并構(gòu)建一個(gè)新的Node.js鏡像：

FROM node:lts-bullseye-slim

瘦身后的Node.js LTS版本（16.15.0）在鏡像上帶來了相似數(shù)量的依賴、安全漏洞和一個(gè)略小的體積（188MB）。

因此，盡管你可能需要在LTS和當(dāng)前Node.js運(yùn)行時(shí)版本中選擇，但他們都不會(huì)對(duì)Node.js鏡像的軟件占用空間有大的影響。

node:alpine對(duì)于Node.js鏡像來說是一個(gè)更好的選擇嗎？

Node.js Docker團(tuán)隊(duì)維護(hù)了一個(gè)node:alpine鏡像tag以及他的變體，以便將Alpine Linux發(fā)行版的特定版本與Node.js運(yùn)行時(shí)的特定版本進(jìn)行匹配。

Alpine Linux項(xiàng)目經(jīng)常因?yàn)槠浞浅Ｐ〉溺R像體積而被引用，小體積意味著更新的軟件占用空間和更少的漏洞，確實(shí)十分不錯(cuò)。
下面的命令會(huì)讓Dockerfile去生成一個(gè)node環(huán)境，這個(gè)將會(huì)增加未壓縮的鏡像體積：

FROM node:alpine

這個(gè)將會(huì)產(chǎn)生一個(gè)178MB大小的docker鏡像，和slimNode.js鏡像大小差不多，但是在alpine鏡像tag中，只檢測到了16個(gè)系統(tǒng)依賴漏洞和2個(gè)安全安全漏洞。這就意味著alpine鏡像tag對(duì)于小體積和漏洞數(shù)量來說是一個(gè)比較好的選擇。

alpine對(duì)Node.js鏡像可能提供了一個(gè)較小的鏡像體積和更少的漏洞數(shù)量。但是，我們必須意識(shí)到Alpine項(xiàng)目使用musl作為C標(biāo)準(zhǔn)庫的實(shí)現(xiàn)。而Debian的Node.js鏡像tag依賴于glibc實(shí)現(xiàn)，比如bullseye和slim。這些差異可以解釋性能問題、功能性的bug或者是潛在的應(yīng)用程序崩潰，這些都是由于底層C庫的差異造成的。

選擇一個(gè)alpine的Node.js鏡像tag意味著你實(shí)際上是在選擇一個(gè)非官方的Node.js運(yùn)行時(shí)。Node.js Docker團(tuán)隊(duì)并不會(huì)正式支持基于alpine的容器鏡像構(gòu)建。因此，他聲明基于Alpine的鏡像tag是實(shí)驗(yàn)性的，并且可能和官方的構(gòu)建不一致。

如果你正在選一個(gè)一個(gè)基于Alpine的Node.js Docker鏡像，需要記住一點(diǎn)，Docker安全工具（例如Trivy或Snyk）目前無法檢測到Alpine鏡像中與運(yùn)行時(shí)相關(guān)的漏洞的。雖然這種情況未來可能會(huì)改變，但是目前還不能找到Node.js18.2.0alpine基礎(chǔ)鏡像tag的安全漏洞，而18.2.0運(yùn)行時(shí)本身實(shí)際上是容易受到攻擊的。這與安全工具本身有關(guān)，而不是與Alpine基礎(chǔ)鏡像有關(guān)，但是也應(yīng)該考慮到這一點(diǎn)。

Node.js的distroless（無損）Docker鏡像

我們的基準(zhǔn)測試的最后一個(gè)比較項(xiàng)目是谷歌的Distroless容器鏡像。

什么是distroless容器鏡像?

這種鏡像甚至比slim的Node.js鏡像更加小，因?yàn)?code>distroless鏡像只針對(duì)這個(gè)應(yīng)用和應(yīng)用運(yùn)行時(shí)的依賴性而已。因此，一個(gè)distroless的docker鏡像沒有容器包管理器、shell、或者其他通用工具的依賴性，這使得它們的體積更小，漏洞也更少。

幸運(yùn)的是，Distroless項(xiàng)目為Node.js維護(hù)了一個(gè)特殊運(yùn)行時(shí)的distrolessdocker鏡像，通過其完整的命名空間識(shí)別為grc.io/distroless/nodejs-debian11，并且可以在谷歌的容器注冊表中找到（這個(gè)是gcr.io的部分）。

因?yàn)镈istroless容器鏡像沒有軟件，我們可以使用一個(gè)docker的多階段工作流來為我們的容器安裝依賴項(xiàng)，并且把它們復(fù)制到Distroless鏡像：

FROM node:16-bullseye-slim AS build
WORKDIR /usr/src/app
COPY . /usr/src/app
RUN npm install

FROM gcr.io/distroless/nodejs:16
COPY --from=build /usr/src/app /usr/src/app
WORKDIR /usr/src/app
CMD ["server.js"]

構(gòu)建這個(gè)distrolessdocker鏡像將產(chǎn)生112MB的文件，而在slim和alpine鏡像tag來說，這已經(jīng)減小了很多文件的體積了。
如果你正在考慮使用distrolessdocker鏡像，有一些重要的事項(xiàng)需要注意：

• 好的一點(diǎn)是，它們是基于當(dāng)前穩(wěn)定的Debian發(fā)行版本，這意味著它們是最新的，很久才會(huì)到EOL的日期。
• 因?yàn)樗鼈兪腔贒ebian的，所以它們依賴glibc實(shí)現(xiàn)，并且不太可能在生產(chǎn)環(huán)境出現(xiàn)一些奇怪的問題。
• 你很快就會(huì)發(fā)現(xiàn)Distroless團(tuán)隊(duì)沒有維護(hù)細(xì)粒度的Node.js運(yùn)行時(shí)版本。這意味著你需要依賴于通用的nodejs:16的標(biāo)記（該標(biāo)記經(jīng)常更新），或者在一個(gè)特定時(shí)間點(diǎn)根據(jù)鏡像的SHA256哈希值進(jìn)行安裝。

Node.js Docker鏡像tags的比較

我們可以參考下面的表格來總結(jié)不同Node.js Docker鏡像tags之間的比較：

##OS Critical vulnerabilitiesMedium v??ulnerabilitiesLow vulnerabilitiesNode.js runtime vulnerabilitiesImage sizeYarn availableImage size952MB##node:bullseye 18.2.0409289#54182177952MBYesnode:bullseye-slim#18.2.0975648447#246MBYesnode:lts-bullseye-slim16.15.097554#7446188MBYesnode:alpine18.2.016220#00178MBYesgcr.io/distroless/nodejs:1616.17.09#1100110#112MBNo

Image tag	Node.js runtime version	OS dependencies	OS security vulnerabilities	#High and
		node	18.2.0	#409	289	54	# 18	217	7
Yes

我們來透過之前學(xué)習(xí)到的每個(gè)不同的Node.js鏡像tags的資料和見解，然後確定哪個(gè)是最理想的。

DEVELOPMENT-PARITY（開發(fā)環(huán)境平價(jià)）

如果你選擇使用的Node.js映像tag取決於開發(fā)的一致性（這意味著你希望為開發(fā)和生產(chǎn)完全相同的環(huán)境進(jìn)行最佳化），那麼這可能已經(jīng)是一場失敗的battle了。在大多數(shù)情況下，所有3個(gè)主要作業(yè)系統(tǒng)都使用不同的C庫實(shí)作。 Linux依賴glibc，Alpine依賴musl，而macOS有自己的BSD libc實(shí)作。

DOCKER鏡像大小有時(shí)候，鏡像大小也很重要。更準(zhǔn)確地說，我們的目標(biāo)不是擁有最小的體積，而是擁有最小的整體軟體佔(zhàn)用。在這種情況下，slim鏡像tags和alpine沒有太大的區(qū)別，而且它們對(duì)於一個(gè)容器鏡像來說平均大概是200MB。當(dāng)然，slim鏡像的軟體佔(zhàn)用相對(duì)於alpine來說還是相當(dāng)高的（slim97個(gè)VS alpine16個(gè)），因此，漏洞數(shù)量對(duì)於alipne來說也更高（slime56個(gè)VS slpine

2個(gè)）。

安全漏洞

漏洞是一個(gè)重要的問題，並且一直是許多文章的中心——關(guān)於你為什麼應(yīng)該減少容器鏡像的大小。 忽略node和node:bullseye這種由於較大的軟體佔(zhàn)用而跟著增加安全漏洞的鏡像，我們可以更關(guān)注稍微小一點(diǎn)的鏡像類型。在slim、alpine、distroless

之間對(duì)比，高風(fēng)險(xiǎn)和關(guān)鍵安全漏洞的絕對(duì)數(shù)量並不高，範(fàn)圍在0到4之間，這是一個(gè)可控的風(fēng)險(xiǎn)，不會(huì)影響到你的應(yīng)用程式。

本質(zhì)內(nèi)容?

最理想的Node.js Docker映像應(yīng)該是基於現(xiàn)代Debian OS的作業(yè)系統(tǒng)的精簡版本，它有一個(gè)穩(wěn)定且活躍的Node.js長期支援版本。 歸根究底就是選擇node:lts-bullseye-slim

Node.js鏡像tag。我贊成使用確定性圖像標(biāo)記，因此我要做的細(xì)微更改是使用實(shí)際的底層版本號(hào)，而不是

lts別名。 最理想的Node.js Docker映像tag是**node:16.17.0-bullseye-slim**

。 如果你在一個(gè)成熟的開發(fā)團(tuán)隊(duì)工作，該團(tuán)隊(duì)可以支援自訂基礎(chǔ)鏡像，那麼我的第二個(gè)最佳建議是選擇Google的distroless

鏡像tag ，因?yàn)樗３至?p>glibc對(duì)官方Node.js運(yùn)行時(shí)版本的兼容性。這個(gè)工作流程會(huì)需要一些維護(hù)，所以我只是建議而已。

更多node相關(guān)知識(shí)，請?jiān)煸L：###nodejs 教學(xué)###！ ###

以上是聊聊如何選擇一個(gè)最好的Node.js Docker映像？的詳細(xì)內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！