企业官网建设流程全解析

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

本篇技术指南以 docker-selenium 仓库中CHANGELOG/archived/4.34.0/firefox_135.md记录的发布日志为核心，深度剖析 Selenium Grid 4.34.0 版本中 Firefox 135.0.1（GeckoDriver 0.36.0）浏览器镜像的完整打标签过程：从tag_and_push_browser_images.sh的命令参数、版本探测逻辑，到node-firefox/standalone-firefox两类镜像的 20 个标签命名规则，再到镜像背后的构建与使用方式。读完本文，你将能看懂任何一条浏览器版本 changelog 日志、正确选择与解析所需的镜像标签，并理解这套多标签发布机制的设计动机。

从一条发布日志说起

CHANGELOG/archived/4.34.0/firefox_135.md记录了 2025 年 7 月 27 日（构建日期20250727）发布 Firefox 135 系列镜像的完整过程，原文如下：

./tag_and_push_browser_images.sh 4.34.0 20250727 selenium false firefox true Tagging images for browser firefox, version 4.34.0, build date 20250727, namespace selenium Selenium Grid version -> 4.34.0-20250727 Firefox version -> 135.0.1 Short Firefox version -> 135.0 GeckoDriver version -> 0.36.0 Short GeckoDriver version -> 0.36 Tagged selenium/node-firefox:135.0.1-geckodriver-0.36.0-grid-4.34.0-20250727 Tagged selenium/standalone-firefox:135.0.1-geckodriver-0.36.0-grid-4.34.0-20250727 Tagged selenium/node-firefox:135.0.1-geckodriver-0.36.0-20250727 Tagged selenium/standalone-firefox:135.0.1-geckodriver-0.36.0-20250727 Tagged selenium/node-firefox:135.0.1-20250727 Tagged selenium/standalone-firefox:135.0.1-20250727 Tagged selenium/node-firefox:135.0-geckodriver-0.36-grid-4.34.0-20250727 Tagged selenium/standalone-firefox:135.0-geckodriver-0.36-grid-4.34.0-20250727 Tagged selenium/node-firefox:135.0-geckodriver-0.36-20250727 Tagged selenium/standalone-firefox:135.0-geckodriver-0.36-20250727 Tagged selenium/node-firefox:135.0-20250727 Tagged selenium/standalone-firefox:135.0-20250727

这条日志揭示了仓库在"某个 Grid 版本 + 某个浏览器版本"组合上的发布产物全貌：Firefox 135.0.1、GeckoDriver 0.36.0、Selenium Grid 4.34.0三个版本被捆绑打包进node-firefox（Grid 节点）和standalone-firefox（独立部署）两类镜像，并通过 6 组标签对外发布。下一节我们从命令本身入手，逐项拆解每个参数的语义。

命令参数逐项拆解

./tag_and_push_browser_images.sh 4.34.0 20250727 selenium false firefox true

对照 tag_and_push_browser_images.sh 开头的参数解析（第 1-13 行），7 个位置参数含义如下：

其中几个关键点的源码依据：

• TAG_VERSION=${VERSION}-${BUILD_DATE}（第 15 行），因此日志第一行输出的 Grid 版本为4.34.0-20250727，这也是镜像构建时使用的核心标签；
• NAMESPACE=${NAME:-selenium}（第 16 行），允许通过环境变量NAME覆盖发布目标；
• RELEASE_OLD_VERSION=true是关键：脚本第 219-230 行中，只有当该参数为false时，才会追加135.0.1-geckodriver-0.36.0、135.0.1、135.0-geckodriver-0.36、135.0这四个不含 Grid 版本号的"短标签"。本日志共生成 20 个标签且全部带 Grid 版本号或构建日期，正好与RELEASE_OLD_VERSION=true的行为吻合——其设计意图是：补发旧浏览器版本时，避免用旧的浏览器版本号覆盖仓库中更新的135.0.1、135.0之类的浮动标签，从而防止用户拉到非预期的旧版本。

在 Makefile 中，tag_and_push_firefox_images目标（第 795-796 行）正是以$(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) firefox $(RELEASE_OLD_VERSION)的形式调用本脚本，即本日志命令的正式出处。

版本探测：标签上的版本号从哪来

日志中Firefox version -> 135.0.1和GeckoDriver version -> 0.36.0并非手动填写，而是脚本从已构建镜像内实时探测得到的。firefox 分支（第 196-204 行）的探测命令如下：

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

即：临时启动selenium/node-firefox:4.34.0-20250727，分别执行firefox --version与geckodriver --version，再借助awk提取第三列/第一行第二列作为版本号。这种"以运行时探测结果为准"的做法保证了标签与实际二进制版本严格一致，不依赖任何手写配置。

随后通过short_version函数（第 53-57 行）截取主版本号：

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

135.0.1→135.0，0.36.0→0.36。这就是日志中两行 "Short ... version" 的由来——短版本号用于生成一组更简短、更便于记忆的标签。

最终firefox分支共生成 6 组标签（第 206-230 行），每组同时作用于node-firefox与standalone-firefox：

每组的实际执行通过retag函数（第 31-51 行）完成：默认路径为docker tag本地镜像并（可选）docker push；当PROMOTE_TAGS=true时（CI 发布路径），则改用docker buildx imagetools create在 registry 之间直接复制 manifest，从而保留多架构特性（详见脚本第 18-44 行注释）。

多标签机制的设计动机

这套"一镜像、多标签"策略服务于版本矩阵的需求。在 CHANGELOG/README.md 中对此有明确说明：仓库的动机是"提供最新的 Selenium Grid 核心版本，同时让用户能够用于跨浏览器测试，或因特定浏览器版本的兼容性问题而固定浏览器版本"；使用方法是"找到镜像标签 → 拉取所需镜像 → 开始测试"。

具体到本日志的 6 组标签，它们面向不同的使用场景：

• 追求完全可复现（浏览器、驱动、Grid 三者全锁）：选135.0.1-geckodriver-0.36.0-grid-4.34.0-20250727；
• 只关心浏览器与驱动版本：选135.0.1-geckodriver-0.36.0-20250727；
• 只关心浏览器版本、不关心具体哪天构建：135.0.1这类浮动标签（在RELEASE_OLD_VERSION=false的常规发布中提供）；
• 想跟随某个 Grid 大版本：以grid-4.34.0-20250727结尾的标签将 Grid 版本显式锚定。

另外，README 也诚实声明："我们没有做完整的测试来保证 Grid 与浏览器版本的每一种组合都能完全正常运转，用户需要基于自身测试需求自行评估决策"。这一点同样适用于 135.0.1 与 4.34.0 的组合——标签存在代表构建成功，不代表组合被全量验证过。

镜像内容：Firefox 与 GeckoDriver 是如何被装进容器的

理解标签之后，再看这些标签背后的镜像内容。NodeFirefox/Dockerfile 基于selenium/node-base构建，其 Firefox 安装段（第 21-70 行）展示了版本策略的演进：当目标版本满足"amd64 架构"或"版本号主版本 ≥ 136"时，走 Mozilla 官方 apt 仓库安装（调用 install-firefox-apt.sh，该脚本引入packages.mozilla.org源并校验签名指纹35BAA0B33E9EB396F59CA838C0BA5CE6DC6315A3）；否则从 Mozilla 官方 CDN 下载.deb或.tar.bz2安装包，由 install-firefox-package.sh 完成解压与/usr/bin/firefox符号链接。因此 135.0.1 属于"< 136"的下载安装路径——这也解释了为什么日志发布时需要明确标注精确版本。

GeckoDriver 安装段（第 75-86 行）则始终从 mozilla/geckodriver 的 GitHub Releases 下载对应架构的压缩包：先解析releases/latest重定向得到最新版本，再按amd64→linux64、aarch64→linux-aarch64选择驱动归档，最终软链到/usr/bin/geckodriver，与日志中的 0.36.0 对应。

此外，Dockerfile 第 93-96 行还会向/opt/selenium/browsers/firefox/写入浏览器元数据：

firefox # name 135.0.1 # version（运行时探测） {"moz:firefoxOptions": {"binary": "${SE_BROWSER_BINARY_LOCATION:-/usr/bin/firefox}"}}

其中moz:firefoxOptions.binary供 Selenium Grid 创建会话时定位浏览器可执行文件，可通过SE_BROWSER_BINARY_LOCATION环境变量覆盖。节点还默认开启SE_NODE_ENABLE_MANAGED_DOWNLOADS=true（第 98-99 行），支持由 Selenium Manager 管理浏览器下载行为。另外 firefox-cleanup.sh 提供僵尸进程清理守护进程，通过SE_BROWSER_LEFTOVERS_PROCESSES_SECS（默认阈值）与SE_BROWSER_LEFTOVERS_INTERVAL_SECS（轮询间隔）控制，避免长时间运行的节点被残留的firefox-bin进程拖垮。

实际使用：如何拉起 Firefox 135 镜像

方式一：Selenium Grid 节点（Node 模式）

在分布式 Grid 中，node-firefox镜像作为注册到 Hub 的节点运行。仓库根目录的 docker-compose-v3.yml 展示了典型用法（当前示例为image: selenium/node-firefox:4.48.0-20260905），将该值替换为本日志发布的标签即可锁定 Firefox 135.0.1 + GeckoDriver 0.36.0：

services: node-firefox: image: selenium/node-firefox:135.0.1-geckodriver-0.36.0-grid-4.34.0-20250727 shm_size: 2gb depends_on: - selenium-hub environment: - SE_EVENT_BUS_PUBLISH_PORT=4442 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443 volumes: - /dev/shm:/dev/shm

节点启动后，客户端通过 Grid 端点（Hub 的 4444 端口）提交browserName: firefox的会话请求，Distributor 会将该请求路由到本节点，并由节点依据/opt/selenium/browsers/firefox/binary_location中的配置启动 Firefox 135.0.1。

方式二：独立部署（Standalone 模式）

standalone-firefox把 Selenium Server 与 Firefox 打包进同一容器，适合本地快速验证或 CI 单机执行：

docker run -d -p 4444:4444 --shm-size="2g" \ selenium/standalone-firefox:135.0.1-geckodriver-0.36.0-grid-4.34.0-20250727

然后通过 WebDriver 客户端（Java/Python/JS 等）连接http://localhost:4444，请求browserName: firefox即会得到 135.0.1 实例；若需要多语言界面，get_lang_package.sh会将对应版本的语言包装入distribution/extensions目录（该目录的创建见 install-firefox-package.sh 第 22 行）。

方式三：固定版本（版本矩阵的初衷）

如 CHANGELOG/README.md 所述，本矩阵存在的核心价值就是"固定浏览器版本"。当 Firefox 136+ 或后续版本在你的业务场景中表现不佳时，可以直接引用本文档发布的135.0.1系标签，把测试环境锁定在这一版本组合上，直到兼容性问题解决。

如何验证镜像内容

拉取镜像后，可用容器内命令复核版本号是否与标签一致，这与发布脚本的探测逻辑（firefox --version、geckodriver --version）完全对应：

docker run --rm selenium/standalone-firefox:135.0.1-geckodriver-0.36.0-grid-4.34.0-20250727 \ firefox --version docker run --rm selenium/standalone-firefox:135.0.1-geckodriver-0.36.0-grid-4.34.0-20250727 \ geckodriver --version docker run --rm selenium/standalone-firefox:135.0.1-geckodriver-0.36.0-grid-4.34.0-20250727 \ /opt/selenium/selenium-server.jar info --version

Makefile 中的firefox_upgrade_version目标（第 765-770 行）正是这样一组"构建 → 打标签 → 复核三版本"的自动化流程，可作为升级 Firefox 版本时的手工/自动化参考模板。

阅读 changelog 的正确姿势

最后，把这条日志放回更大的上下文：CHANGELOG/archived/目录按 Grid 版本归档了历史上所有浏览器版本的发布记录，当前最新版本矩阵见 CHANGELOG/README.md 的 "Latest Grid Version" 表（Firefox 列表从 98 一直延伸到 155）。每一格✓都链接到对应firefox_<版本>.md的发布日志。阅读任何一条此类日志时，可按三步快速定位：

1. 看命令参数：确认 Grid 版本（4.34.0）、构建日期（20250727）与是否RELEASE_OLD_VERSION（决定是否有浮动短标签）；
2. 看版本探测结果：确认浏览器（135.0.1）与驱动（0.36.0）的精确版本，以及短版本（135.0/0.36）；
3. 看 Tagged 列表：选择适合自己场景的标签——三者全锁用grid-组，浏览器优先用-<build_date>组，跟随浮动版本则用无日期组（仅在常规发布中存在）。

相关文件索引

• 发布脚本：tag_and_push_browser_images.sh
• 镜像构建：NodeFirefox/Dockerfile、NodeFirefox/install-firefox-apt.sh、NodeFirefox/install-firefox-package.sh、NodeFirefox/get_lang_package.sh
• 运维脚本：NodeFirefox/firefox-cleanup.sh
• 版本矩阵总览：CHANGELOG/README.md
• 构建与发布入口：Makefile
• 使用示例：docker-compose-v3.yml

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