- 测试
- 后端
- 云原生
- 容器编排
- 可观测性
【免费下载链接】docker-selenium
Provides a simple way to run Selenium Grid with Chrome, Firefox, and Edge using Container Platform, making it easier to perform browser automation at scale
本篇技术指南聚焦 docker-selenium 项目的镜像发布标签体系：以 CHANGELOG/archived/4.35.0/chrome_116.md 记录的一次真实发布过程为骨架，完整讲解tag_and_push_browser_images.sh的命令参数、版本探测流程与十种标签命名规则，并结合 tag_and_push_browser_images.sh、Makefile、NodeChrome/Dockerfile 等源码深入剖析其实现原理。读完本文，你将理解 docker-selenium 为何为同一浏览器版本发布多套镜像标签、每套标签的语义与适用场景，并能独立按标签拉取镜像、复现标签发布流程。
一次真实的标签发布记录
在 Grid 版本 4.35.0、构建日期 20250909 的发布中，项目通过以下命令为 Chrome 116 生成并标记镜像标签：
./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 -> 116.0.5845.187 Short Chrome version -> 116.0 ChromeDriver version -> 116.0.5845.96 Short ChromeDriver version -> 116.0 Tagged selenium/node-chrome:116.0.5845.187-chromedriver-116.0.5845.96-grid-4.35.0-20250909 Tagged selenium/standalone-chrome:116.0.5845.187-chromedriver-116.0.5845.96-grid-4.35.0-20250909 Tagged selenium/node-chrome:116.0.5845.187-chromedriver-116.0.5845.96-20250909 Tagged selenium/standalone-chrome:116.0.5845.187-chromedriver-116.0.5845.96-20250909 Tagged selenium/node-chrome:116.0.5845.187-20250909 Tagged selenium/standalone-chrome:116.0.5845.187-20250909 Tagged selenium/node-chrome:116.0-chromedriver-116.0-grid-4.35.0-20250909 Tagged selenium/standalone-chrome:116.0-chromedriver-116.0-grid-4.35.0-20250909 Tagged selenium/node-chrome:116.0-chromedriver-116.0-20250909 Tagged selenium/standalone-chrome:116.0-chromedriver-116.0-20250909 Tagged selenium/node-chrome:116.0-20250909 Tagged selenium/standalone-chrome:116.0-20250909这段日志完整展示了发布脚本的输入（参数）、中间过程（版本探测与短版本号计算）与输出（12 条标签记录）。下文将逐层拆解其背后的机制。
为什么需要为同一浏览器发布多套标签
根据 CHANGELOG/README.md 的说明，该矩阵体系的动机是：在持续提供最新 Selenium Grid 核心版本的同时，让用户能够针对跨浏览器测试（cross-browser testing）或因兼容性/已知问题而需要锁定（pin）特定浏览器版本的场景，选择固定浏览器版本的镜像。项目为 Node 与 Standalone 两类镜像同时打包 Grid 核心与指定的浏览器/驱动版本，用户只需查矩阵、找标签、拉镜像即可开始测试。
因此同一浏览器版本会被贴上多套语义不同的标签：完整版本号标签便于精确锁定，短版本号标签便于按大版本维度使用，带构建日期的标签保证可追溯，而不带构建日期的标签则作为长期可用的稳定别名。这正是 CHANGELOG/archived/4.35.0/chrome_116.md 中 12 条 Tagged 记录产生的原因。
命令参数全解
脚本入口位于仓库根目录的 tag_and_push_browser_images.sh，其参数解析如下（对应源码第 1-9 行）：
| 位置 | 参数 | 含义 | 默认值 |
|---|---|---|---|
$1 | VERSION | Selenium Grid 版本号（如 4.35.0） | 必填 |
$2 | BUILD_DATE | 构建日期（YYYYMMDD，如 20250909） | 必填 |
$3 | NAMESPACE | 镜像命名空间，默认取环境变量NAME，未设置时为selenium | selenium |
$4 | PUSH_IMAGE | 打标签后是否执行docker push | false |
$5 | BROWSER | 浏览器类型：chrome/chromium/edge/firefox/chrome-for-testing | 必填 |
$6 | RELEASE_OLD_VERSION | 是否为旧版本补发标签；true时不生成不带构建日期的裸版本标签 | false |
$7 | PLATFORM | 运行版本探测时使用的平台（如linux/amd64） | linux/amd64 |
文档记录的命令中，PUSH_IMAGE=false表示只打本地标签不推送，RELEASE_OLD_VERSION=true表示这是一次面向归档旧版本（4.35.0 已被归档）的补标签操作——这与 CHANGELOG/generate-matrix-readme.py 的归档逻辑相吻合：旧 Grid 版本目录会被移入archived/，其浏览器标签也不再需要裸版本别名。
脚本内部首先拼接完整标签版本号：
TAG_VERSION=${VERSION}-${BUILD_DATE}即文档日志中的Selenium Grid version -> 4.35.0-20250909，它是所有镜像在构建阶段使用的原始标签（如selenium/node-chrome:4.35.0-20250909）。
版本探测：从镜像内读取真实组件版本
标签内容不是凭空拼出来的，而是先运行已构建的node-chrome:4.35.0-20250909镜像，从容器内探测 Chrome 与 ChromeDriver 的实际版本，再据此生成标签。对应源码第 65-73 行：
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}')google-chrome --version输出形如Google Chrome 116.0.5845.187，awk '{print $3}'取出版本号116.0.5845.187；chromedriver --version输出以版本号开头，awk '{print $2}'取出116.0.5845.96；--platform ${PLATFORM}确保在多架构发布时按目标平台探测（默认linux/amd64）。
这些版本号随后写入 Dockerfile 的浏览器信息目录。在 NodeChrome/Dockerfile 第 65-72 行可以看到镜像构建时同样执行google-chrome --version并把结果写入/opt/selenium/browsers/chrome/version，脚本运行时的探测与此同源，确保标签与实际打包的二进制严格一致。
短版本号的生成
脚本通过short_version()函数（源码第 53-57 行）把完整版本截断为主版本+次版本：
function short_version() { local __long_version=$1 local __version_split=(${__long_version//./ }) echo "${__version_split[0]}.${__version_split[1]}" }116.0.5845.187按.拆分后取前两段得到116.0，ChromeDriver 同理得到116.0，对应日志中的两行Short ... version -> 116.0。
标签命名规则：六类基础标签与四类可选标签
以探测到的四个变量（完整/短版本的 Chrome 与 ChromeDriver 版本号）为原料，chrome 分支构建了标签数组（源码第 75-99 行），并逐一作用于node-chrome与standalone-chrome两个镜像（源码第 101-104 行）。全部标签按下表归纳：
| 类别 | 标签格式 | 文档中实例 | 语义 |
|---|---|---|---|
| 完整组合 | ${CHROME}-chromedriver-${DRIVER}-grid-${TAG_VERSION} | 116.0.5845.187-chromedriver-116.0.5845.96-grid-4.35.0-20250909 | 同时锁定浏览器、驱动、Grid 与构建日期，精确可复现 |
| 完整+日期 | ${CHROME}-chromedriver-${DRIVER}-${BUILD_DATE} | 116.0.5845.187-chromedriver-116.0.5845.96-20250909 | 锁定浏览器与驱动版本，并标识构建日期 |
| 浏览器+日期 | ${CHROME}-${BUILD_DATE} | 116.0.5845.187-20250909 | 仅锁定浏览器完整版本与日期 |
| 短组合 | ${CHROME_SHORT}-chromedriver-${DRIVER_SHORT}-grid-${TAG_VERSION} | 116.0-chromedriver-116.0-grid-4.35.0-20250909 | 按大版本维度锁定浏览器与驱动 |
| 短+日期 | ${CHROME_SHORT}-chromedriver-${DRIVER_SHORT}-${BUILD_DATE} | 116.0-chromedriver-116.0-20250909 | 短版本+日期组合 |
| 短浏览器+日期 | ${CHROME_SHORT}-${BUILD_DATE} | 116.0-20250909 | 短版本+日期 |
当RELEASE_OLD_VERSION=false（常规新版本发布）时，还会追加四类不带构建日期的稳定别名（源码第 88-99 行）：${CHROME}-chromedriver-${DRIVER}、${CHROME}、${CHROME_SHORT}-chromedriver-${DRIVER_SHORT}、${CHROME_SHORT}。这类标签长期有效，适合在 CI 配置中固定使用。
需要特别说明：本次文档记录的命令第六个参数为true，即RELEASE_OLD_VERSION=true，因此输出中只有前六类共 12 条 Tagged 记录，与脚本逻辑完全一致——旧版本补发时不再生成裸版本别名，避免与后续新版本混淆。
底层实现：retag 函数与发布模式
每条标签最终都经由retag()函数落地（源码第 31-51 行）。该函数支持两种发布模式：
本地打标签模式（默认）：
docker tag "${__source}" "${NAMESPACE}/${__image}:${__tag}" if [ "${PUSH_IMAGE}" = true ]; then docker push "${NAMESPACE}/${__image}:${__tag}" fi即对本地已有镜像执行docker tag，可选docker push推送到仓库。
镜像提升模式（PROMOTE_TAGS=true）：当发布流程直接提升 CI 已验证镜像而不是重新构建时（相关逻辑见 Makefile 第 183-233 行的promote_release_images等目标），本地并不存在镜像，脚本改用docker buildx imagetools create在仓库与仓库之间、manifest 层面复制标签：
docker buildx imagetools create --tag "${NAMESPACE}/${__image}:${__tag}" "${__source}"注释中解释了这样做的原因：docker tag要求镜像在本地，而单次docker pull只会带回运行机架构的镜像，导致浏览器标签退化为单架构；imagetools直接操作多架构 manifest index，可保留多架构能力。若设置了PROMOTE_GHCR_NAMESPACE，同一调用还会同时把标签镜像到 GHCR。
Makefile 封装与 GHCR 镜像
日常使用不必直接调用脚本，Makefile 第 781-796 行提供了封装目标：
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 第 1-40 行给出了默认值，例如NAME默认selenium、BUILD_DATE默认当天、VERSION默认为当前维护版本）。此外tag_and_push_browser_images_ghcr（Makefile 第 798-808 行）会枚举本地node-chrome/standalone-chrome等镜像的全部标签，通过docker buildx imagetools create逐一镜像到ghcr.io/seleniumhq。
实战：按标签拉取与验证镜像
基于上面的标签体系，实际使用中可按需选择标签：
# 精确锁定浏览器、驱动与 Grid 版本 docker pull selenium/node-chrome:116.0.5845.187-chromedriver-116.0.5845.96-grid-4.35.0-20250909 # 仅按短版本维度使用（兼容同大版本下的补丁更新） docker pull selenium/standalone-chrome:116.0拉取后可进入容器验证组件版本是否与标签一致：
docker run --rm selenium/node-chrome:116.0 google-chrome --version docker run --rm selenium/node-chrome:116.0 chromedriver --version这两个命令正是 tag_and_push_browser_images.sh 第 65-73 行在发布时执行的探测命令，输出应分别为Google Chrome 116.0.5845.187与版本号116.0.5845.96。
关于版本与浏览器组合的可用性，CHANGELOG/README.md 明确提示：项目并未对每种 Grid 与浏览器版本的组合做全量测试，用户应根据自身测试需求评估选择。这也是标签矩阵按"Grid 版本 × 浏览器版本"二维组织的原因——每个 ✓ 都链接到对应组合的详细 changelog（如本文章对应的 chrome_116.md）。
版本矩阵与归档机制
整个 changelog 目录由 CHANGELOG/generate-matrix-readme.py 自动维护：它首先把除最新版本外的 Grid 版本目录移入archived/（这就是chrome_116.md位于CHANGELOG/archived/4.35.0/的原因），然后扫描各版本目录下的浏览器_版本.md文件，生成"Grid 版本 × 浏览器版本"矩阵 README，并链接到每个 changelog 文件。文档记录中RELEASE_OLD_VERSION=true与"已归档版本"的身份相互印证：归档版本在补标签时只生成带日期的标签，不再干扰最新版本的裸版本别名。
总结
通过 CHANGELOG/archived/4.35.0/chrome_116.md 这份发布记录，可以完整还原 docker-selenium 的镜像标签体系：tag_and_push_browser_images.sh以 Grid 版本与构建日期为输入，先运行镜像探测 Chrome/ChromeDriver 的真实版本，再按"完整/短版本 × 是否带 Grid 与构建日期"的组合规则生成六类基础标签（旧版本补发）或十类标签（常规发布），最终通过retag()以本地打标签或 buildx imagetools 提升的方式落地到node-chrome与standalone-chrome。理解这套规则后，无论是锁定测试环境的浏览器版本，还是排查多架构镜像标签问题，都能直接定位到正确的标签与对应源码。
- 测试
- 后端
- 云原生
- 容器编排
- 可观测性
【免费下载链接】docker-selenium
Provides a simple way to run Selenium Grid with Chrome, Firefox, and Edge using Container Platform, making it easier to perform browser automation at scale
相关推荐
docker-selenium 4.48.0 版本 Chrome 145 镜像标签生成全解析：从 `tag_and_push_browser_images.sh` 看版本矩阵与镜像标签体系
docker selenium 4.48.0 版本 Chrome 145 镜像标签生成全解析：从 tag_and_push_browser_images.sh
测试后端云原生容器编排可观测性docker-selenium Chrome 116 镜像版本标签体系解析：从 `tag_and_push_browser_images.sh` 到可复现的标签命名规范
docker selenium Chrome 116 镜像版本标签体系解析：从 tag_and_push_browser_images.sh 到可复现的标签命名
测试后端云原生容器编排可观测性cosign pkcs11-tool list-tokens 命令详解：枚举 PKCS11 模块中的所有 Token
cosign pkcs11 tool list tokens 命令详解：枚举 PKCS 11 模块中的所有 Token 导读 cosign pkcs11 too
测试后端云原生容器编排可观测性
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
