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

导读

本文以 CHANGELOG/archived/4.31.0/firefox_114.md 这份发布记录为线索，完整解读 docker-selenium 项目在 Selenium Grid 4.31.0（构建日期 20250414）发布时，如何为 Firefox 114.0.2 + GeckoDriver 0.36.0 生成并打上 12 个镜像标签。通过本文，你将掌握 docker-selenium 的镜像标签命名约定（Tagging Convention）、tag_and_push_browser_images.sh的标签生成逻辑、RELEASE_OLD_VERSION参数的历史版本发布策略，以及如何在实战中为自己的 WebDriver 测试选择最合适的 Firefox 镜像标签。

从一份发布记录说起：firefox_114.md 记录了什么

这份位于CHANGELOG/archived/4.31.0/目录下的文件，本质是 docker-selenium 项目 4.31.0 版本发布时，为历史浏览器版本 Firefox 114重建镜像并打标签的完整执行日志。记录的核心信息如下：

./tag_and_push_browser_images.sh 4.31.0 20250414 selenium false firefox true Tagging images for browser firefox, version 4.31.0, build date 20250414, namespace selenium Selenium Grid version -> 4.31.0-20250414 Firefox version -> 114.0.2 Short Firefox version -> 114.0 GeckoDriver version -> 0.36.0 Short GeckoDriver version -> 0.36

将命令与 tag_and_push_browser_images.sh 的参数定义对照（见第 3–8 行），可以还原出这次调用的完整参数语义：

日志中Selenium Grid version -> 4.31.0-20250414对应脚本第 15 行TAG_VERSION=${VERSION}-${BUILD_DATE}拼接出的镜像基准标签，而 Firefox、GeckoDriver 的版本号则是在运行时通过docker run启动对应镜像、执行firefox --version与geckodriver --version探测得到的。

镜像标签体系：一次发布生成哪些标签

这份记录最核心的价值，是完整展示了 docker-selenium 对selenium/node-firefox与selenium/standalone-firefox两类镜像的一次性标签矩阵。日志中共输出 12 个标签，按镜像划分各 6 个：

node-firefox 镜像：

selenium/node-firefox:114.0.2-geckodriver-0.36.0-grid-4.31.0-20250414 selenium/node-firefox:114.0.2-geckodriver-0.36.0-20250414 selenium/node-firefox:114.0.2-20250414 selenium/node-firefox:114.0-geckodriver-0.36-grid-4.31.0-20250414 selenium/node-firefox:114.0-geckodriver-0.36-20250414 selenium/node-firefox:114.0-20250414

standalone-firefox 镜像：

selenium/standalone-firefox:114.0.2-geckodriver-0.36.0-grid-4.31.0-20250414 selenium/standalone-firefox:114.0.2-geckodriver-0.36.0-20250414 selenium/standalone-firefox:114.0.2-20250414 selenium/standalone-firefox:114.0-geckodriver-0.36-grid-4.31.0-20250414 selenium/standalone-firefox:114.0-geckodriver-0.36-20250414 selenium/standalone-firefox:114.0-20250414

这些标签并非随意堆砌，而是由 tag_and_push_browser_images.sh 中FIREFOX_TAGS数组按固定模板生成的。以完整版本与短版本为两条主线，组合出三种信息粒度：

1. 完整信息标签：<Firefox版本>-geckodriver-<GeckoDriver版本>-grid-<Grid版本>-<构建日期>，例如114.0.2-geckodriver-0.36.0-grid-4.31.0-20250414，包含浏览器、驱动、Grid 与构建日期的全部信息，可精确复现某次发布；
2. 构建日期标签：<Firefox版本>-geckodriver-<GeckoDriver版本>-<构建日期>与<Firefox版本>-<构建日期>，标识"某一天构建的某浏览器版本"；
3. 短版本标签：将 Firefox114.0.2截断为114.0、GeckoDriver0.36.0截断为0.36后生成的对应标签，便于在只关心大版本时使用。

其中"短版本"由脚本第 53–57 行的short_version()函数实现：按.拆分版本号后仅保留前两段，例如114.0.2 -> 114.0、0.36.0 -> 0.36。日志中Short Firefox version -> 114.0与Short GeckoDriver version -> 0.36正是该函数的输出。

RELEASE_OLD_VERSION 参数：旧版本发布的标签策略

细心的读者会发现：这份 4.31.0 的发布记录只生成了 6 组标签，但脚本源码中FIREFOX_TAGS在RELEASE_OLD_VERSION为 false 时还会追加 4 个纯版本标签（不含构建日期）：

FIREFOX_TAGS+=( # Browser version and browser driver version ${FIREFOX_VERSION}-geckodriver-${GECKODRIVER_VERSION} # Browser version ${FIREFOX_VERSION} # Browser version and browser driver version ${FIREFOX_SHORT_VERSION}-geckodriver-${GECKODRIVER_SHORT_VERSION} # Browser version ${FIREFOX_SHORT_VERSION} )

见 tag_and_push_browser_images.sh。这意味着如果RELEASE_OLD_VERSION=false，还会额外生成114.0.2-geckodriver-0.36.0、114.0.2、114.0-geckodriver-0.36、114.0四个标签。

而本次调用传入的第六个参数为true，脚本因此跳过了这组追加标签。原因在于：Firefox 114 是历史版本。docker-selenium 在每个 Selenium Grid 新版本发布时，除了为当前主推浏览器版本生成包含纯版本号的"滚动标签"（如selenium/node-firefox:114.0，会随每次发布更新指向新构建），还会为全部历史浏览器版本重建镜像。若历史版本也抢占114.0这类纯版本标签，就会与主推版本发生标签冲突。因此归档版本发布一律携带RELEASE_OLD_VERSION=true，只保留含构建日期或完整信息锚定点的标签，确保114.0这类短标签永远由最新发布持有。

这也解释了CHANGELOG/archived/与CHANGELOG/4.48.0/下为何会按版本号存放firefox_98.md、firefox_100.md、chrome_95.md、edge_114.md等大量历史浏览器发布记录：它们共同构成了项目"向后兼容构建矩阵"的档案。

标签生成背后的源码：tag_and_push_browser_images.sh 的 firefox 分支

tag_and_push_browser_images.sh 的firefoxcase 分支完整演示了标签生成的执行链路：

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.31.0-20250414为基准镜像，临时启动容器读取浏览器与驱动的真实版本号。注意这里docker run未指定--platform，而 Chrome 分支（第 65 行）显式使用了--platform ${PLATFORM}，这是因为 Firefox 在 docker-selenium 中同时支持 amd64 与 arm64 架构，直接运行即可探测当前架构下的版本。

随后生成的每个标签都通过retag()函数（第 31–51 行）落地：

docker tag "${__source}" "${NAMESPACE}/${__image}:${__tag}" if [ "${PUSH_IMAGE}" = true ]; then docker push "${NAMESPACE}/${__image}:${__tag}" fi

即先用docker tag为基准镜像追加别名，若PUSH_IMAGE=true则随后推送到 Docker Hub。日志中PUSH_IMAGE为 false，说明这是一次本地打标签操作，推送由发布流水线的后续环节完成。此外，脚本还支持PROMOTE_TAGS=true的发布晋升模式（第 36–44 行），此时改用docker buildx imagetools create在镜像仓库索引层面直接复制 manifest，从而保持多架构（multi-arch）标签完整性，这是新版本发布时"测试镜像直接晋升为发布镜像"的关键机制。

如何在实战中选择正确的 Firefox 镜像标签

docs/docker-hub/node-firefox.md 与 docs/docker-hub/standalone-firefox.md 对标签选择给出了官方指引。标签的基础结构为：

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

以及叠加浏览器与驱动版本的完整形态：

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

结合本次发布记录，实战选标签时可遵循以下原则：

• 追求可复现性：选择114.0.2-geckodriver-0.36.0-grid-4.31.0-20250414这类完整标签，浏览器、驱动、Grid、构建日期全部锁定，适合 CI 流水线固化版本；
• 只关心浏览器版本：选择114.0.2-20250414或短版本114.0-20250414，适合对 GeckoDriver 版本不敏感的日常开发；
• 跟随最新发布：使用latest或114.0等滚动标签，但注意其指向会随新版本发布而变化，不适合需要严格版本管理的生产环境。docs 文档明确建议优先使用完整标签以锁定具体浏览器与 Grid 版本。

用正确的标签运行 Firefox 节点与 Standalone

docker-selenium 提供两种 Firefox 部署形态，均可用上述标签拉取运行。

Node 模式（配合 Hub 组成 Grid，见 docs/docker-hub/node-firefox.md）：

docker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:latest docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-firefox:114.0.2-geckodriver-0.36.0-grid-4.31.0-20250414

Standalone 模式（单容器同时承载 Grid 与浏览器，见 docs/docker-hub/standalone-firefox.md）：

docker run -d -p 4444:4444 -p 7900:7900 --shm-size="2g" \ selenium/standalone-firefox:114.0.2-geckodriver-0.36.0-grid-4.31.0-20250414

启动后，将 WebDriver 测试指向http://localhost:4444即可远程驱动 Firefox。两个要点需要特别注意：

• --shm-size="2g"是必选项：包含浏览器的镜像必须挂载 2g 宿主共享内存，否则 Firefox 在容器内可能因/dev/shm空间不足而崩溃；
• 可选的可视化调试：访问http://localhost:7900/?autoconnect=1&resize=scale&password=secret可查看容器内的浏览器画面（noVNC 界面由 NodeBase/start-novnc.sh 提供）。

Firefox 镜像构建：NodeFirefox/Dockerfile 的版本实现

Firefox 114.0.2 之所以能与 Grid 4.31.0 组合，根源在 NodeFirefox/Dockerfile 的构建逻辑。该 Dockerfile 以node-base为基础镜像，通过构建参数控制版本：

ARG FIREFOX_VERSION=latest ARG FIREFOX_DOWNLOAD_URL=""

构建时会根据FIREFOX_VERSION选择安装策略：对于latest、beta-latest、nightly-latest等通道值调用 install-firefox-apt.sh 走 apt 仓库安装；对于明确的数字版本（如 114.0.2）则拼接 Mozilla 官方下载地址，交由 install-firefox-package.sh 下载.deb或.tar.bz2安装，随后调用 get_lang_package.sh 补充语言包。构建末尾还会执行一次apt-get upgrade修复依赖组件的 CVE。

GeckoDriver 的安装独立成段（第 75–86 行）：默认解析最新 release 版本号，按amd64/aarch64分别下载linux64/linux-aarch64压缩包，解压到/opt/geckodriver-<版本>并通过软链接固定到/usr/bin/geckodriver——这正是 NodeBase/start-selenium-node.sh 中-Dwebdriver.gecko.driver=/usr/bin/geckodriver这一 JVM 属性所指向的驱动路径。

镜像构建完成后，还会把浏览器信息写入/opt/selenium/browsers/firefox/（第 93–96 行），记录名称、版本与二进制路径，供 Grid 节点注册能力时读取。firefox --version | awk '{print $3}'与打标签脚本中的版本探测命令完全一致，保证"构建时记录的版本"与"发布时标记的版本"同源。

发布流水线：从构建到打标签的自动化链路

在完整发布流程中，本次 firefox_114.md 记录的打标签动作只是其中一环。从 Makefile 可以还原整条链路：

1. 构建浏览器镜像：make firefox目标（第 590–593 行）先构建node_base，再在 NodeFirefox 目录构建node-firefox:<TAG_VERSION>；make standalone_firefox（第 614–617 行）在此基础上叠加 Standalone 层；
2. 生成版本矩阵：make update_browser_versions_matrix（第 400–405 行）调用tests/build-backward-compatible/下的脚本抓取各浏览器渠道的最新版本，其中就包含 Firefox 版本抓取脚本，维护"每个 Grid 版本对应哪些浏览器版本"的向后兼容矩阵；
3. 打标签：make tag_and_push_firefox_images（第 795–796 行）调用tag_and_push_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) firefox $(RELEASE_OLD_VERSION)——本次发布记录中的命令正是该目标的一个具体实例；
4. 生成发布说明：generate_release_notes.sh 会再次通过docker run探测各镜像内的 Firefox 与 GeckoDriver 版本（第 23–24 行），以 amd64/arm64 双列形式写入发布表格，与打标签日志互相印证。

这套流水线保证了：每个 Grid 版本发布时，主推浏览器版本获得完整标签与滚动标签，全部历史浏览器版本获得带构建日期与完整信息的归档标签，从而让用户可以在任意时间点精确拉取"某 Grid 版本 + 某 Firefox 版本 + 某 GeckoDriver 版本"的确定性组合。

总结

CHANGELOG/archived/4.31.0/firefox_114.md表面上是 21 行打标签日志，实质是 docker-selenium 镜像版本管理体系的一个缩影。通过它你可以掌握：标签的三段式信息粒度与短版本截断规则、RELEASE_OLD_VERSION对历史版本标签的约束逻辑、tag_and_push_browser_images.sh从版本探测到docker tag/docker push的完整执行链路，以及Makefile与构建脚本串联起的"构建 — 打标签 — 生成发布说明"自动化发布流水线。当你在 CI 中需要锁定一个可复现的 Firefox 测试环境时，理解这套标签体系将让你能精确、安全地选择镜像。

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