Heim >Web-Frontend >js-Tutorial >Lassen Sie uns darüber sprechen, wie Sie das beste Node.js-Docker-Image auswählen.

Lassen Sie uns darüber sprechen, wie Sie das beste Node.js-Docker-Image auswählen.

青灯夜游
青灯夜游nach vorne
2022-12-13 20:00:092627Durchsuche

Die Auswahl eines NodeDocker-Image mag wie eine kleine Sache erscheinen, aber die Größe und potenziellen Schwachstellen des Images können erhebliche Auswirkungen auf Ihren CI/CD-Prozess und Ihre Sicherheit haben. Wie wählen wir also das beste Node.js Docker-Image aus?

Lassen Sie uns darüber sprechen, wie Sie das beste Node.js-Docker-Image auswählen.

Wenn wir FROM node:latest oder einfach FROM node verwenden, können die potenziellen Risiken leicht ignoriert werden. Wenn Sie das allgemeine Sicherheitsrisiko nicht kennen und es nicht in den CI/CD-Prozess einbeziehen, wird es das Risiko zweifellos verschärfen. [Empfohlene verwandte Tutorials: FROM node:latest或只是FROM node时,很容易忽略他潜在的风险。如果你不知道总体的安全风险并且把他引入到了CI/CD的流程中,那无疑是加剧了这个风险。【相关教程推荐:nodejs视频教程编程教学

下面这个例子非常典型,你可以从很多教程或者博客文章中看到这个Node.js Dockerfile的配置。但是这个Dockerfile的配置存在很大的问题,非常不推荐这样使用:

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

译者注:如果需要跳过分析直接看结论,请直接滑到文末。

一个可供选择Node.js Docker镜像

当你构建一个Node.js镜像的时候,实际上有很多选择。其中就包括了Node.js核心团队维护的官方Docker镜像,以及从特定的基础镜像中选择的特殊Node.js镜像版本。还可以选择其他的,比如谷歌在distroless项目上构建的Node.js应用程序,或者是Docker官方团队提供的一个名为scratch的镜像。

在这些Node.js的Docker镜像中,哪一个是最适合你的呢?

让我们一个一个的去分析,了解更多他们的好处和潜在风险。

作者注:在这篇文章中,我将会比较18.2.0这个版本的Node.js镜像,他的发布时间是2022年6月左右。

默认的Node.js镜像

我们先从维护的node镜像开始。它是由进行正式地维护的,包含了一些基础的镜像tag。这些tag对应到不同的底层发行版(Debian、Ubuntu、Alpine)以及不同版本的Node.js运行时本身。还有针对不同CPU架构的特定版本tag,例如amd64arm64x8(新版苹果的M1)。

Debian发行版中最常见的node镜像,例如bullseyebuster,他们都是基于由另一个团队维护的buildpack-deps的。
当你基于这个默认的node镜像构建Node.js Docker镜像时会发生什么?

FROM node

使用docker build --no-cache -f Dockerfile1 -t dockerfile1构建镜像时,就会出现下面这些:

  • 我们没有指定Node.js运行时版本,所以nodenode:last的一个别名,他的版本指向的是18.2.0
  • 这个Node.js Docker镜像大小是952MB

这个最新的Node.js镜像的依赖和安全漏洞足迹是什么呢?我们可以用docker scan dockerfile1来运行一个Synk-powered容器,就会得到下面的结果:

  • 共有409个依赖项 - 这些是使用操作系统包管理器检测到的开源库,比如curl/libcurl4git/git-manimagemagick/imagemagick-6-common
  • 共有289个安全问题在这些依赖中被发现,例如,Buffer Overflowsuse-after-free errorsout-of-bounds write等。
  • Node.js 18.2.0运行时版本容易出现7个安全问题。例如,DNS RebindingHTTP Request SmugglingConfiguration Hijackingnodejs-Video-Tutorial
  • , Programmierunterricht
]

Das Folgende 1. Das Beispiel ist sehr typisch. Sie können die Konfiguration dieser Node.js-Dockerdatei aus vielen Tutorials oder Blogbeiträgen sehen. Es gibt jedoch große Probleme mit der Konfiguration dieser Docker-Datei, und es wird dringend davon abgeraten, sie auf diese Weise zu verwenden:

FROM node:bullseye复制代码
🎜🎜Anmerkung des Übersetzers: Wenn Sie die Analyse überspringen und direkt zu gehen müssen Zum Fazit scrollen Sie bitte direkt zum Ende des Artikels. 🎜
🎜🎜🎜

Ein Node.js-Docker-Image zur Auswahl

🎜Wenn Sie ein Node.js-Image erstellen, stehen tatsächlich viele Optionen zur Auswahl. Dazu gehören offizielle Docker-Images, die vom Node.js-Kernteam verwaltet werden, sowie spezielle Node.js-Image-Versionen, die aus bestimmten Basis-Images ausgewählt werden. Sie können auch andere auswählen, beispielsweise die von Google im Rahmen des distroless-Projekts erstellte Node.js-Anwendung oder ein Image namens scratch, das vom offiziellen Docker-Team bereitgestellt wird. 🎜🎜Welches dieser Node.js-Docker-Images ist für Sie am besten geeignet? 🎜🎜Lassen Sie uns sie einzeln analysieren, um mehr über ihre Vorteile und potenziellen Risiken zu erfahren. 🎜🎜🎜Anmerkung des Autors: In diesem Artikel werde ich das Node.js-Image der Version 18.2.0 vergleichen, die etwa im Juni 2022 veröffentlicht wird. 🎜🎜
🎜🎜

Standard-Node.js-Image

🎜Beginnen wir mit dem gepflegten Node-Image. Es wird offiziell von verwaltet und enthält einige grundlegende Bild-Tags. Diese Tags entsprechen verschiedenen zugrunde liegenden Distributionen (Debian, Ubuntu, Alpine) und verschiedenen Versionen der Node.js-Laufzeitumgebung selbst. Es gibt auch spezifische Versions-Tags für verschiedene CPU-Architekturen, wie zum Beispiel amd64 und arm64x8 (neue Version von Apples M1). 🎜🎜Die häufigsten node-Images in Debian-Distributionen, wie z. B. bullseye oder buster, basieren auf , die von einem anderen Team verwaltet werden >Buildpack -deps.
Was passiert, wenn Sie ein Node.js-Docker-Image basierend auf diesem Standard-node-Image erstellen? 🎜
FROM node:bullseye-slim
🎜Wenn Sie docker build --no-cache -f Dockerfile1 -t dockerfile1 verwenden, um das Image zu erstellen, wird Folgendes angezeigt: 🎜
  • Wir haben die Node.js nicht angegeben Laufzeitversion, also ist node ein Alias ​​von node:last und seine Version zeigt auf 18.2.0🎜
  • Dieses Node.js Docker Die Image-Größe beträgt 952 MB🎜🎜🎜Welche Abhängigkeiten und Sicherheitslücken weist dieses neueste Node.js-Image auf? Wir können docker scan dockerfile1 verwenden, um einen Synk-powered-Container auszuführen, und wir erhalten die folgenden Ergebnisse: 🎜
    • Es gibt insgesamt 409 Abhängigkeiten – Dabei handelt es sich um die Verwendung von Open-Source-Bibliotheken, die vom Paketmanager des Betriebssystems erkannt werden, z. B. curl/libcurl4, git/git-man, imagemagick/imagemagick-6-common >. 🎜
    • In diesen Abhängigkeiten wurden insgesamt 289 Sicherheitsprobleme gefunden, wie z. B. Pufferüberläufe, use-after-free-Fehler, out-of-bounds schreibenusw. 🎜
    • Die Laufzeitversion von Node.js 18.2.0 ist anfällig für 7 Sicherheitsprobleme. Zum Beispiel DNS Rebinding, HTTP Request Smuggling, Configuration Hijacking🎜🎜🎜🎜Anmerkung des Übersetzers: 🎜
      • Buffer Overflows - 缓冲区溢出
      • Use After Free - 一种内存破坏漏洞,通常存在于浏览器中
      • out-of-bounds write - 越界写入
      • DNS Rebinding - DNS重绑定攻击
      • HTTP Request Smugglin - HTTP请求夹带攻击技术
      • Configuration Hijacking - 配置劫持

      你真的需要在Node.js镜像中给你的应用提供wgetgitcurl吗?在Node.js Docker镜像中,有成百上千个依赖和工具,而这些依赖又对应着成百上千个漏洞。Node.js运行时的特性对应着7个不同的安全漏洞,给潜在攻击留下了很大的空间。总的来说,情况并不是很乐观。

      Node.js Docker Hub选项node:buster vs node:bullseye

      如果你在Node.js Docker Hub仓库上浏览可用tags,你将会发现有两个Node.js镜像tags - node:busternode:bullseye

      这两个Docker镜像tags都基于Debian发行版。buster镜像tag对应着Debian10,将会在2022年8月到2024年进入到他的End of Life日期,所以buster不是一个很好的选择。bullseye镜像tag对应着Debian11,被当做Debian的当前稳定版本,预计EOL日期为2026年6月。

      译者注:

      • End of Life。特指产品寿命的结束,通常缩写为EOL。

      因此,十分建议你将所有新的和现有的Node.js Docker镜像从node:buster迁移到node:bullseye或者其他合适的可替代版本。
      我们先构建一个新的Node.js Docker镜像基于:

      FROM node:bullseye复制代码

      如果你构建了这个Node.js Docker镜像tag并且与之前使用node:latest的结果进行比较,将会得到完全相同的大小、依赖数量和发现的漏洞。原因是nodenode:latestnode:bullseye全部指向了同一个正在构建的Node.js镜像tag。

      Node.js镜像tag瘦身

      官方的Node.js团队还维护了一个显式地针对功能性Node.js环境所需工具的镜像tag并且不会存在其他的东西。

      这个Node.js镜像tags是通过slim镜像tag变量来引用的,比如node:bullseye-slim,或者带有Node.js指定版本,像node:14.19.2 -slim

      我们再来基于Debian的当前稳定版本的bullseye构建一个Node.jsslim镜像:

      FROM node:bullseye-slim
      • 镜像的大小已经急剧下降,从接近1GB的容器镜像降到246MB的镜像大小
      • 扫描他的内容也显示了整体软件足迹的大幅下降,只有97个依赖项和56个漏洞。

      就容器镜像大小和安全状况而言,node:bullseye-slim已经是一个比较好的起点了。

      一个LTS的Node.js Docker镜像

      到目前为止,我们的Node.js Docker镜像基于当前版本的Node.js,即Node.js18。但是根据Node.js的发布时间表,这个版本直到2022年10月才进入正式的Active LTS状态。

      译者注:LTS - Long-term support,即长期支持版本。

      如果我们总是依赖于我们正在构建的Node.js Docker镜像中的LTS版本的话会怎么样?我们先更新这个Docker镜像tag并构建一个新的Node.js镜像:

      FROM node:lts-bullseye-slim

      瘦身后的Node.js LTS版本(16.15.0)在镜像上带来了相似数量的依赖、安全漏洞和一个略小的体积(188MB)。

      因此,尽管你可能需要在LTS和当前Node.js运行时版本中选择,但他们都不会对Node.js镜像的软件占用空间有大的影响。

      node:alpine对于Node.js镜像来说是一个更好的选择吗?

      Node.js Docker团队维护了一个node:alpine镜像tag以及他的变体,以便将Alpine Linux发行版的特定版本与Node.js运行时的特定版本进行匹配。

      Alpine Linux项目经常因为其非常小的镜像体积而被引用,小体积意味着更新的软件占用空间和更少的漏洞,确实十分不错。
      下面的命令会让Dockerfile去生成一个node环境,这个将会增加未压缩的镜像体积:

      FROM node:alpine

      这个将会产生一个178MB大小的docker镜像,和slimNode.js镜像大小差不多,但是在alpine镜像tag中,只检测到了16个系统依赖漏洞和2个安全安全漏洞。这就意味着alpine镜像tag对于小体积和漏洞数量来说是一个比较好的选择。

      alpine对Node.js镜像可能提供了一个较小的镜像体积和更少的漏洞数量。但是,我们必须意识到Alpine项目使用musl作为C标准库的实现。而Debian的Node.js镜像tag依赖于glibc实现,比如bullseyeslim。这些差异可以解释性能问题、功能性的bug或者是潜在的应用程序崩溃,这些都是由于底层C库的差异造成的。

      选择一个alpine的Node.js镜像tag意味着你实际上是在选择一个非官方的Node.js运行时。Node.js Docker团队并不会正式支持基于alpine的容器镜像构建。因此,他声明基于Alpine的镜像tag是实验性的,并且可能和官方的构建不一致。

      如果你正在选一个一个基于Alpine的Node.js Docker镜像,需要记住一点,Docker安全工具(例如Trivy或Snyk)目前无法检测到Alpine镜像中与运行时相关的漏洞的。虽然这种情况未来可能会改变,但是目前还不能找到Node.js18.2.0alpine基础镜像tag的安全漏洞,而18.2.0运行时本身实际上是容易受到攻击的。这与安全工具本身有关,而不是与Alpine基础镜像有关,但是也应该考虑到这一点。

      Node.js的distroless(无损)Docker镜像

      我们的基准测试的最后一个比较项目是谷歌的Distroless容器镜像。

      什么是distroless容器镜像?

      这种镜像甚至比slim的Node.js镜像更加小,因为distroless镜像只针对这个应用和应用运行时的依赖性而已。因此,一个distroless的docker镜像没有容器包管理器、shell、或者其他通用工具的依赖性,这使得它们的体积更小,漏洞也更少。

      幸运的是,Distroless项目为Node.js维护了一个特殊运行时的distrolessdocker镜像,通过其完整的命名空间识别为grc.io/distroless/nodejs-debian11,并且可以在谷歌的容器注册表中找到(这个是gcr.io的部分)。

      因为Distroless容器镜像没有软件,我们可以使用一个docker的多阶段工作流来为我们的容器安装依赖项,并且把它们复制到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"]

      构建这个distrolessdocker镜像将产生112MB的文件,而在slimalpine镜像tag来说,这已经减小了很多文件的体积了。
      如果你正在考虑使用distrolessdocker镜像,有一些重要的事项需要注意:

      • 好的一点是,它们是基于当前稳定的Debian发行版本,这意味着它们是最新的,很久才会到EOL的日期。
      • 因为它们是基于Debian的,所以它们依赖glibc实现,并且不太可能在生产环境出现一些奇怪的问题。
      • 你很快就会发现Distroless团队没有维护细粒度的Node.js运行时版本。这意味着你需要依赖于通用的nodejs:16的标记(该标记经常更新),或者在一个特定时间点根据镜像的SHA256哈希值进行安装。

      Node.js Docker镜像tags的比较

      我们可以参考下面的表格来总结不同Node.js Docker镜像tags之间的比较:

      Knotennode:bullseye 409 975648447246MBJanode:lts-bullseye-slim16.15.0975547 446188 MB Ja gcr.io/distroless/nodejs:16 16.17.091100110112MBNein Sie können auch Node.js-Tags verwenden的数据和见解,然后确定哪个是最理想的.DEVELOPMENT-PARITY(开发环境平价)安全漏洞本质内容?最理想的Node.js Docker镜像应该是一个基于现代Debian OS的操作系统的精简版本,它有一个稳定且活跃的Node.js长期支持版本.归根结底就是选择node:lts-bullseye-slimNode.js镜像tag更改是使用实际的底层版本号,而不是ltswerden angezeigt一个成熟的开发团队工作,该团队可以支持自定义基础镜像,那么我的第二个最佳建议是选择谷歌的distroless镜像tag,因为它保持了glibc code>对官方Node.js运行时版本的兼容性.这个工作流会需要一些维护,所以我只是建议而已.<td></td>更多node相关知识,请访问: <td>nodejs 教程</td>!<td></td>
      Image-Tag Node.js-Laufzeitversion OS-Abhängigkeiten OS-Sicherheitslücken Hohe und kritische Schwachstellen Mittlere Schwachstellen Node.js-Laufzeit. Schwachstellen Bildgröße Garn verfügbar
      18.2.0 409 289 54 18 217 7 952 MB Ja
      18.2.0
      如果你选择使用的Node.js镜像tag取决于开发的一致性(这意味你希望为开发和生产完全相同的环境进行优化),那么这可能已经是一场失败的battle了.在大多数情况下,所有3个主要操作系统都使用不同的C库实现.Linux依赖glibc,Alpine依赖musl, macOS ist eine BSD-Bibliothek准确地说, 我们的目标不是拥有最小的体积, 而是拥有最小的整体软件占用.在这种情况下, slim镜像tags und alpine没有太大的区别,而且它们对于一个容器镜Es handelt sich um eine Datei mit einer Kapazität von 200 MB. slim镜像的软件占用相对于alpine来说还是相当高的(slim97% VS alpine16% ), 因此, 漏洞数量对于alipne来说也更高(slime56个 VS slpine2个)。

      漏洞是一个重要的问题,并且一直是很多文章的中心——关于你为什么应该减少容器镜像的大小. 忽略nodeund node:bullseye Code:型。在<code>slimalpinedistroless并不会影响到你的应用程序.

Das obige ist der detaillierte Inhalt vonLassen Sie uns darüber sprechen, wie Sie das beste Node.js-Docker-Image auswählen.. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:juejin.cn. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen