docker-selenium 镜像标签体系与浏览器版本锁定实战：从 Chrome 100 × Selenium Grid 4.28.1 发布记录看标签生成原理

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

在 Selenium Grid 的容器化部署中，镜像标签是"浏览器版本 + 驱动版本 + Grid 版本 + 构建日期"四种信息的组合体，理解其命名规律是精准锁定测试环境的必备技能。本文以 docker-selenium 仓库中CHANGELOG/archived/4.28.1/chrome_100.md这份真实发布记录为线索，完整还原 Chrome 100 镜像在 Selenium Grid 4.28.1 发布批次中的全部标签集合，并深入tag_and_push_browser_images.sh源码，讲清每个标签的生成逻辑、参数含义与使用场景。读完本文，你将能够根据需求从 12 个候选标签中准确挑选镜像，也能独立复现整个打标签发布流程。

发布记录原文：一次打标签任务的完整输出

CHANGELOG/archived/4.28.1/chrome_100.md记录了 2025 年 2 月 2 日（构建日期20250202）为 Chrome 100 生成镜像标签的完整命令输出，这是理解整个标签体系的原始素材：

./tag_and_push_browser_images.sh 4.28.1 20250202 selenium false chrome true Tagging images for browser chrome, version 4.28.1, build date 20250202, namespace selenium Selenium Grid version -> 4.28.1-20250202 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.28.1-20250202 Tagged selenium/standalone-chrome:100.0.4896.127-chromedriver-100.0.4896.60-grid-4.28.1-20250202 Tagged selenium/node-chrome:100.0.4896.127-chromedriver-100.0.4896.60-20250202 Tagged selenium/standalone-chrome:100.0.4896.127-chromedriver-100.0.4896.60-20250202 Tagged selenium/node-chrome:100.0.4896.127-20250202 Tagged selenium/standalone-chrome:100.0.4896.127-20250202 Tagged selenium/node-chrome:100.0-chromedriver-100.0-grid-4.28.1-20250202 Tagged selenium/standalone-chrome:100.0-chromedriver-100.0-grid-4.28.1-20250202 Tagged selenium/node-chrome:100.0-chromedriver-100.0-20250202 Tagged selenium/standalone-chrome:100.0-chromedriver-100.0-20250202 Tagged selenium/node-chrome:100.0-20250202 Tagged selenium/standalone-chrome:100.0-20250202

这份记录看似只是一段日志，实际上是两个关键事实的档案：

1. 版本对应关系：在 Selenium Grid 4.28.1-20250202 这个发布批次中，node-chrome与standalone-chrome镜像内封装的 Chrome 版本为100.0.4896.127，ChromeDriver 版本为100.0.4896.60。当你的测试需要精确复现"Chrome 100 环境"时，这就是可追溯的权威来源。
2. 标签命名规律：同一镜像被打了 6 种标签（每种同时作用于 node 与 standalone 两种镜像，共 12 个），从"全版本全信息"到"短版本短信息"层层递进。

标签体系全景：从"最全"到"最简"的 6 层设计

对照tag_and_push_browser_images.sh中CHROME_TAGS数组的定义，上面 12 个标签可以归纳为 6 类命名模式（下文以 node 镜像为例）：

其中"短版本"（short version）由脚本中的short_version函数生成，逻辑是取版本号前两段：

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

见 tag_and_push_browser_images.sh#L53-L57。因此100.0.4896.127变为100.0，100.0.4896.60变为100.0。短标签的价值在于：当你不关心 Patch 版本差异、只想锁定"Chrome 100 系列"时，selenium/node-chrome:100.0-20250202这样的标签足够简洁且可读。

版本探测：标签中的数字从哪里来

标签里的 Chrome 与 ChromeDriver 版本号并非人工填写，而是脚本在构建后通过容器内命令实时探测得到的。以 chrome 分支为例（tag_and_push_browser_images.sh#L63-L73）：

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}')

也就是说，先以基础标签selenium/node-chrome:4.28.1-20250202运行容器，分别执行google-chrome --version和chromedriver --version，再用awk提取版本字段。探测结果直接进入本次发布的输出：Chrome 100.0.4896.127、ChromeDriver 100.0.4896.60。

这一设计保证了标签与镜像内容永远一致：无论 Dockerfile 中的安装脚本如何解析上游版本，最终标签都以容器内真实二进制为准，避免了"标签写 100.0 但实际装的是 99.0"之类的错位。

为何只打了 6 类标签：RELEASE_OLD_VERSION 开关

细心的读者会发现：本次记录没有生成100.0.4896.127-chromedriver-100.0.4896.60、100.0.4896.127、100.0这类"不含构建日期"的标签。原因是脚本中这段条件逻辑（tag_and_push_browser_images.sh#L88-L99）：

if [ "${RELEASE_OLD_VERSION}" = "false" ]; then CHROME_TAGS+=( # Browser version and browser driver version ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION} # Browser version ${CHROME_VERSION} # Browser version and browser driver version ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION} # Browser version ${CHROME_SHORT_VERSION} ) fi

本次调用命令为./tag_and_push_browser_images.sh 4.28.1 20250202 selenium false chrome true，第 6 个位置参数RELEASE_OLD_VERSION未传（脚本默认值为false，见 tag_and_push_browser_images.sh#L8），因此不追加这 4 类"旧版本标签"。此开关的设计意图是：当一个浏览器版本已经很老、不再建议直接使用（Chrome 100 已远超常见测试范围）时，避免生成会让人误以为"当前推荐版本"的裸版本号标签，引导用户使用带构建日期的精确标签。

顺带说明命令的完整参数表（tag_and_push_browser_images.sh#L3-L13）：

打标签的执行链路：retag 函数与发布集成

每个标签最终通过retag函数落地（tag_and_push_browser_images.sh#L31-L51），其核心是：

docker tag "${NAMESPACE}/${__image}:${TAG_VERSION}" "${NAMESPACE}/${__image}:${__tag}" echo "Tagged ${NAMESPACE}/${__image}:${__tag}" if [ "${PUSH_IMAGE}" = true ]; then docker push "${NAMESPACE}/${__image}:${__tag}" fi

即先以TAG_VERSION（如4.28.1-20250202）为源镜像，为每个新标签打一次docker tag；若第 4 个参数为true则随后逐个docker push。脚本对每个标签同时作用于node-chrome与standalone-chrome两种镜像（tag_and_push_browser_images.sh#L101-L104），这就是为什么输出中每个标签成对出现。

在发布流程中，该脚本通过Makefile的tag_and_push_browser_images目标统一调度，该目标依赖tag_and_push_chrome_images等五个子目标，依次处理 chrome、chrome-for-testing、chromium、firefox、edge 五类浏览器镜像，每次调用传入$(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE)与对应浏览器名。此外脚本还支持PROMOTE_TAGS=true模式，此时改用docker buildx imagetools create在 registry 与 registry 之间直接复制多架构 manifest，而非本地打标签——这是"发布时直接复用测试过的镜像"的场景（tag_and_push_browser_images.sh#L31-L44）。

镜像侧的证据：Chrome 版本如何进入容器

标签所依赖的容器内 Chrome 由NodeChrome/Dockerfile构建。构建时通过ARG CHROME_VERSION="google-chrome-stable"（NodeChrome/Dockerfile#L18）控制安装渠道，执行install-chrome.sh完成安装；随后在镜像内写入浏览器信息目录：

RUN mkdir -p /opt/selenium/browsers/chrome \ && echo "chrome" > /opt/selenium/browsers/chrome/name \ && if [ "${INSTALL_CFT}" = "true" ]; then \ google-chrome --version | awk '{print $5}' > /opt/selenium/browsers/chrome/version; \ else \ google-chrome --version | awk '{print $3}' > /opt/selenium/browsers/chrome/version; \ fi

见 NodeChrome/Dockerfile#L62-L72。注意这里同样是用google-chrome --version的输出写入版本文件，与打标签脚本的探测方式完全一致——两条链路共享同一事实来源，保证了 changelog 记录、镜像标签与容器内/opt/selenium/browsers/chrome/version三者的版本号严格对齐。ChromeDriver 则由install-chromedriver.sh安装，可通过ARG CHROME_DRIVER_VERSION指定版本（NodeChrome/Dockerfile#L45-L51）。

使用场景：如何按需挑选标签

docs/docker-hub/node-chrome.md中给出了标签使用的完整约定：推荐使用完整标签来固定浏览器与 Grid 版本。对照本文的发布记录，可归纳出三个典型选择：

1. 复现精确环境（回归测试 / Bug 复现）

docker pull selenium/node-chrome:100.0.4896.127-chromedriver-100.0.4896.60-grid-4.28.1-20250202

六段式标签同时锁定浏览器、驱动、Grid 与构建日期，是唯一精确到单次构建的选择。

2. 锁定浏览器主版本（跨构建稳定性）

docker pull selenium/node-chrome:100.0-20250202

短版本 + 构建日期，锁定"Chrome 100 系列"，容忍 Patch 升级。

3. 与 Hub 组成 Grid（Hub + Node 模式）

docker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:latest 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.28.1-20250202

Hub 与 Node 在同一网络内通过容器名互相发现，--shm-size=2g是运行含浏览器镜像时的重要参数（详见 docs/docker-hub/node-chrome.md）。

注意：仓库官方明确提示，并未对每一种 Grid 版本与浏览器版本的组合做全量兼容性测试（见 CHANGELOG/README.md），选定标签后应结合自身测试用例先行验证。

归档机制：为什么这份记录位于 archived 目录

chrome_100.md位于CHANGELOG/archived/4.28.1/而非当前版本目录，这是CHANGELOG/generate-matrix-readme.py的归档逻辑所致：当出现更新的 Grid 版本时，脚本会把旧版本目录整体移入archived/，保持CHANGELOG/README.md中"Latest Grid Version"只展示最新版本。同时脚本通过扫描各版本目录下的*.md文件名（匹配([\w-]+)_(\d+)\.md）自动生成版本矩阵表，矩阵中每个 ✓ 都链接到对应的 changelog 文件（CHANGELOG/generate-matrix-readme.py#L59-L67）。这份chrome_100.md正是矩阵中"4.28.1 行 × Chrome 100 列"交叉点的内容载体，是可检索、可追溯的版本档案。

在CHANGELOG/README.md的归档矩阵中可以看到，4.28.1 是 Chrome 100 可用的最后一个 Grid 版本批次，此后 Chrome 100 不再出现在更新的 Grid 版本中——这从另一个侧面印证了标签中RELEASE_OLD_VERSION=false的设计合理性：历史浏览器版本应通过归档记录精确引用，而不是在最新发布中继续泛滥成无日期的裸标签。

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