docker-selenium 4.28.1 的 Firefox 133 镜像标签解析：tag_and_push_browser_images.sh 与版本矩阵实战

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

导读

本文以 docker-selenium 仓库中CHANGELOG/archived/4.28.1/firefox_133.md的发布日志为切入点，完整解读 Selenium Grid 4.28.1-20250202 构建中 Firefox 133.0.3 + GeckoDriver 0.35.0 镜像的 20 个发布标签（node-firefox 与 standalone-firefox 各 10 个）背后的生成逻辑。你将掌握该仓库镜像标签命名规范、tag_and_push_browser_images.sh脚本的完整参数与执行流程、Firefox 节点镜像的构建原理，以及如何依据 CHANGELOG/README.md 的版本矩阵精准挑选你需要的镜像 tag。

一、先读懂这份发布日志：一次打标签命令的完整输出

firefox_133.md的内容是一次真实发布命令的逐行记录，命令为：

./tag_and_push_browser_images.sh 4.28.1 20250202 selenium false firefox true

其参数含义（对应 tag_and_push_browser_images.sh 的脚本形参）：

命令执行后，脚本先从已构建的selenium/node-firefox:4.28.1-20250202镜像内部探测版本信息：

Selenium Grid version -> 4.28.1-20250202 Firefox version -> 133.0.3 Short Firefox version -> 133.0 GeckoDriver version -> 0.35.0 Short GeckoDriver version -> 0.35

• 4.28.1-20250202由TAG_VERSION=${VERSION}-${BUILD_DATE}拼接而成（脚本第 15 行）；
• 完整版本133.0.3、0.35.0与短版本133.0、0.35同时存在，这是脚本short_version()函数取主次版本号的结果，短版本标签用于让用户无需记住 patch 号即可拉取。

随后按三种 tag 分类、长短两组，依次为node-firefox与standalone-firefox各打出 10 个标签，最终共 20 个：

完整版本 + 驱动 + Grid（最精确的一组）

selenium/node-firefox:133.0.3-geckodriver-0.35.0-grid-4.28.1-20250202 selenium/standalone-firefox:133.0.3-geckodriver-0.35.0-grid-4.28.1-20250202

浏览器完整版本 + 驱动版本 + 构建日期

selenium/node-firefox:133.0.3-geckodriver-0.35.0-20250202 selenium/standalone-firefox:133.0.3-geckodriver-0.35.0-20250202

浏览器完整版本 + 构建日期

selenium/node-firefox:133.0.3-20250202 selenium/standalone-firefox:133.0.3-20250202

短版本三组（同一镜像的“只认大版本”别名）

selenium/node-firefox:133.0-geckodriver-0.35-grid-4.28.1-20250202 selenium/standalone-firefox:133.0-geckodriver-0.35-grid-4.28.1-20250202 selenium/node-firefox:133.0-geckodriver-0.35-20250202 selenium/standalone-firefox:133.0-geckodriver-0.35-20250202 selenium/node-firefox:133.0-20250202 selenium/standalone-firefox:133.0-20250202

注意：本日志因RELEASE_OLD_VERSION=true，不再生成不带构建日期的133.0.3、133.0-geckodriver-0.35等"裸"标签，避免覆盖最新版本同名的浮动标签——这正是归档旧版本发布时的重要保护机制（详见第三节）。

二、标签命名规范：20 个标签如何组织成一套可检索体系

文档 对node-firefox的标签结构给出了通用范式，与上述输出完全对应：

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

以及由上述组合衍生出的全部排列变体，可归纳为三类：

1. Grid 维度标签：<Major>.<Minor>.<Patch>、<Major>.<Minor>.<Patch>-<YYYYMMDD>（本次为4.28.1/4.28.1-20250202所在位置）；
2. 浏览器/驱动维度标签：<BrowserMajor>.<BrowserMinor>、<BrowserMajor>.<BrowserMinor>-<YYYYMMDD>（本次为133.0/133.0-20250202）；
3. 组合标签：<BrowserMajor>.<BrowserMinor>-geckodriver-<GeckoDriverMajor>.<GeckoDriverMinor>[-<YYYYMMDD>][-grid-<Grid版本>-<YYYYMMDD>]（本次为133.0-geckodriver-0.35-grid-4.28.1-20250202等）。

实用建议：日常测试建议使用最精确的133.0.3-geckodriver-0.35.0-grid-4.28.1-20250202以固定整套环境；若只需锁定 Firefox 大版本、容忍 patch 更新，则133.0或133.0-20250202更合适。对应地，standalone-firefox与node-firefox共享同一套标签命名，只是前者自带 Hub/Grid 全栈功能，可单独运行。

三、脚本源码剖析：版本探测、短版本与 retag 的实现细节

tag_and_push_browser_images.sh 是本 changelog 背后的生成引擎，其 firefox 分支（第 195-236 行）是本次日志的直接来源。

3.1 版本探测：版本号来自镜像内部，而非硬编码

FIREFOX_VERSION=$(docker run --rm ${NAMESPACE}/node-firefox:${TAG_VERSION} firefox --version | awk '{print $3}') GECKODRIVER_VERSION=$(docker run --rm ${NAMESPACE}/node-firefox:${TAG_VERSION} geckodriver --version | awk 'NR==1{print $2}')

脚本通过docker run临时启动已构建的节点镜像，执行firefox --version与geckodriver --version并用awk提取版本号。这意味着标签永远与镜像内实际打包的二进制版本保持一致，消除了手工填写版本号导致标签错配的风险。

3.2 short_version：主次版本提取

function short_version() { local __version_split=(${__long_version//./ }) echo "${__version_split[0]}.${__version_split[1]}" }

把133.0.3拆为133、0、3后取前两段拼成133.0，同理0.35.0→0.35，为短标签提供版本来源。

3.3 FIREFOX_TAGS 数组的构造规则

以RELEASE_OLD_VERSION为开关，标签集合分两层：

• 基础 6 个标签（始终生成）：<完整版本>-geckodriver-<驱动>-grid-<TAG_VERSION>、<完整版本>-geckodriver-<驱动>-<BUILD_DATE>、<完整版本>-<BUILD_DATE>，及三者对应的短版本形式；
• 追加 4 个标签（仅当RELEASE_OLD_VERSION=false）：<完整版本>-geckodriver-<驱动>、<完整版本>、<短版本>-geckodriver-<短驱动>、<短版本>。

随后循环对node-firefox与standalone-firefox两个镜像执行retag：

for firefox_tag in "${FIREFOX_TAGS[@]}"; do retag node-firefox "${firefox_tag}" retag standalone-firefox "${firefox_tag}" done

3.4 retag：docker tag 与发布提升两条路径

retag() 函数 默认使用docker tag "${NAMESPACE}/${__image}:${TAG_VERSION}" "${NAMESPACE}/${__image}:${__tag}"，并在PUSH_IMAGE=true时追加docker push。而当 CI 的PROMOTE_TAGS=true（发布流程直接提升已测试镜像、而非重新构建）时，则改用：

docker buildx imagetools create --tag ... "${NAMESPACE}/${__image}:${TAG_VERSION}"

注释（脚本第 18-30 行）解释得很清楚：此时源镜像只存在于远端 registry，本地没有镜像层，docker tag无法表达，且docker pull只会带回构建机的单架构镜像；imagetools在 index 层面完成 registry 到 registry 的多架构镜像打标。若同时设置PROMOTE_GHCR_NAMESPACE，还会在同一调用中镜像到 GHCR 命名空间。

四、版本从何而来：NodeFirefox 镜像构建链路

本次日志中的node-firefox:4.28.1-20250202并非凭空出现，其构建逻辑位于 NodeFirefox/Dockerfile：

• Firefox 安装（第 21-70 行）：通过ARG FIREFOX_VERSION控制，常规数值版本（如 133）走install-firefox-package.sh下载 Mozilla 官方.deb（amd64/aarch64 分别映射x86_64/aarch64，找不到 .deb 时回退 tar.bz2）；latest/beta-latest等通道或大于等于 136 的主版本走install-firefox-apt.sh的 apt 安装；随后执行get_lang_package.sh拉取语言包并apt-get upgrade修复依赖 CVE。
• GeckoDriver 安装（第 75-86 行）：解析 GitHub releases 最新版后，按架构下载geckodriver-${GK_VERSION}-linux64.tar.gz（或linux-aarch64），解压到/opt/geckodriver-${GK_VERSION}并通过ln -fs软链到/usr/bin/geckodriver。
• 浏览器信息落盘（第 93-96 行）：构建时把firefox、实际版本写入/opt/selenium/browsers/firefox/，并生成{"moz:firefoxOptions": {"binary": "${SE_BROWSER_BINARY_LOCATION:-/usr/bin/firefox}"}}的 binary_location 文件——这正是 ENV_VARIABLES.md 中SE_BROWSER_BINARY_LOCATION环境变量所作用的配置逻辑：默认/usr/bin/firefox，自定义安装路径时可通过该变量覆盖并配合GENERATE_CONFIG=true使用。

也正因构建时已安装 Firefox 133.0.3 与 GeckoDriver 0.35.0，第三节的版本探测命令才能从镜像内读到一致的结果。

五、版本矩阵与归档机制：如何在仓库里定位本日志

firefox_133.md位于CHANGELOG/archived/4.28.1/下，说明 4.28.1 已不再是当前最新 Grid 版本，其 changelog 被归档管理。整个归档与矩阵索引由 CHANGELOG/generate-matrix-readme.py 自动维护：

1. 归档步骤（第 8-42 行）：扫描符合\d+\.\d+\.\d+的目录，仅保留最新版本，其余shutil.move到archived/下（已存在则跳过）；
2. 矩阵扫描（第 45-67 行）：用正则([\w-]+)_(\d+)\.md解析每个 changelog 文件名，得到grid_version → browser → version的映射；
3. README 生成（第 70-186 行）：按浏览器分组生成"Grid 版本 × 浏览器版本"的 ✓ 链接矩阵，其中归档版本的链接前缀为archived/{grid_version}/{browser}_{version}.md。

因此 CHANGELOG/README.md 的 "Archived Grid Versions → Firefox" 表中，4.28.1行与133列交叉处的 ✓ 即指向本文分析的 firefox_133.md。该 README 明确说明其动机是"让用户既能用最新 Grid 核心功能，又能按需锁定浏览器版本做跨浏览器测试或规避特定版本问题"，并强调官方并未对每种 Grid×浏览器组合做全量回归测试，使用者需结合自身测试需求评估。

六、实战：用 133 系标签跑起 Firefox 节点

拿到标签后，按 文档 的 Hub-and-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:4.28.1 # 3. 启动本次 changelog 对应的 Firefox 节点（务必使用 --shm-size=2g） docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-firefox:133.0.3-geckodriver-0.35.0-grid-4.28.1-20250202

随后将 WebDriver 测试指向http://localhost:4444即可；如需观察容器内运行情况，可访问http://localhost:7900/?autoconnect=1&resize=scale&password=secret（需配合 VNC/noVNC 端口映射）。若只做单机测试，也可直接拉取自带 Grid 的selenium/standalone-firefox:133.0.3-geckodriver-0.35.0-grid-4.28.1-20250202。测试结束后执行docker network rm grid清理网络。

注意：含有浏览器的镜像必须使用--shm-size=2g以利用宿主共享内存，否则浏览器进程可能因 /dev/shm 过小而崩溃。

七、进一步探索

• 阅读脚本全貌与其余浏览器分支（chrome、chromium、edge、chrome-for-testing）：tag_and_push_browser_images.sh
• 查看 Firefox 节点构建脚本与清理配置：NodeFirefox/install-firefox-apt.sh、NodeFirefox/install-firefox-package.sh、NodeFirefox/firefox-cleanup.sh
• 对比同一 Grid 版本的其他浏览器 changelog：如 firefox_132.md（132.0.2 + geckodriver 0.35.0）、firefox_134.md
• 查看当前最新 Grid 版本的对应记录（GeckoDriver 已升级至 0.37.1）：CHANGELOG/4.48.0/firefox_133.md

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