企业官网建设流程全解析

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

本篇技术指南以 docker-selenium 仓库归档变更记录 CHANGELOG/archived/4.34.0/chrome_108.md 中 Chrome 108 的完整打标签日志为骨架，结合仓库根目录发布脚本 tag_and_push_browser_images.sh、CHANGELOG/README.md 版本矩阵与 Makefile 构建目标，逐行解读selenium/node-chrome、selenium/standalone-chrome镜像那 20 个标签的生成逻辑、命名规则与实战选取方法。读完你既能读懂这套「浏览器版本 × Selenium Grid 版本」矩阵背后的自动化发布流程，也能熟练挑选并验证适合自己测试场景的镜像标签。

一、变更记录在版本矩阵中的位置与阅读方式

该文档属于CHANGELOG/archived/4.34.0/目录下的归档变更记录，其主题为：Selenium Grid 4.34.0 发布周期内，为 Chrome 108（108.0.5359.124）与 ChromeDriver 108（108.0.5359.71）生成的镜像标签清单。

在 CHANGELOG/README.md 的「Archived Grid Versions > Chrome」矩阵中，4.34.0一行覆盖了从 Chrome 137 一路回溯到 Chrome 95 的诸多版本（其中 135、138 等个别版本空缺），chrome_108.md就是这一行里 Chrome 108 单元格（✓）链接指向的详细变更记录。矩阵的阅读约定是：最新 Grid 版本在前，浏览器版本按数字降序排列，每个 ✓ 链接到对应 Grid 版本 × 浏览器版本组合的详细日志。

这份矩阵存在的动机在 CHANGELOG/README.md 中写得很清楚：在持续供给最新 Selenium Grid 核心功能的同时，允许用户出于跨浏览器测试、或因特定浏览器版本存在兼容问题而需要固定浏览器版本等诉求，按需选择历史浏览器版本。仓库为 Node 与 Standalone 两类镜像同时打包 Grid 与指定的驱动/浏览器版本，用户只需找到标签、拉取镜像即可开始测试。矩阵文档同时提示：并非每个 Grid × 浏览器组合都经过完整测试验证，使用者需按自身测试要求自行评估——这是阅读任何一条 changelog 前都应记住的前提。

二、命令行入口与每个参数的语义

chrome_108.md的第一行给出了触发本次打标签动作的完整命令：

./tag_and_push_browser_images.sh 4.34.0 20250727 selenium false chrome true

对照 tag_and_push_browser_images.sh 顶部的参数解析，7 个位置参数依次为：

日志第 2 行输出的Selenium Grid version -> 4.34.0-20250727正是TAG_VERSION=${VERSION}-${BUILD_DATE}（脚本第 15 行）的展开结果，之后的每一行Tagged ...都对应一次 retag() 调用。

三、版本来源：镜像自身是唯一事实来源

日志第 3、5 行给出了两组关键版本号：Chrome 108.0.5359.124、ChromeDriver 108.0.5359.71（短版本号均为 108.0）。它们并非硬编码在脚本里，而是在打标签之前实时从已构建好的selenium/node-chrome:4.34.0-20250727镜像中探测出来的（脚本第 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}')

即：临时启动 node-chrome 容器，分别执行google-chrome --version与chromedriver --version，再用awk提取输出中的第 3、第 2 个字段得到精确版本号。随后short_version()函数（脚本第 53-57 行）按.切分版本号并取前两段，得到短版本108.0。这种方式保证了「镜像里实际装的浏览器版本」与「标签上宣称的版本」永远一致，不会出现脚本里手写版本号与镜像内容漂移的问题。

这些版本号最终落盘于镜像的构建阶段——NodeChrome/Dockerfile 中会执行google-chrome --version | awk '{print $3}'将版本写入/opt/selenium/browsers/chrome/version，并在binary_location中登记 Chrome 可执行文件路径，Node 启动时据此向 Grid 注册能力（capabilities）。

四、标签矩阵全解码：20 个标签的完整含义

日志中除版本探测与提示行外，共输出 20 行Tagged：node-chrome 与 standalone-chrome 各 10 个标签。这正是脚本第 101-104 行的循环行为：

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

CHROME_TAGS数组（脚本第 75-99 行）在RELEASE_OLD_VERSION=true时共 10 个元素，按日志顺序解码如下：

其中第 1～6 个标签无条件生成；第 7～10 个标签仅当RELEASE_OLD_VERSION != false时追加（脚本第 88-99 行）。就本次命令而言，true意味着这是一次为历史/旧版本 Chrome 补全「干净」标签的归档操作：让用户可以直接使用selenium/node-chrome:108.0、selenium/standalone-chrome:108.0这类简洁标签，而不必携带冗长的 Grid 版本与构建日期。

每个retag调用的执行细节（脚本第 31-51 行）：默认路径下使用docker tag将NAMESPACE/${image}:${TAG_VERSION}打上新标签，PUSH_IMAGE=true时再对每个标签执行docker push；若PROMOTE_TAGS=true（由 CI 的 deploy 流程设置），则改用docker buildx imagetools create直接在 registry 之间为多架构 manifest 建立别名，避免docker pull只带回 runner 单一架构镜像的问题。

五、为什么需要一整套标签：固定浏览器版本的实战价值

从使用者的角度看，这 10 类标签分别服务于不同诉求：

• 跨浏览器矩阵测试：用短版本标签（如108.0）即可锁定 Chrome 主版本，配合其它浏览器镜像构建兼容性矩阵；
• 精确复现缺陷：用完整版本标签（如108.0.5359.124-chromedriver-108.0.5359.71）同时锁定浏览器与驱动补丁版本，排除「驱动与浏览器不完全匹配」的干扰；
• 追溯构建产物：带构建日期的标签（如108.0.5359.124-20250727）让镜像与某次具体发布强绑定，便于审计与回滚；
• 严格复现发布环境：...-grid-4.34.0-20250727完整三元组标签把 Grid、浏览器、驱动、构建日期一次性全部钉死，适合需要在与 CI 完全相同环境里复现问题的场景。

注意node-chrome与standalone-chrome的差异：前者是Node 镜像，需要搭配 Router/Hub 组成分布式 Grid；后者是Standalone 镜像，单容器内即包含完整的 Selenium Grid 与浏览器，适合本地开发或小规模并行。因此同一套版本组合会被同时打到两种镜像上，日志中每个 node-chrome 标签之后紧跟同名的 standalone-chrome 标签。

六、与构建工作流的衔接：Makefile 中的调用链

这条命令不会在发布流程中单独出现，而是由 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_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) chrome $(RELEASE_OLD_VERSION)

tag_and_push_browser_images目标会依次对 chrome、chrome-for-testing、chromium、edge、firefox 五个浏览器分支执行同一脚本（对应脚本第 61-285 行 case 分支，各分支的版本探测命令与标签数组结构完全同构，仅浏览器/驱动命令与字段位置不同）。当某次发布需要「复用已经测试通过的镜像而不是重建」时，通过PROMOTE_TAGS=true走 imagetools 路径；而像 Chrome 108 这类历史版本的归档日志，则对应RELEASE_OLD_VERSION=true的补标签场景，即本次chrome_108.md记录的内容。

七、如何在你的测试中选用这些标签

结合 tests/docker-compose-v3-test-standalone.yml 等仓库自带的示例编排文件，选用方式非常直接：

# 拉取并运行 Standalone Chrome 108（短版本标签，最常用） docker run -d -p 4444:4444 --shm-size="2g" selenium/standalone-chrome:108.0 # 精确锁定浏览器与驱动补丁版本 docker run -d -p 4444:4444 --shm-size="2g" \ selenium/standalone-chrome:108.0.5359.124-chromedriver-108.0.5359.71 # 以 Node 形态接入已有 Grid（需替换为你的 Hub/Router 地址） docker run -d --shm-size="2g" -e SE_EVENT_BUS_PUBLISH_PORT=4442 \ selenium/node-chrome:108.0

启动后，可用仓库根目录的 check-grid.sh 同款逻辑（curl http://localhost:4444/wd/hub/status）验证 Grid 就绪状态，再向/wd/hub发送标准的 WebDriver 请求，声明browserName: chrome、browserVersion: 108.0即可让 Grid 调度到对应节点。若测试脚本对browserVersion有精确匹配要求，直接使用完整版本标签对应的镜像最稳妥——这正是本文第三节所述「版本由镜像自身探测生成」这一设计的意义所在。

结语

一条看似只有 21 行打标签日志的归档 changelog，背后是 docker-selenium 一整套「镜像版本自探测 + 多级标签矩阵 + 双镜像同步」的发布机制。理解 tag_and_push_browser_images.sh 的标签构造规则，就等于掌握了 CHANGELOG 矩阵每一格 ✓ 的生成原理，也就能在跨浏览器测试、缺陷复现与版本归档等场景中，从数百个候选标签里准确挑出恰好满足需求的那一个。

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