docker-selenium Firefox 141 发布记录解析：镜像标签命名规范与浏览器自动化部署实战

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

导读

本文以 docker-selenium 项目 Selenium Grid 4.48.0 版本 Firefox 141.0.3 发布记录（CHANGELOG/4.48.0/firefox_141.md）为核心，剖析本次发布的版本组合、标签生成机制与镜像矩阵，并结合仓库中的发布脚本与 NodeFirefox 镜像源码，讲清楚"如何选择正确的 Firefox 镜像标签"以及"标签背后浏览器、驱动与 Grid 三者版本的对应关系"，帮助你基于 docker-selenium 搭建可复现、可追溯的 Firefox 自动化测试环境。

一、发布记录速览：本次 Firefox 141 发布包含哪些版本信息

firefox_141.md是 Selenium Grid 4.48.0 版本发布周期的浏览器发布记录之一（同一批次还包括 chrome-for-testing、edge、firefox_140 等记录）。记录本质是一次镜像打标签（tagging）过程的可审计日志，核心信息如下：

日志完整列出了对selenium/node-firefox与selenium/standalone-firefox两组镜像追加的 12 个标签。这些标签并非随意命名，而是由项目根目录的 tag_and_push_browser_images.sh 脚本按固定规则自动生成（详见下文第三节）。

需要说明的是：文档中的日期20260909为发布构建日期，仅代表该发布记录的构建批次，并非当前系统时间。

二、理解标签体系：如何解读与选择 Firefox 镜像标签

2.1 标签结构总览

本次发布打出的 12 个标签可归纳为四类模式，其中<TAG_VERSION>即4.48.0-20260909（Selenium Grid 版本 + 构建日期）：

2.2 短版本（Short version）的由来

日志中 "Short Firefox version -> 141.0" 与 "Short GeckoDriver version -> 0.37" 由脚本内的short_version()函数生成：它按.拆分版本号，仅保留前两段（主版本 + 次版本）。这样141.0标签会随同系列小版本（如 141.0.1、141.0.2、141.0.3）的后续发布自动指向最新镜像，适合想要"锁定大版本但跟随小版本更新"的场景。

2.3 长版本标签的用途

形如141.0.3-geckodriver-0.37.1-grid-4.48.0-20260909的完整标签将浏览器、驱动、Grid、构建日期四者全部锁定，是可完全复现的选择：无论何时拉取，得到的都是同一份经过验证的组合。官方推荐在生产环境使用完整标签固定版本，而不是latest（见 docs/docker-hub/node-firefox.md 与 docs/docker-hub/standalone-firefox.md）。

2.4 关于旧版本标签

注意到141与0.37这类不带日期的短标签在本次日志中并未出现。这是因为脚本逻辑：当RELEASE_OLD_VERSION参数为false（本次调用第 6 个参数即false）时，才会追加纯浏览器版本标签（141.0.3、141.0）与浏览器+驱动标签（141.0.3-geckodriver-0.37.1、141.0-geckodriver-0.37）。这 4 个标签留给旧版本发布流程使用，避免与"最新版"标签互相覆盖。

三、深入源码：tag_and_push_browser_images.sh 如何工作

发布记录由仓库根目录的 tag_and_push_browser_images.sh 执行生成。脚本针对firefox分支的关键流程如下：

3.1 参数与版本探测

VERSION=$1 # 4.48.0 BUILD_DATE=$2 # 20260909 NAMESPACE=$3 # selenium PUSH_IMAGE="${4:-false}" BROWSER=$5 # firefox RELEASE_OLD_VERSION="${6:-false}" PLATFORM="${7:-linux/amd64}"

脚本通过docker run临时启动已构建的node-firefox:${TAG_VERSION}镜像来探测实际版本：

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

随后对两组镜像执行retag node-firefox与retag standalone-firefox，为每个标签追加版本。

3.2 双模式打标签：本地 retag 与 registry 级 promote

retag()函数支持两种路径：

• 常规路径：docker tag本地复制镜像并（可选）docker push，PUSH_IMAGE=true时推送；
• promote 路径：当PROMOTE_TAGS=true时，直接使用docker buildx imagetools create在 registry 之间复制多架构 manifest（index），因为 release 流程此时直接复用测试过的镜像而非本地重建（脚本头部注释对此有详细说明）。

3.3 与 Makefile 的联动

Makefile 中tag_and_push_firefox_images目标（第 796 行）正是以同样参数调用该脚本：

./tag_and_push_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) firefox $(RELEASE_OLD_VERSION)

而tag_and_push_browser_images总目标（第 781 行）会依次串联 chrome、chrome-for-testing、chromium、edge、firefox 五个浏览器分支，因此每轮发布各浏览器会并行产出同构的标签矩阵。

四、镜像内部实现：node-firefox 如何构建 Firefox 141 + GeckoDriver 0.37.1

发布日志中的版本组合并非凭空生成，而是由 NodeFirefox/Dockerfile 的构建参数决定：

4.1 Firefox 安装策略

Dockerfile 定义FIREFOX_VERSION=latest等 ARG。amd64 架构或版本 ≥ 136 时优先从 Mozilla 官方 APT 仓库安装（install-firefox-apt.sh 配置了packages.mozilla.org源与固定指纹校验、Pin-Priority: 1000的 apt 偏好），否则通过 install-firefox-package.sh 下载官方.deb/.tar.bz2/.tar.xz包安装。对 141 这类新版本，amd64 走 APT 路径、aarch64 走下载路径（脚本内按dpkg --print-architecture自动判别x86_64与aarch64架构包）。

4.2 GeckoDriver 安装

GECKODRIVER_VERSION=latest时，Dockerfile 会解析mozilla/geckodriver最新 release，下载对应架构的geckodriver-${GK_VERSION}-${DRIVER_ARCH}.tar.gz解压到/opt/geckodriver-${GK_VERSION}，并软链到/usr/bin/geckodriver，因此镜像内版本可通过geckodriver --version探测——这正是脚本 3.1 节获取 0.37.1 的来源。

4.3 浏览器信息与运行时环境

镜像构建后段还会固化浏览器元数据（NodeFirefox/Dockerfile）：写入/opt/selenium/browsers/firefox/{name,version,binary_location}，其中 binary_location 预置moz:firefoxOptions.binary为${SE_BROWSER_BINARY_LOCATION:-/usr/bin/firefox}，允许通过环境变量自定义浏览器路径（对应 ENV_VARIABLES.md 中的SE_BROWSER_BINARY_LOCATION）。同时默认开启SE_NODE_ENABLE_MANAGED_DOWNLOADS=true，由 NodeBase/start-selenium-node.sh 在启动时追加--enable-managed-downloads，让 Node 自动管理会话下载文件。

五、实战：运行 Firefox 141 镜像并验证版本

5.1 Standalone 模式（单容器 Grid）

docker run -d -p 4444:4444 -p 7900:7900 \ --shm-size="2g" \ selenium/standalone-firefox:141.0.3-geckodriver-0.37.1-grid-4.48.0-20260909

将 WebDriver 测试指向http://localhost:4444即可；如需 VNC 观察，访问http://localhost:7900/?autoconnect=1&resize=scale&password=secret。

5.2 Node + Hub 模式

docker network create grid docker run -d -p 4442-4444:4442-4444 \ --net grid --name selenium-hub selenium/hub:4.48.0-20260909 docker run -d --net grid \ -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-firefox:141.0.3-geckodriver-0.37.1-grid-4.48.0-20260909

使用 PowerShell 时换行符改用反引号（`）。浏览器容器务必加--shm-size=2g，否则浏览器渲染进程可能因共享内存不足而崩溃。结束后可用docker network rm grid清理网络。

5.3 验证镜像内版本

docker run --rm selenium/node-firefox:141.0.3-geckodriver-0.37.1-grid-4.48.0-20260909 firefox --version docker run --rm selenium/node-firefox:141.0.3-geckodriver-0.37.1-grid-4.48.0-20260909 geckodriver --version

输出应与发布记录一致（Firefox 141.0.3、GeckoDriver 0.37.1），可快速确认镜像组合与预期相符。

5.4 会话回收配置

NodeFirefox 默认通过 firefox-cleanup.sh 定期清理残留的firefox-bin进程（由 firefox-cleanup.conf 交由 supervisord 托管），相关阈值可用环境变量调整：

• SE_BROWSER_LEFTOVERS_PROCESSES_SECS（默认 7200）：清理运行超过该秒数的 Firefox 进程；
• SE_BROWSER_LEFTOVERS_INTERVAL_SECS（默认 3600）：清理守护循环间隔；
• SE_BROWSER_LEFTOVERS_TEMPFILES_DAYS（默认 1）：临时文件保留天数。

详见 ENV_VARIABLES.md。

六、版本追踪与回归验证

本次发布日志位于 CHANGELOG/4.48.0/firefox_141.md，与同批次 firefox_140.md（Firefox 140.0.4 + GeckoDriver 0.37.1）对比可见：GeckoDriver 保持 0.37.1 不变，仅浏览器由 140.0.4 升级到 141.0.3，标签矩阵结构完全一致。若需回溯更早版本，CHANGELOG/archived 目录归档了旧发布记录，可作为镜像版本回归的对照依据。

这种"发布记录 + 标签矩阵 + 源码探测逻辑"三位一体的设计，使得每个镜像版本都可审计、可复现，也让使用者在挑选 Firefox 镜像标签时，能准确预判浏览器、驱动与 Grid 之间的兼容组合。

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