#Node Docker イメージの選択は小さな問題のように思えるかもしれませんが、イメージのサイズと潛在的な脆弱性は、CI/CD プロセスとセキュリティに大きな影響を與える可能性があります。では、最適な Node.js Docker イメージを選択するにはどうすればよいでしょうか?

FROM ノード:最新 または単に FROM ノード を使用する場合、その潛在的なリスクを無視するのは簡単です。全體的なセキュリティ リスクを知らずに CI/CD プロセスに導(dǎo)入すると、間違いなくリスクが悪化します。 [関連チュートリアルの推奨事項: nodejs ビデオ チュートリアル 、プログラミング教育 ]

次の例は非常に典型的なもので、このノードは多くのチュートリアルやブログ投稿で見ることができます。 Dockerfileの設(shè)定。

ただし、この Dockerfile の構(gòu)成には大きな問題があるため、次のように使用することは強くお勧めできません:

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

翻訳者注: をスキップする必要がある場合は、分析して結(jié)論を??直接確認するには、記事の最後まで直接スライドしてください。

選択する Node.js Docker イメージ

Node.js イメージをビルドするとき、実際にはたくさんの選択肢があります。これらには、Node.js コア チームによって保守されている公式の Docker イメージと、特定のベース イメージから選択された特別な Node.js イメージ バージョンが含まれます。 Google が

distroless プロジェクトで構(gòu)築した Node.js アプリケーションや、公式の Docker チームが提供する scratch というイメージなど、他のものを選択することもできます。

これらの Node.js Docker イメージの中で、あなたに最も適したものはどれですか?

それらを 1 つずつ分析して、その利點と潛在的なリスクについて詳しく見てみましょう。

著者注: この記事では、2022 年 6 月頃にリリースされるバージョン 18.2.0 の Node.js イメージを比較します。

#デフォルトの Node.js イメージ

まず、維持されているノード イメージから始めます。これは によって公式に管理されており、いくつかの基本的なイメージ タグが含まれています。これらのタグは、基盤となるさまざまなディストリビューション (Debian、Ubuntu、Alpine) および Node.js ランタイム自體のさまざまなバージョンに対応します。

amd64

や arm64x8 (Apple の M1 の新しいバージョン) など、さまざまな CPU アーキテクチャに固有のバージョン タグもあります。 Debian ディストリビューションで最も一般的な

node

イメージ (bullseye や buster など) は、によって保守されている に基づいています。別のチーム##buildpack-deps。 このデフォルトの node
イメージに基づいて Node.js Docker イメージを構(gòu)築するとどうなりますか? <pre class='brush:php;toolbar:false;'>FROM node</pre>Use

docker build --no-cache -f Dockerfile1 -t dockerfile1

イメージをビルドすると、次のように表示されます:

指定しませんでしたNode .js ランタイム バージョン。したがって、

node
• は node:last のエイリアスであり、そのバージョンは、この 18.2.0 を指します。 Node.js Docker イメージのサイズは 952MB
この最新の Node.js イメージの依存関係とセキュリティ脆弱性の足跡は何ですか?

docker scan dockerfile1

を使用して Synk を利用した コンテナを?qū)g行すると、次の結(jié)果が得られます:

合計 409 個の依存関係があります -これらは、オペレーティング システムのパッケージ マネージャーによって検出されたオープン ソース ライブラリを使用します (

curl/libcurl4
• 、git/git-man、imagemagick/imagemagick-6-common## など)。 ＃。 これらの依存関係では、バッファ オーバーフロー
、
• use-after-free エラー、境界外など、合計 289 件のセキュリティ問題が見つかりました。 などを書きます。 Node.js 18.2.0 ランタイム バージョンには 7 つのセキュリティ問題が発生する傾向があります。例: DNS 再バインド
、
• HTTP リクエスト スマグリング、構(gòu)成ハイジャック
翻訳者注:

• 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鏡像中，有成百上千個依賴和工具，而這些依賴又對應(yīng)著成百上千個漏洞。Node.js運行時的特性對應(yīng)著7個不同的安全漏洞，給潛在攻擊留下了很大的空間?？偟膩碚f，情況并不是很樂觀。

Node.js Docker Hub選項node:buster vs node:bullseye

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

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

譯者注：

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

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

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

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

Node.js鏡像tag瘦身

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

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

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

FROM node:bullseye-slim

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

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

一個LTS的Node.js Docker鏡像

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

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

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

FROM node:lts-bullseye-slim

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

因此，盡管你可能需要在LTS和當前Node.js運行時版本中選擇，但他們都不會對Node.js鏡像的軟件占用空間有大的影響。

node:alpine對于Node.js鏡像來說是一個更好的選擇嗎？

Node.js Docker團隊維護了一個node:alpine鏡像tag以及他的變體，以便將Alpine Linux發(fā)行版的特定版本與Node.js運行時的特定版本進行匹配。

Alpine Linux項目經(jīng)常因為其非常小的鏡像體積而被引用，小體積意味著更新的軟件占用空間和更少的漏洞，確實十分不錯。
下面的命令會讓Dockerfile去生成一個node環(huán)境，這個將會增加未壓縮的鏡像體積：

FROM node:alpine

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

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

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

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

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

我們的基準測試的最后一個比較項目是谷歌的Distroless容器鏡像。

什么是distroless容器鏡像?

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

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

因為Distroless容器鏡像沒有軟件，我們可以使用一個docker的多階段工作流來為我們的容器安裝依賴項，并且把它們復(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)建這個distrolessdocker鏡像將產(chǎn)生112MB的文件，而在slim和alpine鏡像tag來說，這已經(jīng)減小了很多文件的體積了。
如果你正在考慮使用distrolessdocker鏡像，有一些重要的事項需要注意：

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

Node.js Docker鏡像tags的比較

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

イメージ タグ	Node.js ランタイム バージョン	OS の依存関係	OS セキュリティの脆弱性	高および重大な脆弱性	中程度の脆弱性	低レベルの脆弱性	Node.js ランタイムの脆弱性	畫像サイズ	利用可能な糸
ノード	18.2.0	409	289	54	18	217	7	952MB	はい
ノード:ブルズアイ	18.2.0	409	289	54	18	217	7	952MB	はい
ノード:ブルズアイスリム	18.2.0	97	56	4	8	44	7	246MB	はい
node:lts-bullseye-slim	16.15.0	97	55	4	7	44	6	188MB	はい
ノード:アルパイン	18.2.0	16	2	2	0	0	0	178MB	はい
gcr.io/distroless/nodejs:16	16.17.0	9	11	0	0	11	0	112MB	No

さまざまな Node.js イメージ タグのそれぞれについて學(xué)んだデータと洞察を調(diào)べて、どれが理想的であるかを判斷してみましょう。

DEVELOPMENT-PARITY (開発環(huán)境パリティ)

Node.js イメージ タグの使用を選択するかどうかは、開発の一貫性によって決まります (これは、開発と運用とまったく同じ環(huán)境に最適化することを意味します)、その場合、これはすでに負け戦である可能性があります。ほとんどの場合、3 つの主要なオペレーティング システムはすべて、異なる C ライブラリ実裝を使用します。 Linux は glibc に依存し、Alpine は musl に依存し、macOS には獨自の BSD libc 実裝があります。

DOCKER イメージ サイズ

イメージ サイズも重要な場合があります。より正確に言うと、私たちの目標はサイズを最小にすることではなく、ソフトウェア全體のフットプリントを最小にすることです。この場合、slim イメージ タグと alpine の間に大きな違いはなく、コンテナー イメージあたり平均約 200MB です。もちろん、slim ミラーのソフトウェア使用率は、alpine と比較して依然としてかなり高くなります (slim97 VS alpine16)。 、脆弱性の數(shù)も alipne の方が高くなります (slime56 対 slpine2)。

セキュリティの脆弱性

脆弱性は重要な問題であり、コンテナ イメージのサイズを削減する必要がある理由に関する多くの記事の中心となっています。

node と node:bullseye は、ソフトウェアの使用量が増えるとセキュリティの脆弱性が増大するイメージです。少し小さいイメージ タイプに注意を払うことができます。 slim、alpine、distroless を比較すると、高リスクおよび重大なセキュリティ脆弱性の絶対數(shù)は 0 ～ 4 であり、それほど多くはありません。アプリケーションに影響を與えない、制御可能なリスク。

重要なコンテンツ?

理想的な Node.js Docker イメージは、最新の Debian OS をベースにしたオペレーティング システムの合理化されたバージョンである必要があります。は、Node.js の安定したアクティブな長期サポート バージョンです。

最後の分析は、node:lts-bullseye-slimNode.js ミラー タグを選択することです。私は決定論的なイメージ タグを使用することに賛成なので、少し変更するとすれば、lts エイリアスの代わりに実際の基礎(chǔ)となるバージョン番號を使用することです。

最も理想的な Node.js Docker イメージ タグは **node:16.17.0-bullseye-slim** です。

カスタム ベース イメージをサポートできる成熟した開発チームで作業(yè)している場合、次善の提案は、glibc# を維持する Google の distrolessimage タグを選択することです。 ## 公式 Node.js ランタイム バージョンとの互換性。このワークフローには多少のメンテナンスが必要になるため、私はこれを提案しているだけです。

ノード関連の知識の詳細については、

nodejs チュートリアル を參照してください。

以上が最適な Node.js Docker イメージを選択する方法について話しましょう。の詳細內(nèi)容です。詳細については、PHP 中國語 Web サイトの他の関連記事を參照してください。