Memilih Nod Imej Docker mungkin kelihatan seperti perkara kecil, tetapi saiz dan potensi kelemahan imej boleh memberi kesan yang ketara pada proses dan keselamatan CI/CD anda. Jadi bagaimana kita memilih imej Node.js Docker terbaik?
Apabila kita menggunakan FROM node:latest atau hanya FROM node, adalah mudah untuk mengabaikan potensi risikonya. Jika anda tidak mengetahui risiko keselamatan keseluruhan dan memperkenalkannya ke dalam proses CI/CD, sudah pasti ia akan memburukkan lagi risiko tersebut. [Tutorial berkaitan yang disyorkan: tutorial video nodejs, Pengajaran pengaturcaraan]
Contoh berikut adalah sangat biasa Anda boleh melihat Nod ini daripada banyak tutorial atau catatan blog Konfigurasi fail Docker. Walau bagaimanapun, terdapat masalah besar dengan konfigurasi Dockerfile ini, dan sangat tidak disyorkan untuk menggunakannya seperti ini:
FROM node WORKDIR /usr/src/app COPY . /usr/src/app RUN npm install CMD "npm" "start"
Nota Penterjemah: Jika anda perlu langkau analisis dan terus ke kesimpulan, sila pergi terus Tatal ke akhir artikel.
Apabila anda membina imej Node.js , terdapat sebenarnya banyak pilihan. Ini termasuk imej Docker rasmi yang diselenggara oleh pasukan teras Node.js, serta versi imej Node.js khas yang dipilih daripada imej asas tertentu. Anda juga boleh memilih yang lain, seperti aplikasi Node.js yang dibina oleh Google pada projek distroless atau imej bernama scratch yang disediakan oleh pasukan Docker rasmi.
Antara imej Node.js Docker ini, yang manakah paling sesuai untuk anda?
Mari kita analisa mereka satu demi satu untuk mengetahui lebih lanjut tentang manfaat dan potensi risiko mereka.
Nota Pengarang: Dalam artikel ini, saya akan membandingkan imej Node.js versi 18.2.0, yang akan dikeluarkan sekitar Jun 2022.
Mari kita mulakan dengan imej nod yang dikekalkan. Ia diselenggara secara rasmi oleh , dan mengandungi beberapa teg imej asas. Teg ini sepadan dengan pengedaran asas yang berbeza (Debian, Ubuntu, Alpine) dan versi berbeza bagi masa jalan Node.js itu sendiri. Terdapat juga teg versi khusus untuk seni bina CPU yang berbeza, seperti amd64 dan arm64x8 (versi baharu Apple M1).
Cermin node yang paling biasa dalam pengedaran Debian, seperti bullseye atau buster, adalah berdasarkan buildpack-deps yang diselenggara oleh pasukan lain.
Apakah yang berlaku apabila anda membina imej Node.js Docker berdasarkan imej node lalai ini?
FROM node
Apabila membina imej menggunakan docker build --no-cache -f Dockerfile1 -t dockerfile1, perkara berikut akan dipaparkan:
node ialah node:last Alias , versinya menunjuk kepada 18.2.0Ketergantungan dan jejak kerentanan keselamatan Node.js terbaru ini gambar Apa itu? Kita boleh menjalankan docker scan dockerfile1 bekas dengan Synk-powered dan mendapatkan hasil berikut:
curl/libcurl4, git/git-man, imagemagick/imagemagick-6-common. Buffer Overflows, use-after-free errors, out-of-bounds write, dsb. DNS Rebinding, HTTP Request Smuggling, Configuration HijackingNota penterjemah:
- Buffer Overflows - 缓冲区溢出
- Use After Free - 一种内存破坏漏洞，通常存在于浏览器中
- out-of-bounds write - 越界写入
- DNS Rebinding - DNS重绑定攻击
- HTTP Request Smugglin - HTTP请求夹带攻击技术
- Configuration Hijacking - 配置劫持
你真的需要在Node.js镜像中给你的应用提供wget、git、curl吗？在Node.js Docker镜像中，有成百上千个依赖和工具，而这些依赖又对应着成百上千个漏洞。Node.js运行时的特性对应着7个不同的安全漏洞，给潜在攻击留下了很大的空间。总的来说，情况并不是很乐观。
如果你在Node.js Docker Hub仓库上浏览可用tags，你将会发现有两个Node.js镜像tags - node:buster和node: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的结果进行比较，将会得到完全相同的大小、依赖数量和发现的漏洞。原因是node、node:latest、node:bullseye全部指向了同一个正在构建的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
就容器镜像大小和安全状况而言，node:bullseye-slim已经是一个比较好的起点了。
到目前为止，我们的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.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实现，比如bullseye和slim。这些差异可以解释性能问题、功能性的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基础镜像有关，但是也应该考虑到这一点。
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的文件，而在slim和alpine镜像tag来说，这已经减小了很多文件的体积了。
如果你正在考虑使用distrolessdocker镜像，有一些重要的事项需要注意：
glibc实现，并且不太可能在生产环境出现一些奇怪的问题。nodejs:16的标记（该标记经常更新），或者在一个特定时间点根据镜像的SHA256哈希值进行安装。
我们可以参考下面的表格来总结不同Node.js Docker镜像tags之间的比较：
| Image tag | Node.js runtime version | OS dependencies | OS security vulnerabilities | High and Critical vulnerabilities | Medium vulnerabilities | Low vulnerabilities | Node.js runtime vulnerabilities | Image size | Yarn available |
|---|---|---|---|---|---|---|---|---|---|
| node | 18.2.0 | 409 | 289 | 54 | 18 | 217 | 7 | 952MB | Yes |
| node:bullseye | 18.2.0 | 409 | 289 | 54 | 18 | 217 | 7 | 952MB | Yes |
| node:bullseye-slim | 18.2.0 | 97 | 56 | 4 | 8 | 44 | 7 | 246MB | Yes |
| node:lts-bullseye-slim | 16.15.0 | 97 | 55 | 4 | 7 | 44 | 6 | 188MB | Yes |
| node:alpine | 18.2.0 | 16 | 2 | 2 | 0 | 0 | 0 | 178MB | Yes |
| gcr.io/distroless/nodejs:16 | 16.17.0 | 9 | 11 | 0 | 0 | 11 | 0 | 112MB | No |
Mari kita lihat data dan cerapan yang kami pelajari tentang setiap teg imej Node.js yang berbeza dan tentukan yang mana satu yang sesuai.
Jika anda memilih untuk menggunakan teg imej Node.js bergantung pada ketekalan pembangunan ( ini bermakna anda ingin mengoptimumkan untuk persekitaran yang sama seperti pembangunan dan pengeluaran), maka ini mungkin sudah menjadi pertempuran yang kalah. Dalam kebanyakan kes, kesemua 3 sistem pengendalian utama menggunakan pelaksanaan perpustakaan C yang berbeza. Linux bergantung pada glibc, Alpine bergantung pada musl, dan macOS mempunyai pelaksanaan libc BSD sendiri.
Kadangkala, saiz imej juga penting. Untuk menjadi lebih tepat, matlamat kami bukan untuk mempunyai saiz terkecil, tetapi untuk mempunyai jejak perisian keseluruhan terkecil. Dalam kes ini, tiada banyak perbezaan antara slim teg imej dan alpine, dan ia purata kira-kira 200MB untuk imej bekas. Sudah tentu, penggunaan perisian slim cermin masih agak tinggi berbanding alpine (slim97 VS alpine16), oleh itu, bilangan kelemahan juga lebih tinggi untuk alipne (slime56 VS slpine2).
Kerentanan ialah isu penting dan telah menjadi pusat kepada banyak artikel - tentang sebab anda perlu mengurangkan saiz imej kontena.
Abaikan imej node dan node:bullseye yang meningkatkan kerentanan keselamatan kerana jejak perisiannya yang lebih besar. Kami boleh memfokuskan lebih pada jenis imej yang lebih kecil. Membandingkan antara slim, alpine dan distroless, bilangan mutlak kerentanan keselamatan berisiko tinggi dan kritikal adalah tidak tinggi, antara 0 hingga 4. Ini adalah risiko yang boleh dikawal dan tidak akan menjejaskan aplikasi anda.
Imej Node.js Docker yang ideal mestilah versi sistem pengendalian yang diperkemas berdasarkan OS Debian moden ialah versi sokongan jangka panjang yang stabil dan aktif bagi Node.js.
Analisis akhir ialah memilih node:lts-bullseye-slimteg cermin Node.js. Saya memihak untuk menggunakan teg imej deterministik, jadi sedikit perubahan yang saya akan lakukan ialah menggunakan nombor versi asas sebenar dan bukannya alias lts.
Teg imej Node.js Docker yang ideal ialah **node:16.17.0-bullseye-slim**.
Jika anda bekerja dengan pasukan pembangunan matang yang boleh menyokong imej asas tersuai, maka nasihat kedua terbaik saya ialah memilih tag imej distroless Google kerana ia mengekalkan keserasian yang dipertingkatkan dengan versi masa jalan Node.js rasmi . Aliran kerja ini memerlukan sedikit penyelenggaraan, jadi saya hanya mencadangkannya. glibc
tutorial nodejs!
Atas ialah kandungan terperinci Mari kita bincangkan tentang cara memilih imej Node.js Docker terbaik?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![Tutorial pengenalan lengkap Node.js [es6+npm+express+webpack+promise]](https://img.php.cn/upload/course/000/000/068/6242b4c8f1a39624.png)
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
