分享一下在 node.js 项目里打包 docker 镜像的小技巧. - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
flyingfz
V2EX    Node.js

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

  •  
  •   flyingfz 2024-08-28 15:26:14 +08:00 2781 次点击
    这是一个创建于 483 天前的主题,其中的信息可能已经有所发展或是发生改变。

    在实际的项目开发时,打包 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 仓库的关系。

    9 条回复    2024-09-02 10:39:21 +08:00
    AoEiuV020JP
        1
    AoEiuV020JP  
       2024-08-28 15:41:39 +08:00
    非要浓缩在 package.json 里吗, 我看正常项目 docker 应该是独立出来的脚本处理的,
    flyingfz
        2
    flyingfz  
    OP
       2024-08-28 15:45:48 +08:00
    当然是可以单独写个 .sh 文件 做镜像的打包。

    只是, 上面那段脚本 我觉得还没有复杂到需要独立一个文件。
    assassing
        3
    assassing  
       2024-08-28 15:54:35 +08:00
    镜像命名差不多一致,不过项目这段直接体现了分支。分支代表环境,不同分支镜像隔离在不同仓库中,方便清理和权限管理。
    flyingfz
        4
    flyingfz  
    OP
       2024-08-28 16:20:01 +08:00
    是的。

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

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

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

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

    适用场景其实也有限 。
    xhawk
        5
    xhawk  
       2024-08-29 06:45:24 +08:00 via Android
    不对,这个问题有点有趣。像我这边,是用 docker compose 启动的,你这样子搞,只能说用来方便跟踪镜像产生过程,但是发布的时候你是咋弄的?
    guanzhangzhang
        6
    guanzhangzhang  
       2024-08-29 10:04:48 +08:00   1
    你这有问题,用 makefile 可以设置默认 tag 规则,要是特定暂存 tag ,你还得 vi 你这个 json 文件修改再构建镜像
    make image TAG=xxxxx
    flyingfz
        7
    flyingfz  
    OP
       2024-09-02 09:42:16 +08:00
    @xhawk 我们没有使用 docker compose 启动容器。 大部分情况下,都是为每个应用手写一个脚本启动。 确实是需要在更新部署的时候修改 tag 值。
    我的理解,如果是使用 docker compose , 那么最好每次 tag 都是 latest 会比较方便, 上面我也说过了, 这种方法适用的场景其实有限。

    @guanzhangzhang 没有了解过使用 makefile 来打包镜像,能否分享下你的场景和做法?
    guanzhangzhang
        8
    guanzhangzhang  
       2024-09-02 09:53:13 +08:00
    @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
        9
    flyingfz  
    OP
       2024-09-02 10:39:21 +08:00
    @guanzhangzhang 大概理解了你的意思。
    确实,如果使用 CI 工具,确实是放在 Makfile 里比较合适。否则 CI 里还要依赖 npm 命令。

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

    所以, 结论是,如果使用 完善的部署流程 ,这个小技巧并不适用。
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     5670 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 59ms UTC 02:51 PVG 10:51 LAX 18:51 JFK 21:51
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86