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

本文基于 docker-selenium 仓库的变更记录，完整解读 Selenium Grid 4.32.0 发布中 Chrome 134 浏览器镜像的版本组合、镜像标签命名规范，以及背后tag_and_push_browser_images.sh脚本的自动化发布机制。读者可以借此掌握如何读懂并选用selenium/node-chrome与selenium/standalone-chrome镜像的各类标签，理解"浏览器版本 + ChromeDriver 版本 + Grid 版本 + 构建日期"四段式标签的含义，并学会在 Docker Compose 与测试代码中精确定位指定版本的镜像。

版本组合：Grid 4.32.0 与 Chrome 134 的精确映射

本次发布记录（见 CHANGELOG/archived/4.32.0/chrome_134.md）揭示了该版本组合的核心事实：Chrome 与 ChromeDriver 的版本号完全一致，均为134.0.6998.165，即浏览器与驱动保持严格同步的版本策略。这也正是 docker-selenium 项目"打包最新 Selenium Grid 核心版本，同时让用户能够按需锁定浏览器版本"这一设计目标的直接体现（详见 CHANGELOG/README.md 中的矩阵说明）。

其中20250515为构建日期（2025 年 5 月 15 日），它被拼接到 Grid 版本之后形成唯一标识4.32.0-20250515。在 Makefile 中可以看到该约定的定义：TAG_VERSION := $(VERSION)-$(BUILD_DATE)，所有组件镜像都以$(TAG_VERSION)作为构建期标签。

发布命令逐参数解读

变更记录中的命令是理解整个发布流程的钥匙：

./tag_and_push_browser_images.sh 4.32.0 20250515 selenium false chrome true

对照 tag_and_push_browser_images.sh 顶部的参数定义（第 3～9 行），七个位置参数的含义如下：

脚本第一步会启动基础镜像并读取容器内实际安装的浏览器与驱动版本（第 65、70 行）：

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 版本不是写死在脚本里的，而是从已构建的镜像内部探测得到的真实版本号，这保证了标签与实际二进制永远一致。随后short_version函数（第 53～57 行）将134.0.6998.165截取为134.0：

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

四段式标签体系：20 个标签的完整清单与语义

变更记录列出了node-chrome与standalone-chrome两个镜像各 10 个标签，共 20 个。这些标签由"完整版本 / 短版本 × 是否含 Grid 版本 / 是否含构建日期"组合而成，每一段都有明确的语义：

• 134.0.6998.165：浏览器（Chrome）完整版本；
• 134.0：浏览器短版本（主版本.次版本），便于批量升级或粗粒度锁定；
• chromedriver-134.0.6998.165/chromedriver-134.0：ChromeDriver 版本；
• grid-4.32.0-20250515：Selenium Grid 完整版本；
• 20250515：构建日期。

对照 tag_and_push_browser_images.sh 第 75～99 行的CHROME_TAGS数组可以确认：前 6 类标签（含构建日期或 Grid 版本）总是生成；而第 7～10 类裸版本标签仅在RELEASE_OLD_VERSION="false"时才追加生成。本次发布命令中第 6 个参数为true，意味着这是为已经归档的旧版本 4.32.0 补发带日期与 Grid 信息的完整标签，不覆盖裸版本标签的既有指向。

每次打标签都由retag函数（第 31～51 行）完成：常规路径执行docker tag，若PUSH_IMAGE=true则追加docker push；而发布流程中另一种PROMOTE_TAGS=true的路径则使用docker buildx imagetools create实现"registry 到 registry"的索引级复制，以保留多架构清单的完整性。

从源码看镜像的构建链路

这批标签所指向的镜像本身由 Makefile 的构建目标逐层产出：

• chrome目标（chrome: node_base chrome_only）在./NodeChrome目录构建node-chrome:$(TAG_VERSION)；
• standalone_chrome目标（standalone_chrome: chrome standalone_chrome_only）在./Standalone目录以--build-arg BASE=node-chrome为基础叠加 Selenium Server，产出standalone-chrome:$(TAG_VERSION)；
• tag_and_push_chrome_images目标（Makefile 第 783～784 行）把$(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE)透传给脚本，与变更记录中的命令完全对应。

在 NodeChrome/Dockerfile 中可以看到浏览器组件的落地细节：

• ARG CHROME_VERSION="google-chrome-stable"（第 18 行）：默认安装 Chrome 稳定版，也可通过构建参数切换google-chrome-beta/google-chrome-unstable；
• install-chrome.sh负责安装浏览器，install-chromedriver.sh负责安装 ChromeDriver；
• 构建期会把实际版本写入/opt/selenium/browsers/chrome/version（第 65～71 行），google-chrome --version | awk '{print $3}'的解析方式与发布脚本完全一致；
• 同时写入binary_location配置（第 72 行），供 Selenium Grid 注册浏览器能力时使用。

此外，NodeChrome/Dockerfile 还设置了SE_NODE_ENABLE_MANAGED_DOWNLOADS="true"，允许 Grid 按需管理浏览器与驱动组件的自动同步。

实战：如何选用与验证 Chrome 134 镜像

方式一：直接拉取并验证版本

node-chrome适用于以 Node 形式加入 Selenium Grid 的分布式部署；standalone-chrome则在一个容器内同时运行 Grid 服务与浏览器，适合独立测试环境。拉取后可以复现发布脚本的探测逻辑来校验版本：

# 拉取精确版本组合的镜像 docker pull selenium/standalone-chrome:134.0.6998.165-chromedriver-134.0.6998.165-grid-4.32.0-20250515 # 验证浏览器版本（注意 awk 取第 3 段字段，与脚本一致） docker run --rm selenium/node-chrome:134.0-20250515 google-chrome --version # 验证 ChromeDriver 版本 docker run --rm selenium/node-chrome:134.0-20250515 chromedriver --version

方式二：通过 Docker Compose 引用

仓库根目录的 docker-compose-v3.yml 展示了 compose 文件中引用带构建日期标签的标准写法：

services: chrome: image: selenium/node-chrome:4.32.0-20250515 shm_size: 2gb depends_on: - selenium-hub environment: - SE_EVENT_BUS_PUBLISH_PORT=4442 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443

若希望在分布式 Grid 中固定到 Chrome 134，可将上述标签替换为变更记录中任一134.0前缀的完整标签（例如selenium/node-chrome:134.0-20250515），即可实现"Grid 版本可升级、浏览器版本稳定不变"的隔离策略。

方式三：按版本矩阵查找可用组合

Selenium Grid × 浏览器版本矩阵 以"Grid 版本 × 浏览器版本"二维表的形式列出所有已发布的组合，每个✓链接到对应版本的详细变更记录。需要留意矩阵中的说明：项目并不保证每种 Grid 与浏览器组合都经过完整测试，用户应根据自身测试需求评估选用。

归档与追溯：为什么 4.32.0 的 Chrome 134 位于 archived 目录

本变更记录位于CHANGELOG/archived/4.32.0/，说明 4.32.0 属于已归档的 Grid 版本线。归档目录保留了该版本全量浏览器组合的发布痕迹（如同目录的 chrome_133.md 记录了 Chrome 133 的对应发布），而当前 Grid 版本线则位于CHANGELOG/4.48.0/（如 CHANGELOG/4.48.0/chrome_134.md），其标签结构与本文所述完全一致。这种"当前版本 + 归档版本"的双层组织，既保证了新版本的持续发布，又让历史版本的可复现性不被破坏——用户在任何时候都能通过归档记录找到当年测试通过的那一个精确镜像标签。

小结

通过这份变更记录，可以完整还原 docker-selenium 项目的一次浏览器镜像发布：脚本从已构建镜像中探测真实版本、生成短版本、按四段式规则组合出 20 个标签，再逐一打标（可选推送）。134.0.6998.165与 Grid4.32.0-20250515的精确绑定，为"跨浏览器测试"和"锁定特定浏览器版本"两类典型场景提供了可复现、可追溯的镜像定位手段。当你需要在自动化测试中固定 Chrome 版本时，优先从 版本矩阵 或对应归档变更记录中查找精确标签，即可避免因浏览器滚动升级带来的不确定性。

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