企业官网建设流程全解析

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

本篇技术指南聚焦 docker-selenium 项目中浏览器镜像的多重标签（multi-tag）发布机制。以 CHANGELOG/4.48.0/chrome_99.md 记录的「Selenium Grid 4.48.0 + Chrome 99.0.4844.84 + ChromeDriver 99.0.4844.51」组合为例，逐行解读该版本组合下node-chrome与standalone-chrome镜像被打上的全部标签，并结合 tag_and_push_browser_images.sh、Makefile 与 NodeChrome/Dockerfile 的源码实现，说明标签命名规则、生成逻辑与底层调用链。读完本文，你将能够：读懂 changelog 中任意一条版本组合记录；理解99.0.4844.84-chromedriver-99.0.4844.51-grid-4.48.0-20260909这类长标签每一段的含义；掌握如何精确选择镜像标签来固定浏览器与驱动版本。

一、版本组合记录：一份可复现的发布日志

CHANGELOG/4.48.0/chrome_99.md是 Selenium Grid 4.48.0 发布周期内，为 Chrome 99 版本生成镜像标签的完整命令输出。其核心内容是一条打标签命令及其执行结果：

./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true

这条命令携带 6 个位置参数，其含义可以从脚本头部参数解析直接确认（tag_and_push_browser_images.sh）：

脚本执行后首先打印版本组合的探测结果：

Selenium Grid version -> 4.48.0-20260909 Chrome version -> 99.0.4844.84 Short Chrome version -> 99.0 ChromeDriver version -> 99.0.4844.51 Short Chrome Driver version -> 99.0

这组输出揭示了该版本组合的完整构成：Grid 核心版本为4.48.0-20260909，镜像内打包的浏览器为 Chrome99.0.4844.84，配套驱动为 ChromeDriver99.0.4844.51。这里的 "Short" 版本是取主版本号与次版本号的缩写（99.0），由脚本中的short_version()函数实现（tag_and_push_browser_images.sh），它把99.0.4844.84按.切分后只保留前两段。

二、十个标签：一套"由全到简"的镜像标签体系

紧随版本探测之后，脚本依次为node-chrome和standalone-chrome两类镜像各打出 10 个标签。下面是该文档记录的全部标签输出（node 与 standalone 各 10 个，一一对应）：

Tagged selenium/node-chrome:99.0.4844.84-chromedriver-99.0.4844.51-grid-4.48.0-20260909 Tagged selenium/standalone-chrome:99.0.4844.84-chromedriver-99.0.4844.51-grid-4.48.0-20260909 Tagged selenium/node-chrome:99.0.4844.84-chromedriver-99.0.4844.51-20260909 Tagged selenium/standalone-chrome:99.0.4844.84-chromedriver-99.0.4844.51-20260909 Tagged selenium/node-chrome:99.0.4844.84-20260909 Tagged selenium/standalone-chrome:99.0.4844.84-20260909 Tagged selenium/node-chrome:99.0-chromedriver-99.0-grid-4.48.0-20260909 Tagged selenium/standalone-chrome:99.0-chromedriver-99.0-grid-4.48.0-20260909 Tagged selenium/node-chrome:99.0-chromedriver-99.0-20260909 Tagged selenium/standalone-chrome:99.0-chromedriver-99.0-20260909 Tagged selenium/node-chrome:99.0-20260909 Tagged selenium/standalone-chrome:99.0-20260909

这些标签由脚本中的CHROME_TAGS数组定义（tag_and_push_browser_images.sh），可归纳为三组命名策略：

1. 完整版本号组（长标签）：同时携带 Chrome 完整版本、ChromeDriver 完整版本与 Grid 版本/构建日期，例如99.0.4844.84-chromedriver-99.0.4844.51-grid-4.48.0-20260909。此类标签信息最全，可完全复现测试环境。
2. 短版本号组：使用99.0这类短版本号，便于记忆与检索，例如99.0-chromedriver-99.0-grid-4.48.0-20260909。
3. 构建日期与版本号组合：例如99.0.4844.84-20260909、99.0-20260909，用于表达"某次构建日期下打包的浏览器版本"。

值得注意的是，RELEASE_OLD_VERSION=true的语义直接体现在标签数量上。对比 chrome_113.md 中相同命令（./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true）的输出可以发现：当RELEASE_OLD_VERSION为true时，只生成上述 6 组基础标签；而当该参数为false时，脚本还会额外追加 4 组不含grid后缀、也不含构建日期的标签（tag_and_push_browser_images.sh），例如99.0.4844.84-chromedriver-99.0.4844.51、99.0.4844.84、99.0-chromedriver-99.0、99.0。这意味着：

• 发布最新浏览器版本时（RELEASE_OLD_VERSION=false），还会暴露99.0、99.0.4844.84这类最简洁的"浮动标签"，方便用户直接引用；
• 补发历史旧版本时（RELEASE_OLD_VERSION=true），刻意省略简洁浮动标签，避免旧版本镜像意外覆盖或干扰最新版本的浮动标签解析。

三、脚本实现原理：从探测版本到批量打标

tag_and_push_browser_images.sh的核心工作流程可以分为四个阶段：

阶段一：参数解析与环境准备。脚本开头通过$1~$7接收 7 个参数，其中PUSH_IMAGE、RELEASE_OLD_VERSION、PLATFORM均设有默认值（false、false、linux/amd64），并定义了PROMOTE_TAGS与PROMOTE_GHCR_NAMESPACE两个由 CI 环境变量注入的开关（tag_and_push_browser_images.sh）。

阶段二：镜像内版本探测。对 chrome 分支而言，脚本通过docker run从已构建的node-chrome:${TAG_VERSION}镜像中直接执行版本命令并解析输出：

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

也就是说，镜像标签中的版本号不是从外部配置读取的，而是在运行时从镜像内真实的浏览器与驱动二进制探测得到，从源头上保证了"标签版本 == 镜像内实际版本"。该探测逻辑同样覆盖 chromium、edge、firefox、chrome-for-testing 分支，只是各自执行的版本命令与awk取列位置不同（例如 edge 使用microsoft-edge --version，firefox 使用firefox --version与geckodriver --version）。

阶段三：生成标签数组并批量打标。chrome分支构建CHROME_TAGS数组后，通过retag函数循环为node-chrome与standalone-chrome各打一遍（tag_and_push_browser_images.sh）。retag函数内部根据PROMOTE_TAGS走两条路径（tag_and_push_browser_images.sh）：

• 普通路径：docker tag "${NAMESPACE}/${__image}:${TAG_VERSION}" "${NAMESPACE}/${__image}:${__tag}"，若PUSH_IMAGE=true再执行docker push；
• 发布晋升路径（PROMOTE_TAGS=true）：源码注释说明，此时镜像源位于 registry 且从未在本地构建，docker tag只能操作本地镜像、且docker pull只会拉回单架构，因此改用docker buildx imagetools create在 registry 与 registry 之间直接创建多架构 manifest 标签，并可同时通过PROMOTE_GHCR_NAMESPACE镜像一份到 GHCR（tag_and_push_browser_images.sh）。

阶段四：按浏览器分发。脚本使用case "${BROWSER}"分支处理chrome、chromium、edge、firefox、chrome-for-testing五种浏览器（tag_and_push_browser_images.sh），未知浏览器打印Unknown browser!后退出。

在 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五个子目标（Makefile），每个子目标把 Makefile 中的$(VERSION)、$(BUILD_DATE)、$(NAMESPACE)、$(PUSH_IMAGE)、$(RELEASE_OLD_VERSION)变量原样传递给脚本。另外，Makefile 中chrome_upgrade_version、edge_upgrade_version、firefox_upgrade_version目标展示了构建完成后先用docker run ... google-chrome --version等方式自检版本，再进入打标环节的完整发布链路。

四、从 changelog 到版本矩阵：文档的生成与阅读

chrome_99.md这类逐版本记录文件并不是孤立存在的，它们共同构成了 CHANGELOG/README.md 这份"Selenium Grid × 浏览器版本矩阵"的原始数据源。该矩阵的定位在 README 开头有明确说明：项目希望持续供应最新的 Selenium Grid 核心版本，同时让用户能够按需固定（pin）浏览器版本进行跨浏览器测试或规避特定版本的问题，因此同时发布 Node 与 Standalone 两种形态、且每种都打包了 Grid 与具体驱动/浏览器版本。

矩阵的生成完全由 CHANGELOG/generate-matrix-readme.py 自动化完成：

• scan_changelog()通过正则([\w-]+)_(\d+)\.md扫描所有版本目录，解析出chrome_99.md这类文件名中的浏览器名与版本号（CHANGELOG/generate-matrix-readme.py）；
• generate_readme()按"最新版本在上、历史版本归档到 archived/ 目录"的原则生成 Markdown 表格，每个 ✓ 链接到对应浏览器版本的详细记录（CHANGELOG/generate-matrix-readme.py）；
• archive_old_versions()自动把非最新 Grid 版本目录移动到archived/，保证矩阵只保留当前发布周期的最新信息（CHANGELOG/generate-matrix-readme.py）。

在 CHANGELOG/README.md 的 4.48.0 Chrome 行中，chrome_99.md对应版本列 99，与 152~95 的完整版本梯队并列，直接说明该组合属于 4.48.0 发布周期内的受支持组合。同时 README 也给出了一条重要免责声明：项目并未对"每个 Grid 与浏览器版本的组合"都做全量功能测试，用户需要根据自身测试需求自行评估与决策——这提醒我们在选用旧浏览器版本组合时要注意功能兼容性边界。

五、镜像内版本从何而来：浏览器与驱动的打包链路

标签中出现的 Chrome 99 与 ChromeDriver 99 版本，最终落地于 NodeChrome/Dockerfile 的构建流程。该 Dockerfile 展示了版本打包的三个关键环节：

1. 浏览器安装：通过ARG CHROME_VERSION="google-chrome-stable"控制 Chrome 渠道（stable/beta/unstable），由 install-chrome.sh 执行安装；若设置INSTALL_CFT=true则改走 install-chrome-for-testing.sh 安装 Chrome for Testing（NodeChrome/Dockerfile）。
2. 驱动安装：ARG CHROME_DRIVER_VERSION用于指定 ChromeDriver 版本，缺省时由 install-chromedriver.sh 结合 resolve-chromedriver-source.sh 解析出与 Chrome 匹配的最新驱动版本（NodeChrome/Dockerfile）。
3. 版本信息落盘：构建期把探测到的版本写入/opt/selenium/browsers/chrome/version，同时写入 Chrome 可执行文件路径的 JSON 配置binary_location（NodeChrome/Dockerfile），供 Grid 节点启动时生成浏览器能力配置使用。此外 wrap_chrome_binary 包装脚本会在容器启动时处理 Chrome 的沙箱与资源限制等运行参数。

理解了这条链路后，chrome_99.md中的版本探测命令就有了清晰落点：docker run ... google-chrome --version探测的正是上述步骤 3 写入的二进制；而 changelog 记录中的版本组合，正是"NodeChrome 构建产物 + Standalone 包装产物"被最终打标的证据。

六、实践：如何拉取并固定这些镜像标签

在了解了标签体系之后，实际使用非常直接。以本文的 Chrome 99 组合为例，在测试中精确固定浏览器与驱动版本可以这样拉取：

docker pull selenium/node-chrome:99.0.4844.84-chromedriver-99.0.4844.51-grid-4.48.0-20260909 docker pull selenium/standalone-chrome:99.0.4844.84-chromedriver-99.0.4844.51-grid-4.48.0-20260909

若希望保留 Grid 核心为最新、只固定浏览器大版本，则可选用短标签99.0-20260909等。镜像的典型运行方式可参考仓库根目录的 docker-compose-v3.yml：它将selenium/node-chrome节点与selenium/hub组合，通过SE_EVENT_BUS_HOST环境变量让节点接入事件总线，并用shm_size: 2gb满足 Chrome 对共享内存的要求（docker-compose-v3.yml）。Standalone 形态则直接暴露 4444/4443/4442 三个端口，由 Standalone/Dockerfile 中的SE_SESSION_REQUEST_TIMEOUT、SE_SESSION_RETRY_INTERVAL等环境变量映射到 Grid 对应的启动参数（Standalone/Dockerfile）。

七、注意事项与适用前提

• 版本组合的可用性：如 CHANGELOG/README.md 所述，项目不保证每个 Grid × 浏览器组合都经过全量测试，固定旧版本（如 Chrome 99）时需自行验证功能完整性；
• 标签的时效性：chrome_99.md记录的标签属于 4.48.0 发布周期，随着新版本发布，旧版本目录会被 generate-matrix-readme.py 自动归档到CHANGELOG/archived/，不再出现在最新矩阵中；
• 打标命令的使用场景：tag_and_push_browser_images.sh属于发布流程的运维脚本，日常使用镜像的用户无需运行；若自行维护镜像仓库，需保证node-chrome:${TAG_VERSION}镜像已提前构建（对应 Makefile 中chrome_upgrade_version目标的职责）；
• 架构限制：脚本默认以--platform linux/amd64探测版本（chrome 分支显式传入PLATFORM），多架构发布时各平台版本号应一致，否则会出现标签与内容不一致的风险。

通过chrome_99.md这一份日志，我们可以完整还原 docker-selenium 浏览器镜像从"探测版本 → 生成标签 → 批量打标 → 写入版本矩阵"的全套发布机制，并在需要精确控制测试环境时，从十种标签中选出最合适的组合。

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