如何挑选node docker镜像
在使用Jenkins构建前端项目的时候遇到一点问题： node的版本问题。
由于可能编译的项目历史不同，所依赖的node版本也各有千秋，直接把所有项目都升级到最新的也不合理。所以必须针对不同的项目使用不同node构建环境。
想过nvm，但nvm是系统级别的环境变量切换，会导致同时运行的其他job也会使用nvm更改后的node版本。nvm只适合个人开发使用。
想过下载。最初见到公司的仓库里会有node.gradle脚本，主要用来下载当前项目的node，然后直接用自己下载的node来构建。用起来还行，但脚本维护是一个问题，升级是一个问题，下载也是一个问题。
最终选择用docker来构建。docker可以随意挑选node镜像，可以缓存。我们可以基于官方的镜像，添加一些适合自己的依赖，比如缓存一些公共的module。
docker hub里有多个node tag，选择哪个好呢。
google了一下，大概得出的结论是： alpine足矣。但我最终没有选择alpine， 后面说原因。
Node Docker tag先来看看node官方的docker镜像有哪些版本。
node:<version> 基于Debian,官方默认镜像。当你不确定你需要什么的时候选择这个就对了。这个被设计成可以丢弃的镜像，也就是可以用作构建源码使用。体积挺大。 node:<version>-slim 基于Debian， 删除了很多默认公共的软件包，只有node运行的最小环境。除非你有空间限制，否则推荐使用默认镜像。 node:<version>-alpine 基于alpine, 比Debian小的多。如果想要最小的镜像，可以选择这个做为base。需要注意的是，alpine使用musl代替glibc。一些c环境的软件可能不兼容。但大部分没问题。 选择按照版本推荐。对比我们的需求，作为构建环境的化，应该选择默认镜像。
来对比下所谓的镜像体积：
node 12.6.0-buster-slim e6e2b19326d7 13 hours ago 161MB node 12.6.0-buster b6a436219112 13 hours ago 875MB node 12.6.0-alpine a9a8b83644f7 3 weeks ago 78.8MB在这之前先来了解下debian的发行版
Debian 10（buster） — 当前的稳定版（stable） Debian 9（stretch） — 旧的稳定版（oldstable） Debian 8（jessie） — 更旧的稳定版（oldoldstable） Debian 7（wheezy） — 被淘汰的稳定版最新的node镜像就是基于Debian 10 buster构建的。
image的体积上， alpine几乎比默认镜像小10倍。即便缩减后的slim，也少一半。
再来看image体积重要不重要。大的image下载需要花时间，需要占用磁盘空间。思考一下，官方镜像近1g，这个磁盘空间还是有的。至于下载时间，docker分层缓存机制可以使得我们只要下载一次即可。也是可以接受。
在使用镜像的时候，docker对于共享的分层是不会复制两份的，也就是共享一份，不会增大磁盘空间。详细介绍见
关注下运行时的内存占用
sudo docker stats CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS c0affeebef3f gracious_williamson 0.00% 964KiB / 15.54GiB 0.01% 8.23kB / 0B 0B / 0B 1 c7a52376ac30 suspicious_goldstine 0.00% 2.047MiB / 15.54GiB 0.01% 9.57kB / 0B 4.13MB / 0B 1 39ae2195606d unruffled_elgamal 0.00% 1.387MiB / 15.54GiB 0.01% 12.2kB / 0B 0B / 0B 1差别还是有的，但在可以接受的范围内。
最重要的是，不同tag的docker镜像运行时可以满足需求吗。
针对这三种镜像，分别对vue-element-admin执行了npm install. 结果基于debian的镜像12.6.0-buster-slim和12.6.0-buster都ok，但12.6.0-alpine 报错了
所以呢，针对我当前作为构建环境的需求，选择12.6.0-buster，也没啥。
至于nodejs运行时的server，没有实验，感觉12.6.0-buster-slim挺好。