企业官网建设流程全解析

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

本指南以仓库中CHANGELOG/archived/4.32.0/chrome_98.md记录的真实发布日志为主线，完整解析 docker-selenium 项目如何通过tag_and_push_browser_images.sh为"固定 Chrome 版本 + 最新 Selenium Grid"组合生成并发布 Docker 镜像标签。读完本文，你将掌握该脚本的参数含义、版本探测逻辑、标签命名约定、docker tag/docker push的底层实现，以及如何在实际测试中正确选择并拉取对应镜像。

为什么需要"旧浏览器 + 新 Grid"的镜像组合

在 docker-selenium 仓库的 CHANGELOG/README.md 中明确说明了这套版本矩阵的设计动机：项目希望持续供应最新的 Selenium Grid 核心版本以引入新功能，同时让用户能够基于特定浏览器版本进行测试——例如跨浏览器测试，或因为某些浏览器版本存在兼容问题而需要锁定旧版本。因此，仓库同时交付 Node 与 Standalone 两类镜像，将 Grid、浏览器、浏览器驱动打包在一起，用户只需找到镜像标签、拉取镜像即可开始测试。

CHANGELOG/archived/4.32.0/目录正是这一策略的产物：它记录了 Grid 4.32.0 版本对 Chrome 95 至 134 等一批浏览器版本的打包发布过程。其中 chrome_98.md 记录的是一次典型的发布执行日志——对 Chrome 98.0.4758.102 这一早已停止更新的旧版本，重新打包进当时最新的 Grid 4.32.0。

归档目录本身由 CHANGELOG/generate-matrix-readme.py 维护：脚本会按语义化版本排序，将除最新版本外的所有 Grid 版本目录移动到archived/下，再扫描所有*_<version>.md文件自动生成 README 版本矩阵表。也就是说，这份日志不仅是历史记录，更是版本矩阵可追溯性的来源。

发布命令与七个位置参数

chrome_98.md记录的完整命令如下：

./tag_and_push_browser_images.sh 4.32.0 20250515 selenium false chrome true

对照 tag_and_push_browser_images.sh 顶部的参数解析逻辑，该脚本共接受 7 个位置参数：

脚本开始时会输出Tagging images for browser chrome, version 4.32.0, build date 20250515, namespace selenium，随后进入chrome)分支。

从镜像内部探测真实版本号

打标签前，脚本必须先确认镜像里实际安装的 Chrome 与 ChromeDriver 版本。这一步通过运行镜像内的可执行文件并用awk抽取版本号实现（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 时使用--platform ${PLATFORM}，保证在非 amd64 的构建机上也能探测正确架构的镜像；
• --rm使探测容器运行后立即清理；
• awk '{print $3}'从Google Chrome 98.0.4758.102这类输出中取出版本号，因此日志中打印出Chrome version -> 98.0.4758.102；
• ChromeDriver 输出形如ChromeDriver 98.0.4758.102 (...)，故用awk '{print $2}'取第二列。

随后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]}" }

它按.拆分后取前两段，得到98.0。日志中Short Chrome version -> 98.0、Short ChromeDriver version -> 98.0即由此而来。短版本标签的价值在于：当 Chrome 发布补丁版本（如 98.0.4758.103）时，指向98.0的浮动标签会自动跟着新的补丁版本走，适合不想频繁改配置的用户。

探测到的版本之所以与安装脚本一致，可追溯到镜像构建链：NodeChrome/Dockerfile 通过ARG CHROME_VERSION（默认google-chrome-stable）控制安装的 Chrome，并调用install-chrome.sh；NodeChrome/install-chrome.sh 支持google-chrome-stable=<具体版本>形式从版本归档下载对应.deb精确安装，从而保证镜像内版本可被锁定与复现。

标签组合规则：同一镜像生成 12 个标签

日志显示 Chrome 分支在RELEASE_OLD_VERSION=true模式下生成了 12 个标签（tag_and_push_browser_images.sh），可分为三类：

1. 完整版本 + Grid 完整标识（形如98.0.4758.102-chromedriver-98.0.4758.102-grid-4.32.0-20250515）：浏览器、驱动、Grid、构建日期全部精确到点，可复现性最强；
2. 完整版本 + 构建日期（如98.0.4758.102-chromedriver-98.0.4758.102-20250515、98.0.4758.102-20250515）：省略 Grid 版本但保留日期；
3. 短版本 + 构建日期/Grid（如98.0-chromedriver-98.0-grid-4.32.0-20250515、98.0-chromedriver-98.0-20250515、98.0-20250515）：使用两位短版本号。

由于RELEASE_OLD_VERSION=true，脚本跳过第 88-99 行的"浏览器版本 + 浏览器驱动版本（不带日期）"一类浮动标签（例如纯98.0.4758.102、纯98.0），避免旧版本镜像携带误导性的浮动标签。这与日志输出完全吻合：12 个标签全部带20250515或grid-4.32.0-20250515后缀。

循环体对node-chrome与standalone-chrome两个镜像名各执行一次retag（tag_and_push_browser_images.sh），因此日志共出现 24 行Tagged ...。

retag 的两种模式：docker tag 与 buildx imagetools

retag()函数（tag_and_push_browser_images.sh）是打标签的核心实现，支持两种模式：

• 常规模式（PROMOTE_TAGS=false）：执行docker tag "${NAMESPACE}/${__image}:${TAG_VERSION}" "${NAMESPACE}/${__image}:${__tag}"，在本地给已构建镜像追加别名；若PUSH_IMAGE=true则再执行docker push。本次日志中PUSH_IMAGE=false，因此只产生Tagged ...输出而不推送。
• 发布提升模式（PROMOTE_TAGS=true）：当 CI 发布时直接推广其测试过的镜像而非重新构建时，本地仓库没有对应镜像，docker tag无法工作，且docker pull只能拉回运行者架构导致单架构标签。此时改用docker buildx imagetools create在镜像索引层（registry 到 registry）直接创建多架构标签，并可通过PROMOTE_GHCR_NAMESPACE在同一调用中同时镜像到 GHCR 命名空间。

实战：如何根据标签拉取与运行 Chrome 98 镜像

结合 docs/docker-hub/node-chrome.md 中的标签约定说明，本次发布的核心可用标签为：

• 精确锁定：selenium/node-chrome:98.0.4758.102-chromedriver-98.0.4758.102-grid-4.32.0-20250515
• 按浏览器主版本锁定：selenium/node-chrome:98.0-20250515
• Standalone 变体同理替换镜像名为selenium/standalone-chrome

典型的 Hub + Node 运行方式（注意浏览器镜像需使用--shm-size=2g）：

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:98.0-20250515

随后将 WebDriver 测试指向http://localhost:4444即可。该文档同时提醒：项目中并未对每一个 Grid × 浏览器组合做完整测试验证（CHANGELOG/README.md 中的 Note 也声明了这一点），用户在锁定旧浏览器版本时，应根据自身测试需求评估该组合的可用性——这也正是"固定版本标签"存在的意义：把选择权交给用户。

小结

CHANGELOG/archived/4.32.0/chrome_98.md看似只是一段 24 行的命令日志，实则是 docker-selenium 版本矩阵发布机制的一个完整切片：它串联起参数解析（tag_and_push_browser_images.sh）、镜像内版本探测、短版本截取、12 类标签组合、retag的双模式实现，以及 CHANGELOG/README.md 与 CHANGELOG/generate-matrix-readme.py 组成的矩阵归档体系。对于需要在 Selenium Grid 上固定 Chrome 98 这类旧浏览器版本的测试团队，理解这套标签语义，即可在"版本可复现"与"标签简洁性"之间做出合适的选择。

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