docker-selenium 浏览器镜像 Tag 体系全解析：以 Selenium Grid 4.29.0 + Chrome 100 为例

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

本文以 CHANGELOG/archived/4.29.0/chrome_100.md 中记录的一次真实发布日志为切入点，系统拆解 docker-selenium 项目中selenium/node-chrome与selenium/standalone-chrome镜像的 tag 命名规范、生成逻辑与使用方式。读者读完本文后，将能够准确读懂任意CHANGELOG/*/chrome_*.md中的 tag 输出，理解 tag_and_push_browser_images.sh 的源码实现，并在实际测试中精确锁定所需版本的镜像 tag。

背景：一份归档日志的价值

在 docker-selenium 项目中，每一次浏览器镜像发布都会产生一份独立的 Markdown 记录，保存在CHANGELOG/目录下，按 Grid 版本归档。本文聚焦的CHANGELOG/archived/4.29.0/chrome_100.md就是 Selenium Grid4.29.0发布周期中，为 Chrome100.0.4896.127生成镜像 tag 时的完整执行输出。它的原始内容如下：

./tag_and_push_browser_images.sh 4.29.0 20250303 selenium false chrome true Tagging images for browser chrome, version 4.29.0, build date 20250303, namespace selenium Selenium Grid version -> 4.29.0-20250303 Chrome version -> 100.0.4896.127 Short Chrome version -> 100.0 ChromeDriver version -> 100.0.4896.60 Short ChromeDriver version -> 100.0 Tagged selenium/node-chrome:100.0.4896.127-chromedriver-100.0.4896.60-grid-4.29.0-20250303 Tagged selenium/standalone-chrome:100.0.4896.127-chromedriver-100.0.4896.60-grid-4.29.0-20250303 Tagged selenium/node-chrome:100.0.4896.127-chromedriver-100.0.4896.60-20250303 Tagged selenium/standalone-chrome:100.0.4896.127-chromedriver-100.0.4896.60-20250303 Tagged selenium/node-chrome:100.0.4896.127-20250303 Tagged selenium/standalone-chrome:100.0.4896.127-20250303 Tagged selenium/node-chrome:100.0-chromedriver-100.0-grid-4.29.0-20250303 Tagged selenium/standalone-chrome:100.0-chromedriver-100.0-grid-4.29.0-20250303 Tagged selenium/node-chrome:100.0-chromedriver-100.0-20250303 Tagged selenium/standalone-chrome:100.0-chromedriver-100.0-20250303 Tagged selenium/node-chrome:100.0-20250303 Tagged selenium/standalone-chrome:100.0-20250303

这份输出表面看只是一串docker tag的日志，但它实际上完整展示了整个项目的镜像 tag 发布体系：一次发布如何以"Grid 版本 + 构建日期"为基准镜像（selenium/node-chrome:4.29.0-20250303），在容器内探测真实的 Chrome 与 ChromeDriver 版本，再为node-chrome与standalone-chrome两类镜像批量打上 12 个（加上未展示的 4 个旧版本 tag，共 16 个）可读性 tag。这正是 docker-selenium 让"跨浏览器测试与版本锁定"变得容易的核心机制——正如 CHANGELOG/README.md 所述，其动机是在提供最新 Selenium Grid 核心能力的同时，让用户能够按浏览器版本精确拉取镜像进行测试。

从命令看参数：一条命令如何驱动整次发布

日志第一行就是整次发布的入口：

./tag_and_push_browser_images.sh 4.29.0 20250303 selenium false chrome true

对照 tag_and_push_browser_images.sh 的脚本头部的参数声明，这 6 个位置参数分别对应：

脚本首先组合出基准版本号TAG_VERSION=${VERSION}-${BUILD_DATE}，即日志中第二行显示的Selenium Grid version -> 4.29.0-20250303。值得注意的是脚本第 16 行NAMESPACE=${NAME:-selenium}表明命名空间实际上优先读取$NAME环境变量，命令行参数$3只是兜底默认值。

在 Makefile 中，tag_and_push_browser_images目标是五个浏览器系列发布的聚合入口，它会依次调用脚本处理chrome、chrome-for-testing、chromium、edge、firefox五个分支；单独的tag_and_push_chrome_images目标则只处理 Chrome 一个系列：

tag_and_push_chrome_images: ./tag_and_push_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) chrome $(RELEASE_OLD_VERSION)

版本探测：在容器内"问"出真实版本号

tag_and_push_browser_images.sh的关键设计是：tag 中记录的浏览器与驱动版本并非人工填写，而是从已构建好的基准镜像中实时探测得到的。以 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}')

即用docker run --rm临时启动selenium/node-chrome:4.29.0-20250303，分别在容器内执行google-chrome --version与chromedriver --version，再用awk截取版本号字段，得到本文日志中的Chrome version -> 100.0.4896.127与ChromeDriver version -> 100.0.4896.60。

之后通过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]}" }

它按.切分版本字符串后取前两段，因此100.0.4896.127变为100.0，100.0.4896.60也变为100.0，对应日志中Short Chrome version -> 100.0与Short ChromeDriver version -> 100.0。

Tag 命名规范：六种组合的完整语义

将完整版本与短版本、Grid 版本与构建日期排列组合，脚本在CHROME_TAGS数组中定义了 6 种 tag 形态（tag_and_push_browser_images.sh）：

当RELEASE_OLD_VERSION=false时（即发布新版本），脚本还会额外追加 4 个不含构建日期的"浮动" tag（tag_and_push_browser_images.sh），它们会随未来版本更新而指向更新的镜像，方便用户不关心具体构建日期时快速引用：

• ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}
• ${CHROME_VERSION}
• ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}
• ${CHROME_SHORT_VERSION}

本文场景中RELEASE_OLD_VERSION=true，因此这些浮动 tag 被跳过，这与归档日志只输出 12 行Tagged记录的现象完全吻合。

这些 tag 与 docs/docker-hub/node-chrome.md 中描述的通用约定一致：镜像名selenium/node-chrome或selenium/standalone-chrome后依次可跟<Major>.<Minor>.<Patch>、<YYYYMMDD>、浏览器版本与 ChromeDriver 版本的任意排列组合，使用者可以从中选择"最简可用"或"完全锁定"的任意粒度。

从 tag 到镜像：node-chrome 与 standalone-chrome 的分工

日志中每一个 tag 都同时打在两类镜像上：selenium/node-chrome与selenium/standalone-chrome，这对应脚本末尾的循环（tag_and_push_browser_images.sh）：

for chrome_tag in "${CHROME_TAGS[@]}"; do retag node-chrome "${chrome_tag}" retag standalone-chrome "${chrome_tag}" done

两类镜像的角色差异在源码中清晰可见：

• node-chrome：基于 NodeBase/Dockerfile 构建的节点镜像，作为 Selenium Grid 的 Node 使用，通过SE_EVENT_BUS_HOST等环境变量连接 Hub/EventBus 注册自身。Chrome 与 ChromeDriver 的安装逻辑集中在 NodeChrome/Dockerfile，其中google-chrome --version | awk '{print $3}'的写法（第 70 行）正是 tag 脚本中版本探测命令的同源实现。
• standalone-chrome：基于 Standalone/Dockerfile 构建，将 Grid 服务端（Router、Distributor、SessionMap 等）与浏览器打包在同一个容器中，适合单机独立运行测试，不需要外部 Hub。

retag函数（tag_and_push_browser_images.sh）在常规路径下执行docker tag，并在PUSH_IMAGE=true时附带docker push。此外它支持PROMOTE_TAGS=true的发布晋升模式：当发布直接用测试通过的镜像而不重建时，使用docker buildx imagetools create在 registry 层直接创建多架构 manifest 别名，避免docker pull只能拉回单架构镜像的问题；若同时设置了PROMOTE_GHCR_NAMESPACE，则在同一调用中镜像到 GHCR。这也解释了为什么归档日志中的命令使用false——它只是本地打 tag 的演练/记录，真正的推送由 CI 发布流程控制。

实战：用这些 tag 锁定浏览器版本

理解了 tag 体系后，实际使用就非常直观。以本文的 Chrome 100 为例，在 CHANGELOG/README.md 的 Chrome 版本矩阵表中，Grid4.29.0行与 Chrome100列交汇处的✓正指向本文这份日志。

若你的测试环境需要精确锁定 Chrome100.0.4896.127与 ChromeDriver100.0.4896.60，可以按信息完整度递减选择 tag：

# 完全锁定：浏览器 + 驱动 + Grid 版本 + 构建日期 docker pull selenium/standalone-chrome:100.0.4896.127-chromedriver-100.0.4896.60-grid-4.29.0-20250303 # 锁定浏览器与驱动、忽略 Grid 补丁号 docker pull selenium/node-chrome:100.0.4896.127-chromedriver-100.0.4896.60 # 只锁定大版本 docker pull selenium/standalone-chrome:100.0

作为 Node 使用并连接 Hub 时（参考 docs/docker-hub/node-chrome.md）：

docker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:4.29.0-20250303 docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub --shm-size="2g" \ selenium/node-chrome:100.0.4896.127-chromedriver-100.0.4896.60-grid-4.29.0-20250303

需要特别说明的是，正如 CHANGELOG/README.md 的 Note 所述：项目并未对每个 Grid 版本与浏览器版本的组合做完整的功能回归测试，用户应根据自己的测试需求评估并选择 tag。这也正是"按浏览器版本归档 changelog"的意义——当某个浏览器版本存在已知问题时，可以方便地回溯并锁定到其上一版本，而不是被迫跟随最新版。

小结

一份看似只有命令输出的归档日志，实际上浓缩了 docker-selenium 浏览器镜像发布的完整链路：命令行参数驱动 → 容器内版本探测 → 六种 tag 形态排列组合 → node/standalone 双镜像同步打标。通过本文的源码级拆解，读者现在可以：

1. 读懂任意CHANGELOG归档中的 tag 输出，并反推其发布参数；
2. 理解 tag_and_push_browser_images.sh 的完整执行流程与RELEASE_OLD_VERSION、PROMOTE_TAGS等开关的作用；
3. 根据测试需求，在"最精确锁定"与"最简引用"之间选择合适的镜像 tag。

当你在跨浏览器测试中需要固定某一代 Chrome 版本、或排查某个浏览器版本特有的兼容问题时，这套 tag 体系就是 docker-selenium 提供给你的版本管理工具。

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