解读 docker-selenium 浏览器镜像标签自动化发布：以 Chrome 121 + Selenium Grid 4.33.0 为例

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

Selenium Grid 的 Docker 镜像发布不仅是"构建一次、推一个 latest"，其核心机制是为同一份镜像内容生成一组精确到浏览器版本、驱动版本、Grid 版本与构建日期的多级标签，供用户按需锁定。本文以仓库归档的 chrome_121.md 这份标签发布日志为线索，逐位拆解tag_and_push_browser_images.sh的命令参数、6 类标签的语义、脚本内部实现以及这些版本信息在 NodeChrome 镜像中的来源，读完即可独立读懂仓库中任意一份CHANGELOG/*/chrome_*.md日志，并能据此为自己的测试环境选择或组合出精确的镜像标签。

这份 Changelog 记录了什么

归档于 CHANGELOG/archived/4.33.0/chrome_121.md 的文档本身是一段完整的命令执行日志，其原始内容如下：

./tag_and_push_browser_images.sh 4.33.0 20250606 selenium false chrome true Tagging images for browser chrome, version 4.33.0, build date 20250606, namespace selenium Selenium Grid version -> 4.33.0-20250606 Chrome version -> 121.0.6167.184 Short Chrome version -> 121.0 ChromeDriver version -> 121.0.6167.184 Short ChromeDriver version -> 121.0 Tagged selenium/node-chrome:121.0.6167.184-chromedriver-121.0.6167.184-grid-4.33.0-20250606 Tagged selenium/standalone-chrome:121.0.6167.184-chromedriver-121.0.6167.184-grid-4.33.0-20250606 Tagged selenium/node-chrome:121.0.6167.184-chromedriver-121.0.6167.184-20250606 Tagged selenium/standalone-chrome:121.0.6167.184-chromedriver-121.0.6167.184-20250606 Tagged selenium/node-chrome:121.0.6167.184-20250606 Tagged selenium/standalone-chrome:121.0.6167.184-20250606 Tagged selenium/node-chrome:121.0-chromedriver-121.0-grid-4.33.0-20250606 Tagged selenium/standalone-chrome:121.0-chromedriver-121.0-grid-4.33.0-20250606 Tagged selenium/node-chrome:121.0-chromedriver-121.0-20250606 Tagged selenium/standalone-chrome:121.0-chromedriver-121.0-20250606 Tagged selenium/node-chrome:121.0-20250606 Tagged selenium/standalone-chrome:121.0-20250606

这份日志完整记录了一次"为 Selenium Grid 4.33.0（构建日期 20250606）补充 Chrome 121 系列镜像标签"的操作。12 行Tagged输出并不是 12 个互不相关的标签，而是6 种标签模式 × 2 个镜像（node-chrome与standalone-chrome）的排列结果。理解这 6 种模式，就理解了 docker-selenium 整个浏览器镜像标签体系的设计思路：让用户既能通过完整版本号精确锁定，也能通过主次版本号快速引用。

命令参数逐位拆解

日志第一行是脚本的完整调用，7 个位置参数与 tag_and_push_browser_images.sh 开头的参数解析一一对应：

脚本内部将VERSION与BUILD_DATE拼接为TAG_VERSION=4.33.0-20250606，这就是日志第二行 "Selenium Grid version -> 4.33.0-20250606" 的来源。第 3~6 行是脚本在构建机上通过容器探测得到的真实版本：

• Chrome：121.0.6167.184（主次缩写121.0）
• ChromeDriver：121.0.6167.184（主次缩写121.0）

PUSH_IMAGE=false说明这次操作只在本地产出标签、并未直接推送到仓库，标签随后由发布流水线统一推送（见下文"Makefile 与发布流水线"一节）。

标签规范：6 种模式的语义

将日志中的 12 行Tagged去重后，可以得到 6 种标签模式。它们的命名规律与 docs/docker-hub/node-chrome.md 中描述的通用结构selenium/node-chrome-<browserVersion>-<browserDriver>-<browserDriverVersion>-<Major>.<Minor>.<Patch>-<YYYYMMDD>一致：

前 3 种使用完整版本号（121.0.6167.184），后 3 种使用short_version函数截取的主次版本（121.0）。所有这些标签都指向同一个镜像内容，区别只在于用户引用它的方式：用121.0-20250606能快速拿到这一批 Chrome 121 的镜像，用121.0.6167.184-chromedriver-121.0.6167.184-grid-4.33.0-20250606则能保证拿到的是与 Grid 4.33.0 配套测试过的确切组合。

为什么这次只打了 6 种而不是 10 种标签

对比 tag_and_push_browser_images.sh 的CHROME_TAGS数组可以发现，当RELEASE_OLD_VERSION=false（常规发布）时，脚本会额外追加 4 个不带构建日期的纯版本标签：121.0.6167.184-chromedriver-121.0.6167.184、121.0.6167.184、121.0-chromedriver-121.0、121.0。

本次调用第 6 个参数为true，因此跳过了这 4 个标签。从脚本分支逻辑可以推断，这是"旧版本补发"场景：Chrome 121 相对构建日期 20250606 已是较早的浏览器版本，此时若再打node-chrome:121.0这类无日期标签，会与后续更新的 121.x 版本产生歧义（121.0应始终指向最新的 121.x）。所以旧版本发布只生成带日期或带 Grid 版本限定的标签，避免覆盖纯版本标签的指向。

脚本实现原理：探测、缩写与打标签

tag_and_push_browser_images.sh的核心逻辑由三块组成。

1. 版本探测：以容器内真实版本为准

脚本并不会从外部资料猜测版本，而是直接运行已构建好的镜像来读取版本号，见 chrome 分支：

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

其中TAG_VERSION为4.33.0-20250606，即此前构建阶段产出的基础标签。探测完成后通过awk取出google-chrome --version输出的第三个字段（121.0.6167.184）和chromedriver --version输出的第二个字段，保证标签中的版本号与镜像内二进制完全一致，不会出现"标签写了 121.0.6167.184 但容器里跑的是别的版本"的漂移问题。

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

121.0.6167.184→121.0。chrome、chromium、edge、firefox、chrome-for-testing 五个分支共用这一函数，只是各分支探测命令与awk字段位置不同。

3. 打标签与推送：retag()

每个标签都交给retag()处理（tag_and_push_browser_images.sh）。默认路径执行docker tag "${NAMESPACE}/${__image}:${TAG_VERSION}" "${NAMESPACE}/${__image}:${__tag}"，并在PUSH_IMAGE=true时追加docker push；echo "Tagged ..."正是日志中 12 行输出。脚本还预留了PROMOTE_TAGS=true的发布提升路径：此时不经过本地docker tag，而是用docker buildx imagetools create在仓库与仓库之间直接给 manifest 增加标签，从而保留多架构清单，避免"pull 回来再 tag"导致的多架构丢失。

最终的循环（tag_and_push_browser_images.sh）对每个标签依次对node-chrome与standalone-chrome执行retag，因此 6 种标签 × 2 个镜像 = 12 行输出。

从 Makefile 到发布流水线

tag_and_push_browser_images.sh不是孤立脚本，而是被 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_chrome_images: ./tag_and_push_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) chrome $(RELEASE_OLD_VERSION)

VERSION、BUILD_DATE、NAMESPACE、PUSH_IMAGE、RELEASE_OLD_VERSION均可在 Makefile 顶部覆盖（默认VERSION=4.49.0、BUILD_DATE=当前日期、NAMESPACE=selenium、PUSH_IMAGE=false、RELEASE_OLD_VERSION=false）。发布时流水线可对五种浏览器分别执行标签生成；此外tag_and_push_browser_images_ghcr目标会用docker buildx imagetools create把同样的标签集合镜像到 GHCR 命名空间，保持多架构清单完整。

镜像内部的版本事实：NodeChrome 如何确定这些版本号

标签里的版本号之所以"可信"，是因为它们在构建期就已经被固化进镜像。查看 NodeChrome/Dockerfile 可以看到三条关键链路：

• Chrome 安装：默认CHROME_VERSION="google-chrome-stable"，由 install-chrome.sh 执行——支持从 Google apt 仓库安装 stable/beta/unstable 通道，也支持通过google-chrome-stable=121.0.6167.120-1形式的参数从归档仓库安装精确版本；
• ChromeDriver 安装：install-chromedriver.sh 默认自动探测已装 Chrome 的主版本号（google-chrome --version | sed -E "s/.* ([0-9]+)(\.[0-9]+){3}.*/\1/"），再根据架构与主版本选择驱动来源：Chrome < 115 走旧的chromedriver.storage.googleapis.com接口，其余由 resolve-chromedriver-source.sh 决定从 Chrome for Testing 分发还是回退到 Debianchromium-driver包；
• 版本固化：构建末尾执行google-chrome --version | awk '{print $3}' > /opt/selenium/browsers/chrome/version，把浏览器版本写入/opt/selenium/browsers/chrome/version，供 Node 配置生成使用。

值得注意的是，tag 脚本中的探测命令（google-chrome --version | awk '{print $3}'）与 NodeChrome/Dockerfile 中固化版本所用的命令完全一致，这正是版本号在构建期、标签期保持自洽的设计保证。此外镜像还设置了SE_NODE_ENABLE_MANAGED_DOWNLOADS=true让 Node 自动管理会话下载文件，以及SE_BROWSER_BINARY_LOCATION（默认/usr/bin/google-chrome）等环境变量，相关语义可查阅 ENV_VARIABLES.md。

CHANGELOG 矩阵与版本锁定机制

这类单浏览器单 Grid 版本的 md 日志，最终汇总为 CHANGELOG/README.md 中的"Grid 版本 × 浏览器版本"矩阵。矩阵的动机在该文件中有明确说明：在提供最新 Selenium Grid 核心功能的同时，允许用户锁定特定浏览器版本（例如用于跨浏览器测试，或规避某些浏览器版本的限制与缺陷）。每个 ✓ 链接到对应 Grid 版本下该浏览器版本的详细 changelog（即chrome_121.md这类文件），最新版本排在最前。

矩阵并非手写维护：generate-matrix-readme.py 会扫描当前与archived目录下所有浏览器名_版本号.md文件（如chrome_121.md），自动生成表格，并把旧 Grid 版本移入archived/。这也解释了本次阅读的文档为何位于CHANGELOG/archived/4.33.0/：4.33.0 已是归档版本，但其标签日志仍保留在矩阵的 "Archived Grid Versions" 表格中，供用户追溯"某个 Grid 版本曾经配套过哪些浏览器版本"。

矩阵还附有一条重要提示：项目并未对每种 Grid × 浏览器组合都做完整测试，用户需要根据自己的测试需求自行评估组合的可用性——这意味着选择越精确的标签（如包含grid-4.33.0-20250606的完整标签），越接近项目实际配套验证过的组合。

如何在测试中使用这些标签

以 Node + Hub 模式为例，docs/docker-hub/node-chrome.md 给出的标准启动方式如下：

# 1. 创建网络 docker network create grid # 2. 启动 Hub docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:latest # 3. 启动 Node，并用 SE_EVENT_BUS_HOST 让 Node 通过容器名找到 Hub docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-chrome:121.0.6167.184-chromedriver-121.0.6167.184-grid-4.33.0-20250606

• 包含浏览器的容器务必加--shm-size=2g，使用宿主机共享内存，避免 Chrome 因/dev/shm过小崩溃；
• 文档明确建议：示例中的latest仅用于体验，正式环境应使用完整标签锁定浏览器与 Grid 版本，例如本次日志中的121.0.6167.184-chromedriver-121.0.6167.184-grid-4.33.0-20250606；
• 若希望进一步观察容器内浏览器行为，可访问http://localhost:7900/?autoconnect=1&resize=scale&password=secret（默认 VNC 密码secret）；
• 使用结束后可执行docker network rm grid清理网络；
• 仓库根目录还提供了 docker-compose-v3.yml 等编排文件，可在services中将image字段替换为上述精确标签，实现 Hub + Node（或 Standalone）组合的声明式部署。

参考路径

• 原始日志：CHANGELOG/archived/4.33.0/chrome_121.md
• 标签脚本：tag_and_push_browser_images.sh
• 发布目标与参数覆盖：Makefile
• 镜像构建与版本固化：NodeChrome/Dockerfile、install-chrome.sh、install-chromedriver.sh
• 标签结构与运行方式：docs/docker-hub/node-chrome.md
• 版本矩阵与其生成器：CHANGELOG/README.md、generate-matrix-readme.py

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