企业官网建设流程全解析

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

Chrome for Testing（CfT）是 Chrome 团队专为自动化测试发布的浏览器构建，其每次发布都会附带同一版本号的 ChromeDriver，保证浏览器与驱动始终是"已知良好"的配对。本文以 docker-selenium 项目 4.48.0 版本发布chrome-for-testing_132镜像的实际日志为骨架，逐条解析发布命令的参数含义、10 个镜像标签的命名结构，以及标签背后的脚本实现与版本探测机制，帮助读者理解如何按需选取精确版本标签、复现发布流程，并掌握该镜像的架构限制与运行方式。

发布日志全景：一条命令生成 20 个镜像标签

CHANGELOG/4.48.0/chrome-for-testing_132.md记录了一次完整的浏览器镜像打标签过程。整条命令与全部输出如下：

./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome-for-testing true Tagging images for browser chrome-for-testing, version 4.48.0, build date 20260909, namespace selenium Selenium Grid version -> 4.48.0-20260909 Chrome for Testing version -> 132.0.6834.159 Short Chrome for Testing version -> 132.0 ChromeDriver version -> 132.0.6834.159 Short ChromeDriver version -> 132.0 Tagged selenium/node-chrome-for-testing:132.0.6834.159-chromedriver-132.0.6834.159-grid-4.48.0-20260909 Tagged selenium/standalone-chrome-for-testing:132.0.6834.159-chromedriver-132.0.6834.159-grid-4.48.0-20260909 Tagged selenium/node-chrome-for-testing:132.0.6834.159-chromedriver-132.0.6834.159-20260909 Tagged selenium/standalone-chrome-for-testing:132.0.6834.159-chromedriver-132.0.6834.159-20260909 Tagged selenium/node-chrome-for-testing:132.0.6834.159-20260909 Tagged selenium/standalone-chrome-for-testing:132.0.6834.159-20260909 Tagged selenium/node-chrome-for-testing:132.0-chromedriver-132.0-grid-4.48.0-20260909 Tagged selenium/standalone-chrome-for-testing:132.0-chromedriver-132.0-grid-4.48.0-20260909 Tagged selenium/node-chrome-for-testing:132.0-chromedriver-132.0-20260909 Tagged selenium/standalone-chrome-for-testing:132.0-chromedriver-132.0-20260909 Tagged selenium/node-chrome-for-testing:132.0-20260909 Tagged selenium/standalone-chrome-for-testing:132.0-20260909

这次发布对应的版本矩阵是：

可以看到 CfT 与 ChromeDriver 在本镜像中版本号完全一致（132.0.6834.159），这正是 CfT 发布模型的核心特性：每个 CfT 构建与同一 revision 构建的 ChromeDriver 捆绑发布，无需担心浏览器与驱动版本错配。

发布命令逐参数解析

tag_and_push_browser_images.sh（仓库根目录）是此次日志的直接来源。脚本开头定义了 7 个位置参数（L1-L9）：

第 3 行日志Tagging images for browser chrome-for-testing, version 4.48.0, build date 20260909, namespace selenium直接对应脚本 L59 的echo语句。

RELEASE_OLD_VERSION 参数对标签数量的影响

日志中只生成了10 个标签（node 与 standalone 各 5 个），而非脚本逻辑能生成的最多 20 个。原因在于 chrome-for-testing 分支 L263-L274：

if [ "${RELEASE_OLD_VERSION}" = "false" ]; then CHROME_TAGS+=( # Browser version and browser driver version ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION} # Browser version ${CHROME_VERSION} # Browser version and browser driver version ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION} # Browser version ${CHROME_SHORT_VERSION} ) fi

当RELEASE_OLD_VERSION=true（本次调用正是如此）时，跳过不带构建日期的"裸版本"标签（如132.0.6834.159、132.0）。这是为了避免旧版本回填标签时覆盖掉较新发布已有的同名标签——新发布通常会携带这些裸版本标签，若旧版本再补一次就会产生标签漂移。

镜像标签命名结构全解

本次生成的 5 组标签（每组同时打给node-chrome-for-testing与standalone-chrome-for-testing），可以归纳为四种组合维度：

1. 版本粒度：完整版本132.0.6834.159vs 短版本132.0（由short_version函数截取前两段）；
2. 组件信息：仅浏览器版本、浏览器+驱动版本、浏览器+驱动+Selenium Grid 版本；
3. 日期：是否携带构建日期20260909。

具体映射如下：

在RELEASE_OLD_VERSION=false的常规发布中，还会追加 4 个裸版本标签：132.0.6834.159-chromedriver-132.0.6834.159、132.0.6834.159、132.0-chromedriver-132.0、132.0。这与 node-chrome-for-testing 文档 和 standalone-chrome-for-testing 文档 中"以浏览器版本 + 驱动版本 + Grid 版本 + 构建日期的各种排列组合作为标签"的描述完全一致。

标签生成依赖链

标签中的版本号并非硬编码，而是在脚本运行时通过docker run临时启动刚构建好的镜像探测而来（chrome-for-testing 分支 L240-L248）：

CHROME_VERSION=$(docker run --platform ${PLATFORM} --rm ${NAMESPACE}/node-chrome-for-testing:${TAG_VERSION} google-chrome --version | awk '{print $5}') CHROMEDRIVER_VERSION=$(docker run --platform ${PLATFORM} --rm ${NAMESPACE}/node-chrome-for-testing:${TAG_VERSION} chromedriver --version | awk '{print $2}')

注意 CfT 分支与普通chrome分支的解析字段不同：google-chrome --version对 CfT 输出取$5，对普通 Chrome 取$3，这是因为两类二进制的版本输出格式存在差异（CfT 输出的Chrome for Testing前缀占据了更靠前的字段）。短版本则由 short_version 函数 按.切分后取前两段得到132.0。

retag 与推送

retag 函数 承担实际的打标签动作：PROMOTE_TAGS=false时使用docker tag（本次日志即此路径，第 4 参数false决定了不执行docker push）；若发布流程走镜像推广（PROMOTE_TAGS=true），则改用docker buildx imagetools create在 registry 之间直接复制 manifest，避免跨架构标签退化为单架构。

Makefile 集成与 GHCR 镜像

该脚本由 Makefile 的 target 驱动，tag_and_push_chrome-for-testing_images（L786-L787）按固定参数调用脚本，与tag_and_push_chrome_images、tag_and_push_chromium_images等并列，汇总于tag_and_push_browser_images（L781）这一个入口 target。而 tag_and_push_browser_images_ghcr 则遍历本地产出的所有标签，通过docker buildx imagetools create将docker.io/selenium/*的标签镜像同步到 GHCR 命名空间，保证两个镜像仓库标签体系一致。

镜像内部的 CfT 安装与版本固定

标签中浏览器版本的"固定"特性，根源在于 NodeChrome/Dockerfile 的构建逻辑（L20-L33）：

ARG CFT_VERSION="STABLE" ARG INSTALL_CFT="false" ... RUN chmod +x /opt/bin/install-chrome.sh /opt/bin/update-chrome-components.sh /opt/bin/install-chrome-for-testing.sh \ && if [ "${INSTALL_CFT}" = "true" ]; then \ CFT_VERSION=${CFT_VERSION} /opt/bin/install-chrome-for-testing.sh; \ else \ /opt/bin/install-chrome.sh; \ fi

• INSTALL_CFT=true时走 CfT 安装路径，CFT_VERSION可传STABLE/BETA/DEV/CANARY通道名或精确版本号（如132.0.6834.159）；
• install-chrome-for-testing.sh 从 Google 的 CfT 公共存储下载对应版本的 zip 包，安装到/opt/chrome，并解析随附的deb.deps安装运行时依赖，最后输出google-chrome --version校验；
• ChromeDriver 由 install-chromedriver.sh 安装，amd64 上优先从 CfT 渠道获取与 Chrome 主版本号锁步的驱动（版本解析逻辑在 resolve-chromedriver-source.sh）。

与普通node-chrome镜像不同，CfT 镜像不自动更新（常规镜像的更新入口 update-chrome-components.sh 对 CfT 构建不适用），且不携带消费版浏览器附带的组件，因此非常适合需要把构建精确钉死在某个版本的场景——标签里写了132.0.6834.159，容器内运行的就是132.0.6834.159。

如何选择并使用正确的标签

标签选择速查

• 需要最完整的可追溯信息：132.0.6834.159-chromedriver-132.0.6834.159-grid-4.48.0-20260909（浏览器+驱动+Grid+日期全齐）；
• 需要精确版本但不过分冗余：132.0.6834.159-chromedriver-132.0.6834.159-20260909；
• 只需要知道主版本线：132.0-20260909；
• 常规新发布后希望跟随该主版本的最新补丁：132.0-chromedriver-132.0或132.0（注意此类裸版本标签仅在RELEASE_OLD_VERSION=false时生成，本次日志未包含）。

官方文档推荐始终固定完整标签（浏览器版本 + Grid 版本 + 构建日期），这是可复现性最强的做法。

以 Node 模式接入 Selenium Grid

CfT 镜像以browserName=chrome注册能力，已有测试无需改动。节点模式运行方式（完整步骤见 node-chrome-for-testing 文档）：

docker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:4.48.0-20260905 docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --platform linux/amd64 \ --shm-size="2g" \ selenium/node-chrome-for-testing:132.0.6834.159-chromedriver-132.0.6834.159-grid-4.48.0-20260909

以 Standalone 模式直接运行

docker run -d -p 4444:4444 -p 7900:7900 --platform linux/amd64 --shm-size="2g" \ selenium/standalone-chrome-for-testing:132.0.6834.159-chromedriver-132.0.6834.159-grid-4.48.0-20260909

随后将 WebDriver 测试指向http://localhost:4444即可；浏览器内联调试可访问http://localhost:7900/?autoconnect=1&resize=scale&password=secret（默认密码secret）。

架构限制：仅 linux/amd64

Chrome for Testing 官方仅发布linux64平台构建，因此selenium/node-chrome-for-testing与selenium/standalone-chrome-for-testing镜像只提供 linux/amd64。运行命令中的--platform linux/amd64正是为了在非 amd64 主机上强制使用该架构。ARM64 环境请改用selenium/node-chrome或selenium/node-chromium（CfT 从 Chrome 153 起才开始发布linux-arm64，更早的版本在 arm64 上只能走 Debian 的chromium-driver包回退路径，见 resolve-chromedriver-source.sh 头部注释）。

此外，凡包含浏览器的镜像都建议加--shm-size=2g，否则 Chrome 在默认 64 MB 的/dev/shm下容易崩溃。

小结

CHANGELOG/4.48.0/chrome-for-testing_132.md表面是一份发布日志，实质是理解 docker-selenium 镜像标签体系的最佳入口：一条命令、两个镜像名、五组标签维度，配合 tag_and_push_browser_images.sh 的版本探测与 Makefile 的发布编排，构成了完整、可追溯、可复现的浏览器镜像发布链路。对使用者而言，掌握浏览器版本-chromedriver-驱动版本-grid-Grid版本-构建日期的标签组合规则，即可在任何历史发布中精确定位"某天、某版 Grid、某版 CfT、某版驱动"的唯一镜像。

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