企业官网建设流程全解析

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

本篇技术指南以仓库归档的 Chrome 112 发布记录（CHANGELOG/archived/4.28.1/chrome_112.md）为切入点，深入剖析 docker-selenium 项目镜像标签的生成脚本 tag_and_push_browser_images.sh 的完整执行逻辑、参数含义与标签命名约定。读完本文，你将掌握：如何读懂一次浏览器镜像发布的输出记录、selenium/node-chrome与selenium/standalone-chrome各标签变体的构成规则，以及在实际 Selenium Grid 测试中如何依据版本矩阵挑选并拉取精确的镜像标签。

一次发布记录：Chrome 112 镜像标签快照

在 4.28.1 版本的 Selenium Grid 发布周期中，仓库以 Chrome 112 为浏览器载体生成并归档了一组镜像标签。原始记录如下（节选自 CHANGELOG/archived/4.28.1/chrome_112.md）：

./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 -> 112.0.5615.165 Short Chrome version -> 112.0 ChromeDriver version -> 112.0.5615.49 Short ChromeDriver version -> 112.0 Tagged selenium/node-chrome:112.0.5615.165-chromedriver-112.0.5615.49-grid-4.28.1-20250202 Tagged selenium/standalone-chrome:112.0.5615.165-chromedriver-112.0.5615.49-grid-4.28.1-20250202 Tagged selenium/node-chrome:112.0.5615.165-chromedriver-112.0.5615.49-20250202 Tagged selenium/standalone-chrome:112.0.5615.165-chromedriver-112.0.5615.49-20250202 Tagged selenium/node-chrome:112.0.5615.165-20250202 Tagged selenium/standalone-chrome:112.0.5615.165-20250202 Tagged selenium/node-chrome:112.0-chromedriver-112.0-grid-4.28.1-20250202 Tagged selenium/standalone-chrome:112.0-chromedriver-112.0-grid-4.28.1-20250202 Tagged selenium/node-chrome:112.0-chromedriver-112.0-20250202 Tagged selenium/standalone-chrome:112.0-chromedriver-112.0-20250202 Tagged selenium/node-chrome:112.0-20250202 Tagged selenium/standalone-chrome:112.0-20250202

这 12 行 "Tagged" 输出并非随意生成，而是脚本根据镜像内真实安装的浏览器与驱动版本，自动组合出 6 种标签命名模式、分别作用于node-chrome与standalone-chrome两类镜像的结果。下面逐层拆解。

命令参数逐项解析

发布记录第一行就是脚本调用本身，其 7 个位置参数与 tag_and_push_browser_images.sh 顶部的变量声明一一对应：

脚本还会拼接出发布标签版本TAG_VERSION=${VERSION}-${BUILD_DATE}，即输出中反复出现的4.28.1-20250202。此外，脚本支持两个环境变量：PROMOTE_TAGS=true时改用docker buildx imagetools create在 registry 间直接复制多架构 manifest（而非本地docker tag）；PROMOTE_GHCR_NAMESPACE则在同一次调用中同步镜像到 GHCR 命名空间（见 tag_and_push_browser_images.sh 的retag()函数）。

版本探测：从运行中的容器读取真实版本

与"根据外部输入写死版本号"不同，脚本启动刚构建好的node-chrome:4.28.1-20250202容器，通过执行二进制命令并解析输出来探测浏览器与驱动版本（见 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 完整版本112.0.5615.165，经short_version()函数（按.拆分后取前两段，见 tag_and_push_browser_images.sh）得到短版本112.0；
• ChromeDriver 完整版本112.0.5615.49，短版本同样为112.0。

这也印证了镜像构建层面的版本参数：NodeChrome 的 NodeChrome/Dockerfile 中，CHROME_VERSION默认google-chrome-stable、CHROME_DRIVER_VERSION默认取最新发布版，浏览器版本与驱动版本在构建时被安装进镜像，发布时再从镜像内部探测出来。

标签命名约定：6 种模式 × 2 类镜像

脚本为 Chrome 定义了 6 个标签模式（见 tag_and_push_browser_images.sh），并按RELEASE_OLD_VERSION决定是否追加 4 个不带日期的变体。由于本次命令第 6 个参数为true（归档旧版本），只生成带日期的 6 种：

上述每种模式同时应用于node-chrome与standalone-chrome两个镜像，因此共产生 12 行 Tagged 输出。这与 docs/docker-hub/node-chrome.md 中描述的标签结构一致：既可以用selenium/node-chrome-<browserVersion>-<browserDriverVersion>-<Major>.<Minor>.<Patch>-<YYYYMMDD>精确锁定完整组合，也可以用短版本标签（如112.0-20250202）快速获取该主版本线的最新发布。

若发布的是非归档新版本（RELEASE_OLD_VERSION=false），还会额外追加112.0.5615.165-chromedriver-112.0.5615.49、112.0.5615.165、112.0-chromedriver-112.0、112.0这 4 个不带日期的"浮动"标签，让用户无需关心具体构建日期即可引用。

两类镜像形态：Node 与 Standalone

发布记录同时为node-chrome和standalone-chrome打上相同版本组合的标签，二者面向不同的部署形态：

• selenium/node-chrome：Selenium Grid 的 Node 形态，需配合 Hub（或 Router/Distributor 等 Grid 组件）使用，通过事件总线注册进网格（见 docs/docker-hub/node-chrome.md 的 Hub + Node 启动流程）；
• selenium/standalone-chrome：把 Grid 服务与浏览器打包在同一个容器中独立运行，开箱即用，适合本地调试或轻量自动化场景。

两者共享同一套 NodeChrome 镜像构建产物（NodeChrome/Dockerfile），差别仅在入口编排（可对比 Standalone/start-selenium-standalone.sh 与 NodeBase/start-selenium-node.sh）。由于 Chrome 与 ChromeDriver 的版本必须严格匹配，发布流程保证了同一日期发布的node-chrome与standalone-chrome标签指向的浏览器/驱动组合完全一致，可直接互相替代使用。

版本矩阵：为什么要有这么多 Chrome 版本标签

仓库 CHANGELOG/README.md 开篇说明了这类 changelog 的动机：让用户既能用上最新的 Selenium Grid 核心功能，又能在跨浏览器测试时固定某个浏览器版本（例如因特定浏览器版本存在兼容问题或支持受限）。因此每个 Grid 版本都维护一张"Grid 版本 × 浏览器版本"矩阵，矩阵中每个 ✓ 链接到对应浏览器版本的详细 changelog 记录。本次的 chrome_112.md 正是 4.28.1 矩阵行中 Chrome 112 列的归档详情，与之并列的还有 4.28.1 下的 Chrome 113～132、Edge 114～132、Firefox 98～134 等条目。此外，README 明确提示：项目并未对所有 Grid 与浏览器版本的组合做完整测试，使用者应根据自身测试需求评估并决定。

实战：在测试中锁定 Chrome 112 镜像

理解了标签构成后，即可在实际测试中精确选择镜像：

# 1. 创建共享网络 docker network create grid # 2. 启动 Selenium Grid Hub（4.28.1 版本） docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:4.28.1-20250202 # 3. 启动 Chrome 112 节点，推荐使用 --shm-size=2g 共享内存 docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-chrome:112.0.5615.165-chromedriver-112.0.5615.49-grid-4.28.1-20250202

若只需锁定"Chrome 112 主版本线"而不关心补丁号，可选用短版本标签：

docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-chrome:112.0-20250202

测试脚本只需指向http://localhost:4444（Grid 入口），由 Selenium 客户端按 capability 匹配browserName=chrome、browserVersion=112.0即可路由到该节点。选择标签的核心原则是：需要版本完全可复现时使用完整版本标签，需要跟随某主版本线的修复更新时使用短版本标签。

总结

从一行发布命令到 12 条镜像标签，本次 Chrome 112 发布记录完整展示了 docker-selenium 的版本管理机制：脚本 tag_and_push_browser_images.sh 通过运行容器探测浏览器与驱动真实版本，按 6 种命名模式 × 2 类镜像批量打标签，并借助 CHANGELOG/README.md 的版本矩阵为每个 Grid 版本留存可检索的归档记录。掌握这套标签生成逻辑，你就能在任何需要固定浏览器版本的 Selenium 测试环境中，快速、准确地定位并拉取所需的镜像标签。

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