docker-selenium 浏览器镜像标签生成机制全解析：以 Chrome 117 在 Selenium Grid 4.48.0 中的发布为例

• 测试
• 后端
• 云原生
• 容器编排
• 可观测性

在 docker-selenium 项目中，每一轮浏览器版本发布都会执行tag_and_push_browser_images.sh脚本，为node-chrome与standalone-chrome等镜像批量打上可读性极强的语义化标签。本文以 CHANGELOG/4.48.0/chrome_117.md 中记录的 Chrome 117 发布日志为骨架，结合仓库内 tag_and_push_browser_images.sh 的完整实现，深入讲解标签的命名规范、版本探测逻辑、短版本截断规则以及 Makefile 的集成方式。读完本文，你将能够读懂任意一条浏览器镜像标签的含义，并能在自己的 Selenium Grid 集群中精准拉取指定 Chrome/ChromeDriver 组合的镜像。

一、一次发布日志背后的完整命令

chrome_117.md记录的是发布 Chrome 117 镜像时脚本的完整输出，其起始命令为：

./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true

对照脚本开头的参数解析（tag_and_push_browser_images.sh），这 7 个位置参数分别表示：

脚本运行时首先生成基准标签TAG_VERSION=${VERSION}-${BUILD_DATE}，即4.48.0-20260909——这也是 CI 构建阶段给所有 Grid 组件镜像（base、hub、node-chrome 等）打的统一标签。随后脚本启动node-chrome:4.48.0-20260909容器，读取内部浏览器与驱动版本：

• Chrome 版本：117.0.5938.149
• ChromeDriver 版本：117.0.5938.149

日志中第三行起依次输出Selenium Grid version -> 4.48.0-20260909、Chrome version -> 117.0.5938.149、Short Chrome version -> 117.0等，完整还原了后续打标签所需的全部版本信息。

二、十组镜像标签的命名规范深度拆解

日志第 9～20 行展示了为 Chrome 117 生成的全部 10 个标签（node-chrome与standalone-chrome各一组，共 20 条 Tagged 记录）。将其去重归类，标签体系由三类信息组合而成：

1. 长版本 + 驱动版本 + Grid 版本（定位最精确）

selenium/node-chrome:117.0.5938.149-chromedriver-117.0.5938.149-grid-4.48.0-20260909

这是信息最完整的标签：浏览器完整版本、ChromeDriver 完整版本、Grid 完整版本（含构建日期）三要素齐全，适合需要"锁定到某个具体补丁版本"的回归测试场景。

2. 长版本 + 驱动版本 + 构建日期

selenium/node-chrome:117.0.5938.149-chromedriver-117.0.5938.149-20260909

浏览器与驱动版本一致（Chrome 与 ChromeDriver 通常同源同版本），再辅以构建日期区分同版本多批次构建。

3. 浏览器版本 + 构建日期

selenium/node-chrome:117.0.5938.149-20260909

只关心浏览器主版本，驱动跟随镜像内部默认。

4. 短版本变体（117.0系列）

selenium/node-chrome:117.0-chromedriver-117.0-grid-4.48.0-20260909 selenium/node-chrome:117.0-chromedriver-117.0-20260909 selenium/node-chrome:117.0-20260909

这是short_version()函数的作用。从源码看（tag_and_push_browser_images.sh），它把完整版本号按.切分后仅保留前两段：

function short_version() { local __long_version=$1 local __version_split=(${__long_version//./ }) echo "${__version_split[0]}.${__version_split[1]}" }

117.0.5938.149→117.0。短版本标签适合粗粒度锁定大版本号（例如只想固定 117 主线的场景），在跨大版本兼容性排查时非常实用。

5. 纯净版本标签（仅在非旧版本发布时追加）

日志中的第 9～20 行没有出现这类标签，原因是本次调用第 6 个参数为true（RELEASE_OLD_VERSION=true）。当该参数为false时，脚本会额外追加 4 个不含日期、不含 Grid 版本的最简标签（tag_and_push_browser_images.sh）：

117.0.5938.149-chromedriver-117.0.5938.149 117.0.5938.149 117.0-chromedriver-117.0 117.0

RELEASE_OLD_VERSION=true的含义是：本次发布的是历史旧版浏览器（如为兼容遗留测试环境而补发的 Chrome 117），为避免selenium/node-chrome:117.0这类无日期标签与未来再次发布同版本时产生歧义，故不再追加"纯净"标签。

三、源码级原理：版本探测与标签组装

版本探测是打标签流程的前置步骤。以 Chrome 为例（tag_and_push_browser_images.sh）：

CHROME_VERSION=$(docker run --platform ${PLATFORM} --rm ${NAMESPACE}/node-chrome:${TAG_VERSION} google-chrome --version | awk '{print $3}') CHROMEDRIVER_VERSION=$(docker run --platform ${PLATFORM} --rm ${NAMESPACE}/node-chrome:${TAG_VERSION} chromedriver --version | awk '{print $2}')

这里有两个值得注意的实现细节：

• 平台参数：Chrome 分支的docker run显式携带--platform ${PLATFORM}（默认linux/amd64），保证跨架构环境下探测到的版本准确；
• 字段截取：google-chrome --version输出形如Google Chrome 117.0.5938.149，取第 3 列即版本号；chromedriver --version输出形如ChromeDriver 117.0.5938.149...，取第 2 列。

标签组装通过CHROME_TAGS数组完成（tag_and_push_browser_images.sh），数组中 6 个（RELEASE_OLD_VERSION=false 时为 10 个）模板依次展开。实际打标签由retag()函数统一处理（tag_and_push_browser_images.sh）：

function retag() { local __image=$1 local __tag=$2 local __source="${NAMESPACE}/${__image}:${TAG_VERSION}" docker tag "${__source}" "${NAMESPACE}/${__image}:${__tag}" if [ "${PUSH_IMAGE}" = true ]; then docker push "${NAMESPACE}/${__image}:${__tag}" fi }

即先对selenium/node-chrome:4.48.0-20260909打本地标签，再按PUSH_IMAGE决定是否推送。日志中 PUSH_IMAGE=false，因此 20 条输出均为本地 Tagged 记录，没有 Push 记录。

retag()还支持一种PROMOTE_TAGS=true的发布路径：当发布采用"promote（晋升）"策略时，直接用docker buildx imagetools create在 registry 与 registry 之间复制 manifest，避免在本地重建镜像——这正是 Makefile 中promote_release_images目标（Makefile）所描述"发布的 digest 就是被测试过的 digest"的核心思想。

四、Makefile 集成：一条命令驱动全部浏览器发布

tag_and_push_browser_images.sh的调用被封装在 Makefile 的tag_and_push_browser_images目标中（Makefile）：

tag_and_push_browser_images: tag_and_push_chrome_images tag_and_push_chrome-for-testing_images tag_and_push_chromium_images tag_and_push_firefox_images tag_and_push_edge_images tag_and_push_chrome_images: ./tag_and_push_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) chrome $(RELEASE_OLD_VERSION)

Makefile 顶层定义了VERSION=4.49.0、BUILD_DATE=$(CURRENT_DATE)、NAMESPACE=$(NAME)、PUSH_IMAGE=false、RELEASE_OLD_VERSION=false等变量（Makefile），可直接通过环境变量或命令行覆盖，例如：

make tag_and_push_browser_images VERSION=4.48.0 BUILD_DATE=20260909 PUSH_IMAGE=true

这意味着 5 种浏览器变体（chrome、chrome-for-testing、chromium、edge、firefox）共用同一套打标签逻辑，仅版本探测命令与标签后缀不同。以同批发布的 edge_117.md 和 firefox_117.md 为例：

日志显示 Edge 117 实际版本为117.0.2045.55，Firefox 为117.0.1（配套 geckodriver0.37.1），Chrome 为117.0.5938.149——三者主版本号均为 117，但完整补丁版本各不相同，恰好说明为什么标签中必须携带完整版本号才能做到精确区分。

五、为什么需要"Grid 版本 + 浏览器版本"双维度标签

CHANGELOG/README.md 的版本矩阵文档明确阐述了设计动机（CHANGELOG/README.md）：项目既要持续跟进最新的 Selenium Grid 核心版本，又要让用户能够把浏览器版本固定在自己需要的版本上（例如某些浏览器版本存在已知问题、或团队环境只支持特定版本时）。因此每个浏览器镜像都同时打包了 Grid 核心、驱动与浏览器，用户只需：

1. 在矩阵表（CHANGELOG/4.48.0目录下的chrome_*.md系列文件）中找到 Grid 版本与浏览器版本的交叉点；
2. 按标签命名规则拼出镜像标签；
3. 直接docker pull并启动测试。

同时该文档也给出了一个重要提醒（CHANGELOG/README.md）：项目并未对每种 Grid 与浏览器版本的组合做全量兼容性测试，用户需要根据自己的测试需求评估选择。

六、实战：如何在测试中选用 Chrome 117 镜像

在docker-compose-v3.yml或 Selenium Grid Hub + Node 部署中，直接修改镜像标签即可固定浏览器版本。例如固定使用 Chrome 117 + ChromeDriver 117 + Grid 4.48.0 的完整组合：

services: chrome: image: selenium/node-chrome:117.0.5938.149-chromedriver-117.0.5938.149-grid-4.48.0-20260909 shm_size: 2gb depends_on: - selenium-hub environment: - SE_EVENT_BUS_HOST=selenium-hub - SE_EVENT_BUS_PUBLISH_PORT=4442 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443

若只需单容器快速验证，可直接使用 Standalone 变体：

docker run -d -p 4444:4444 --shm-size=2g \ selenium/standalone-chrome:117.0.5938.149-20260909

标签选择建议：

• 需要精确复现某次测试环境 → 使用三要素完整标签（含-grid-段）；
• 需要固定主版本、容忍补丁差异→ 使用短版本标签（117.0-20260909）；
• 需要跟随 Grid 升级但锁定浏览器→ 换用新版 Grid 的chrome_117.md对应的标签。

七、镜像内的版本来源：构建期安装逻辑

浏览器与驱动版本最终由镜像构建阶段决定。NodeChrome/Dockerfile通过CHROME_VERSION与CHROME_DRIVER_VERSION两个构建参数控制（NodeChrome/Dockerfile）：

• install-chrome.sh：默认安装google-chrome-stable渠道；也支持google-chrome-stable=版本号形式精确指定 apt 版本；
• install-chromedriver.sh：默认根据已装 Chrome 的主版本号自动解析匹配的 ChromeDriver——115 以前的版本走chromedriver.storage.googleapis.com遗留接口，115 及以后从 Chrome for Testing 公共存储桶下载，非 amd64 架构则回退到 Debianchromium-driver包。

这也解释了为什么日志中 Chrome 与 ChromeDriver 版本完全一致（均为117.0.5938.149）：驱动版本默认跟随浏览器主版本自动匹配，只有显式传入CHROME_DRIVER_VERSION时才会出现两者版本不同的镜像。构建时探测逻辑（google-chrome --version | awk '{print $3}'）与打标签脚本中的探测命令保持了一致性，确保镜像内版本与标签语义严格对应。

结语

一条chrome_117.md发布日志，完整呈现了 docker-selenium 的浏览器镜像版本管理哲学：以"Grid 版本-构建日期"为基准，以"浏览器完整版本 + 驱动版本"为语义，通过长短版本两组标签为不同精度需求的使用者提供选择。理解这套标签体系后，无论是排查环境差异、复现线上问题，还是搭建跨版本兼容矩阵，你都能快速定位到正确的镜像。若需深入，可直接阅读 tag_and_push_browser_images.sh 源码，或对照 CHANGELOG/README.md 的完整版本矩阵规划自己的浏览器版本策略。

• 测试
• 后端
• 云原生
• 容器编排
• 可观测性