V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
flyingfz
V2EX  ›  Node.js

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

  •  
  •   flyingfz · 19 天前 · 1436 次点击

    在实际的项目开发时,打包 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  
       19 天前
    非要浓缩在 package.json 里吗, 我看正常项目 docker 应该是独立出来的脚本处理的,
    flyingfz
        2
    flyingfz  
    OP
       19 天前
    当然是可以单独写个 .sh 文件 做镜像的打包。

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

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

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

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

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

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

    @guanzhangzhang 没有了解过使用 makefile 来打包镜像,能否分享下你的场景和做法?
    guanzhangzhang
        8
    guanzhangzhang  
       14 天前
    @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
       14 天前
    @guanzhangzhang 大概理解了你的意思。
    确实,如果使用 CI 工具,确实是放在 Makfile 里比较合适。否则 CI 里还要依赖 npm 命令。

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

    所以, 结论是,如果使用 完善的部署流程 ,这个小技巧并不适用。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   945 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 19:34 · PVG 03:34 · LAX 12:34 · JFK 15:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.