企业官网建设流程全解析

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

本文以 CHANGELOG/archived/4.35.0/chrome_112.md 这份发布记录为切入点，拆解 docker-selenium 项目如何为指定浏览器版本生成一组结构化的 Docker 镜像标签，并结合 tag_and_push_browser_images.sh 源码、NodeChrome 安装脚本 与 Docker Hub 标签约定文档，讲清"为什么同一个浏览器版本会有十几个不同 tag""旧版本浏览器与最新 Grid 版本如何共存"以及"如何挑选并实际使用这些镜像"。读完本文，你将掌握 docker-selenium 标签体系的设计逻辑，并能据此精确固定测试环境中的浏览器与 Grid 版本。

一、文档速览：一次真实的浏览器标签发布记录

CHANGELOG/archived/4.35.0/chrome_112.md内容极简，只有一段命令执行日志，但它完整记录了发布流程的核心产物——针对 Chrome 112 生成的整组镜像标签：

./tag_and_push_browser_images.sh 4.35.0 20250909 selenium false chrome true Tagging images for browser chrome, version 4.35.0, build date 20250909, namespace selenium Selenium Grid version -> 4.35.0-20250909 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.35.0-20250909 Tagged selenium/standalone-chrome:112.0.5615.165-chromedriver-112.0.5615.49-grid-4.35.0-20250909 Tagged selenium/node-chrome:112.0.5615.165-chromedriver-112.0.5615.49-20250909 Tagged selenium/standalone-chrome:112.0.5615.165-chromedriver-112.0.5615.49-20250909 Tagged selenium/node-chrome:112.0.5615.165-20250909 Tagged selenium/standalone-chrome:112.0.5615.165-20250909 Tagged selenium/node-chrome:112.0-chromedriver-112.0-grid-4.35.0-20250909 Tagged selenium/standalone-chrome:112.0-chromedriver-112.0-grid-4.35.0-20250909 Tagged selenium/node-chrome:112.0-chromedriver-112.0-20250909 Tagged selenium/standalone-chrome:112.0-chromedriver-112.0-20250909 Tagged selenium/node-chrome:112.0-20250909 Tagged selenium/standalone-chrome:112.0-20250909

这份日志传达了几个关键事实：

• 发布对象：Chrome 112 固定版本（112.0.5615.165）搭配 ChromeDriver112.0.5615.49，打包进 Selenium Grid4.35.0-20250909（4.35.0 版本、20250909 构建日期）的 Node 与 Standalone 镜像。
• 镜像形态：每次发布同时处理node-chrome（Grid 分布式架构中的节点）与standalone-chrome（单机一体形态）两类镜像。
• 标签数量：为每个镜像生成了 6 个标签（合计 12 行输出）。这与脚本中RELEASE_OLD_VERSION=true（命令最后一个参数）的语义直接相关——旧版本浏览器发布时只打带构建日期的标签，不再覆盖无日期的通用标签。

对比最新的 CHANGELOG/4.48.0/chrome_112.md 可以发现：同一浏览器版本（112）在不同 Grid 版本（4.48.0）下的发布记录结构完全一致，只是版本号与构建日期不同。这印证了标签发布流程是高度脚本化、可重复的。

二、为什么需要这么多标签：固定版本测试的需求

CHANGELOG/README.md 的开篇说明了这套矩阵的设计动机：Selenium Grid 核心版本持续演进、不断加入新功能，但测试团队往往需要把浏览器固定在某个特定版本——可能因为该版本与业务兼容性最好，也可能因为某些版本存在已知问题需要规避。docker-selenium 为此在发布每个 Grid 版本时，都打包一批历史浏览器版本（Chrome 95～152、Edge、Firefox 等），形成"Grid 版本 × 浏览器版本"的矩阵。

矩阵表里每一格都链接到一份 changelog 文档（即本文这类文件）。最新的 Grid 版本放在 "Latest Grid Version" 小节，历史版本归入 "Archived Grid Versions"；4.35.0下的记录之所以归档，是因为它已不是当前最新的 Grid 版本，但 Chrome 112 镜像仍然可用——这正是"固定版本测试"的价值所在：即使 Grid 升级到 4.48.0，依然可以拉取 4.35.0 时代的 Chrome 112 镜像。

同时 README 也给出重要提示：项目并没有对"每种 Grid 版本 × 浏览器版本"组合做全量功能测试，使用者需要根据自己的测试需求评估选择。这意味着固定版本标签提供的是"可用性保障"，而不是"每个组合都经过完整回归"的承诺。

三、标签体系全解：从完整版本号到短版本号

标签约定在 docs/docker-hub/node-chrome.md 与 docs/docker-hub/standalone-chrome.md 中有明确说明，标签由多个信息片段按固定顺序拼接而成：

selenium/node-chrome-<Major>.<Minor>.<Patch>-<YYYYMMDD> selenium/node-chrome-<browserVersion>-<browserDriver>-<browserDriverVersion>-<Major>.<Minor>.<Patch>-<YYYYMMDD>

以发布记录中的标签为例，逐一拆解其语义（selenium/node-chrome:112.0.5615.165-chromedriver-112.0.5615.49-grid-4.35.0-20250909）：

完整的标签族可以概括为四层"渐进细化"：

1. 最简层：112.0、112.0-20250909—— 只看浏览器大版本，适合"用这个主版本就行"的场景。
2. 浏览器 + 驱动：112.0-chromedriver-112.0、112.0-chromedriver-112.0-20250909—— 明确指定驱动版本。
3. 精确到 Patch：112.0.5615.165、112.0.5615.165-20250909—— 浏览器 Patch 级锁定。
4. 全量信息：112.0.5615.165-chromedriver-112.0.5615.49-grid-4.35.0-20250909—— 浏览器、驱动、Grid 版本、构建日期全部确定，可复现性最强。

其中短版本号由脚本中的short_version()函数计算得出：按.拆分版本号后取前两段（见 tag_and_push_browser_images.sh），如112.0.5615.165→112.0。

标签如何在镜像内被探测生成

脚本并不硬编码版本号，而是直接运行刚构建好的镜像来探测版本。以 Chrome 分支为例（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}')

即先以4.35.0-20250909构建node-chrome，再通过docker run在其中执行google-chrome --version与chromedriver --version，用awk提取版本号（Chrome 取第 3 个字段，ChromeDriver 取第 2 个字段），最后拼出标签矩阵。--platform参数支持linux/amd64之外的架构探测（脚本第 7 个参数PLATFORM默认linux/amd64）。

四、脚本参数与发布模式：普通发布 vs 旧版本再发布

tag_and_push_browser_images.sh 定义了完整的参数序列：

VERSION=$1 # Grid 版本，如 4.35.0 BUILD_DATE=$2 # 构建日期，如 20250909 NAMESPACE=$3 # 镜像命名空间，默认 selenium PUSH_IMAGE=$4 # 是否 docker push，默认 false BROWSER=$5 # chrome / chromium / edge / firefox / chrome-for-testing RELEASE_OLD_VERSION=$6 # 是否发布旧浏览器版本，默认 false PLATFORM=$7 # 目标平台，默认 linux/amd64

关联文档中的命令./tag_and_push_browser_images.sh 4.35.0 20250909 selenium false chrome true对应：Grid 4.35.0、构建日期 20250909、命名空间 selenium、不打 push、浏览器 chrome、发布旧版本（RELEASE_OLD_VERSION=true）。

新旧发布模式的关键差异

脚本内部（tag_and_push_browser_images.sh）先固定生成 6 个"带构建日期"的标签：

• <full>-chromedriver-<full-driver>-grid-<grid>-<date>
• <full>-chromedriver-<full-driver>-<date>
• <full>-<date>
• <short>-chromedriver-<short-driver>-grid-<grid>-<date>
• <short>-chromedriver-<short-driver>-<date>
• <short>-<date>

当RELEASE_OLD_VERSION=false（即发布当前最新浏览器版本）时，额外追加 4 个不带日期的通用标签（tag_and_push_browser_images.sh）：

• <full>-chromedriver-<full-driver>
• <full>
• <short>-chromedriver-<short-driver>
• <short>

这两组标签的设计意图非常清晰：

• 不带日期的标签（如112.0、112.0.5615.165）是"浮动指针"，始终指向最新一次发布该浏览器版本的 Grid 镜像。如果旧版本再发布也覆盖它们，会导致旧 Grid 的镜像抢占最新标签，破坏用户的预期。
• 带日期的标签是"快照"，永久保留，保证历史上任意时刻的发布都可追溯、可复现。

这也解释了为何发布记录中 Chrome 112 只有 12 行（6 标签 × node/standalone 两个镜像）——因为RELEASE_OLD_VERSION=true，脚本跳过了那 4 个通用标签，避免旧浏览器覆盖最新浮动标签。

retag 的两种实现路径

retag()函数（tag_and_push_browser_images.sh）负责真正的打标签与推送：

• 常规路径：docker tag本地镜像后，若PUSH_IMAGE=true再docker push（第 4 个参数控制）。
• 镜像提升路径：当环境变量PROMOTE_TAGS=true（由发布流水线设置）时，不再本地重建，而是用docker buildx imagetools create直接在 registry 之间创建 manifest 标签。注释解释了原因：docker tag只能操作本地镜像，docker pull又只能拉取运行方架构的单架构镜像，会导致浏览器标签变成单架构；而imagetools直接操作 multi-arch index，保证与 release 标签一致。PROMOTE_GHCR_NAMESPACE存在时还会在同一调用中同步镜像到 GHCR 命名空间。

在 Makefile 中，该脚本被封装为make tag_and_push_browser_images（聚合 chrome、chrome-for-testing、chromium、edge、firefox 五个目标）与make tag_and_push_browser_images_ghcr（通过docker buildx imagetools create把 docker.io 上的标签镜像到GHCR_NAMESPACE，默认ghcr.io/seleniumhq）。

五、Chrome 112 镜像背后的安装实现：版本如何被装进容器

标签体系能成立，前提是镜像构建时真的装上了指定版本的 Chrome 与 ChromeDriver。这一层的实现分别在两个脚本中。

Chrome 安装：install-chrome.sh

脚本通过 Google 官方 apt 仓库安装（install-chrome.sh）：

• 按渠道安装：CHROME_VERSION默认google-chrome-stable，也支持beta、unstable渠道。
• 按精确版本安装：当值形如google-chrome-stable=121.0.6167.120-1时，脚本从归档源下载对应.deb包，并用apt-get install --allow-downgrades实现版本锁定与降级。

装完最后执行google-chrome --version校验版本。这与标签发布脚本中"运行容器探测版本"形成了闭环：构建时装什么版本，发布时探测什么版本，标签上就写什么版本。

ChromeDriver 安装：install-chromedriver.sh

驱动安装脚本的版本解析逻辑与 Chrome 112 这个特定版本高度相关（install-chromedriver.sh）：

• Chrome 115 之前是"legacy"时代：Chrome for Testing（CfT）项目在 Chrome 115 之后才成为主渠道。对于主版本号小于 115 的 Chrome（112 正是如此），脚本走冻结的chromedriver.storage.googleapis.comAPI：先请求LATEST_RELEASE_112拿到该主版本的最新驱动号，再下载chromedriver_linux64.zip。
• 115 及之后：amd64 从 Chrome for Testing 官方存储桶下载；其他架构（Google 不发布 Linux/ARM64 的 ChromeDriver）则回退到基于相同 Chromium 源码构建的 Debianchromium-driver包，并按需安装额外共享库（libdouble-conversion3、libminizip1t64），甚至升级libc6。

安装完成后统一创建/opt/selenium/chromedriver-<version>并软链到/usr/bin/chromedriver，确保容器内chromedriver --version可被发布脚本直接探测。

六、如何实际使用这些固定版本标签

掌握了标签语义，用法就非常直接。官方 node-chrome 文档 给出了完整的三步流程。

场景一：Grid 分布式（Hub + Node）

# 1. 创建网络 docker network create grid # 2. 启动 Hub（端口 4442-4444） docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:latest # 3. 启动固定版本的 Chrome 节点 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.35.0-20250909

Windows PowerShell 用户使用反引号续行：

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.35.0-20250909

场景二：Standalone 单机一体

standalone-chrome 文档 展示了免 Hub 的最简形态：

docker run -d -p 4444:4444 -p 7900:7900 --shm-size="2g" \ selenium/standalone-chrome:112.0-20250909

两个场景的共同要点：

• --shm-size="2g"必须保留：包含浏览器的镜像需要宿主机共享内存，否则浏览器进程容易崩溃。
• 启动后，将 WebDriver 测试指向http://localhost:4444即可。
• 可选：访问http://localhost:7900/?autoconnect=1&resize=scale&password=secret通过 noVNC 实时观察容器内的浏览器运行画面（默认密码secret，对应 NodeBase/selenium.conf 中的 VNC 配置）。
• 用完后清理：docker network rm grid。

标签选择建议

• 可复现性优先：使用完整标签（含grid-与日期），如112.0.5615.165-chromedriver-112.0.5615.49-grid-4.35.0-20250909，CI 中每个维度都确定。
• 简写优先：需要"某个浏览器主版本的最新发布"时，用短版本如112.0；但要理解这类浮动标签会被后续新 Grid 版本的发布更新。
• 谨慎对待latest：官方文档明确建议使用完整标签来固定浏览器与 Grid 版本，而非latest，因为latest跟随最新发布，浏览器与 Grid 的组合会随时间漂移。

七、结论与延伸阅读

docker-selenium 通过"Grid 版本 × 浏览器版本 × 镜像形态 × 标签粒度"的多维矩阵，在"跟随最新"与"锁定旧版本"之间提供了完整的操作弹性：发布脚本自动探测版本并生成从112.0到全量信息的标签族，旧版本发布时以RELEASE_OLD_VERSION=true只追加带日期的快照标签，从而保护浮动标签不被历史版本覆盖；CHANGELOG/README.md 矩阵则将这些记录组织成可检索的索引，本文所分析的 4.35.0 版 Chrome 112 记录 即是其中一格。

若想进一步深入，推荐按以下顺序阅读仓库内相关文件：

• 发布脚本全貌：tag_and_push_browser_images.sh（含 chrome/chromium/edge/firefox/chrome-for-testing 五个分支的完整标签矩阵逻辑）
• 构建入口：NodeChrome/Dockerfile 与 Standalone/Dockerfile
• 版本安装细节：NodeChrome/install-chrome.sh、NodeChrome/install-chromedriver.sh
• 标签约定文档：docs/docker-hub/node-chrome.md、docs/docker-hub/standalone-chrome.md
• 版本矩阵索引：CHANGELOG/README.md

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