分享一下在 node.js 项目里打包 docker 镜像的小技巧.

[flyingfz]

在实际的项目开发时，打包 Docker 镜像，其实还是有些细节需要注意

例如，镜像的 name 、tag 如何更准确的表达当前代码的信息。

我认为，镜像的名字以这种格式会比较好 : 私有仓库/项目/产品-git 分支:时间-git hash

当然， 这个观点，大家可能有不同的意见，只是这个格式比较适合我们。

基于以上的想法， 可以在 package.json 的 scripts 里， 增加:

// package.json
{
    ...
    "scripts": {
        ...
        "build-img": "docker build -t registry.xxxxx.com/$(pwd | rev | cut -d / -f 1-2 - | rev)-$(git rev-parse --abbrev-ref HEAD):$(git log --pretty=%ad-%h --date=format:'%y%m%d%H%M' -n 1) ."
        ...
    }
    ...
}

使用时， 直接 npm run build-img 即可， 打包出来的镜像名称类似: registry.xxxxx.com/上级目录名/当前目录名-分支名:yyMMddmmss-hash。

上面的脚本，其实有个关于代码目录的约定: 在项目的目录下，clone 各个 git 仓库的代码 .

通过上面这种方式打包镜像，好处是从镜像名称就能知道 这个镜像属于哪个项目,哪个产品，所属 git 分支，最后一次签入的时间和 hash （即代码的当前状态） 。

并且，只要代码没有变动(或者应该说，没有进行 git commit)，任何时候从 仓库 clone 代码，再次打包镜像时，名称都是一致的。

简单来说， 可以保持镜像名称和 git 仓库的关系。

[AoEiuV020JP]

非要浓缩在 package.json 里吗， 我看正常项目 docker 应该是独立出来的脚本处理的，

[flyingfz]

当然是可以单独写个 .sh 文件 做镜像的打包。

只是， 上面那段脚本 我觉得还没有复杂到需要独立一个文件。

[assassing]

镜像命名差不多一致，不过项目这段直接体现了分支。分支代表环境，不同分支镜像隔离在不同仓库中，方便清理和权限管理。

[flyingfz]

是的。

上面这段脚本很重要的一个目的， 就是区分代码分支 、环境 ， 以及 建立 镜像和代码仓库的关系。

可以想象一下， 在服务器上看到了一个镜像的名称，然后 可以在 git 仓库里， 根据 commit 的时间，hash , 找到镜像对应版本的代码

签入的日志又可以带出更多的信息

这种方式， 在 没有 完善的版本管理和部署流程的情况下，可以很方便的跟踪 部署的镜像和仓库签入之间的关系。

适用场景其实也有限 。

[xhawk]

不对，这个问题有点有趣。像我这边，是用 docker compose 启动的，你这样子搞，只能说用来方便跟踪镜像产生过程，但是发布的时候你是咋弄的？

[guanzhangzhang]

你这有问题，用 makefile 可以设置默认 tag 规则，要是特定暂存 tag ，你还得 vi 你这个 json 文件修改再构建镜像
make image TAG=xxxxx

[flyingfz]

@xhawk 我们没有使用 docker compose 启动容器。 大部分情况下，都是为每个应用手写一个脚本启动。 确实是需要在更新部署的时候修改 tag 值。
我的理解，如果是使用 docker compose , 那么最好每次 tag 都是 latest 会比较方便， 上面我也说过了， 这种方法适用的场景其实有限。

@guanzhangzhang 没有了解过使用 makefile 来打包镜像，能否分享下你的场景和做法？

[guanzhangzhang]

@flyingfz #7 我的意思如果是拼接和设置默认名字 format 之类的，通常都是写 Makefile 里的，你这个可以你自己用，但是这个依赖 npm 命令，而 CI 阶段，是宿主机由 docker 和 make ，执行 makefile 才对
IMAGE_REPO ?= registry.xxxxx.com/xxxx
IMAGE_TAG ?= $(shell git log --pretty=%ad-%h --date=format:'%y%m%d%H%M' -n 1)
IMAGE_NAME ?= $(IMAGE_REPO)/$(IMAGE_NAME)

image:
docker build . -t $(IMAGE_NAME) #前面是 tab ，tab 开头才解释成 shell 命令

构建测试镜像
makge image TAG=v1.0-test

[flyingfz]

@guanzhangzhang 大概理解了你的意思。
确实，如果使用 CI 工具，确实是放在 Makfile 里比较合适。否则 CI 里还要依赖 npm 命令。

由于种种原因， 我们抛弃了 CI ，自己手工打镜像更简单 。 并且，我们的开发语言是 nodejs ，
在这个背景下，我们在任意项目里，仅需在 node 的 package.json 里增加这么一段脚本，即可打包出 名称具有一定意义的镜像。

所以， 结论是，如果使用 完善的部署流程 ，这个小技巧并不适用。