企业官网建设流程全解析

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

本篇技术指南以 docker-selenium 仓库 CHANGELOG/archived/4.32.0/firefox_129.md 这份 Firefox 129 发布日志为切入点，完整解读其背后的镜像打标签脚本tag_and_push_browser_images.sh的调用方式、参数语义、标签命名规则与底层实现，并结合 NodeFirefox/Dockerfile 与 docker-compose-v3.yml 说明这些版本化标签如何被构建与消费。读完本文，你将掌握如何阅读 docker-selenium 的版本发布记录、如何手工复现浏览器镜像打标签流程，以及如何按需锁定selenium/node-firefox与selenium/standalone-firefox的精确镜像版本。

这份发布记录讲的是什么

CHANGELOG/archived/4.32.0/firefox_129.md记录了 Selenium Grid 4.32.0 发布周期中 Firefox 浏览器镜像的打标签执行过程。它本质上是一次tag_and_push_browser_images.sh脚本运行的完整控制台输出：脚本先打印本次任务的关键版本信息，再依次为node-firefox与standalone-firefox两类镜像生成一组标签。这份记录文件本身即属于仓库的变更日志体系（CHANGELOG/目录按发布版本与浏览器维度归档），归档版本位于 CHANGELOG/archived/4.32.0/，是研究发布流水线的第一手素材。

记录中确认的核心版本组合如下：

其中4.32.0-20250505是 Selenium Grid 版本号与构建日期的组合（TAG_VERSION=${VERSION}-${BUILD_DATE}），也是本次发布的主标签基线。

命令参数逐位拆解

发布记录第一行给出了触发命令：

./tag_and_push_browser_images.sh 4.32.0 20250505 selenium false firefox true

对照脚本 tag_and_push_browser_images.sh 第 3～9 行的参数定义，这 7 个位置参数含义如下：

注意第 6 个参数为true（RELEASE_OLD_VERSION=true），它直接影响最终标签数量——这一点会在下文"标签命名规则"中详细展开。该脚本通常由 Makefile 的tag_and_push_firefox_images目标经tag_and_push_browser_images汇总目标（Makefile）调用，$(VERSION)、$(BUILD_DATE)、$(NAMESPACE)、$(PUSH_IMAGE)、$(RELEASE_OLD_VERSION)均为 Makefile 变量注入。

版本探测：版本号从哪来

脚本并没有硬编码 Firefox 与 GeckoDriver 版本号，而是通过docker run临时启动刚构建好的node-firefox:4.32.0-20250505镜像，在容器内执行浏览器/驱动程序的--version命令并解析输出（脚本第 197、201 行）：

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

• firefox --version的输出形如Mozilla Firefox 129.0.2，取第 3 列得到129.0.2；
• geckodriver --version的第一行包含geckodriver 0.36.0，取第 2 列得到0.36.0；
• 短版本由脚本内定义的short_version()函数（脚本第 53～57 行）取前两段生成：129.0.2 → 129.0、0.36.0 → 0.36。

这种"运行时探测"保证了标签始终与镜像内实际安装的二进制版本严格一致，避免手工维护版本号造成漂移。版本来源可进一步追溯至 NodeFirefox/Dockerfile 的构建阶段：Firefox 通过install-firefox-apt.sh（apt 安装firefox系列包）或install-firefox-package.sh（下载 Mozilla 官方.deb/.tar.bz2安装包）安装，GeckoDriver 则从 Mozilla 官方 GitHub Releases 下载对应架构的压缩包（Dockerfile 第 76～86 行），并按版本归档为/opt/geckodriver-$GK_VERSION后软链到/usr/bin/geckodriver。构建结束时，Firefox 版本、浏览器名与二进制路径还会被写入/opt/selenium/browsers/firefox/下的name、version、binary_location文件（Dockerfile 第 93～96 行），供 Selenium Grid 节点启动时读取浏览器能力信息。

标签命名规则：6 组标签的构成

日志中，firefox分支在RELEASE_OLD_VERSION=true时生成了 6 个标签（脚本第 206～218 行的基础数组），每个标签同时作用于node-firefox与standalone-firefox两个镜像，因此共 12 行Tagged输出。标签可归纳为三类格式：

1. 完整版本 + 驱动 + Grid 主版本（精确锁定到补丁级与构建日）：129.0.2-geckodriver-0.36.0-grid-4.32.0-20250505
2. 完整版本 + 驱动 + 构建日期（不含 Grid 版本）：129.0.2-geckodriver-0.36.0-20250505
3. 完整版本 + 构建日期：129.0.2-20250505

上述三组各再生成一个"短版本"变体（129.0/0.36），形成另外三组标签：

• 129.0-geckodriver-0.36-grid-4.32.0-20250505
• 129.0-geckodriver-0.36-20250505
• 129.0-20250505

对应的数组定义见脚本第 206～218 行，例如首个元素为${FIREFOX_VERSION}-geckodriver-${GECKODRIVER_VERSION}-grid-${TAG_VERSION}，其中${TAG_VERSION}即4.32.0-20250505。

关键点在于RELEASE_OLD_VERSION分支（脚本第 219～230 行）：当该参数为false时，脚本会追加4 个不含 Grid 版本/构建日期的"日常使用"标签，例如129.0.2-geckodriver-0.36.0、129.0.2、129.0-geckodriver-0.36、129.0；而当其为true时则跳过追加。本次发布日志第 6 个参数为true，所以恰好只输出 12 个标签——这解释了日志末尾没有出现纯版本号标签的原因。这正对应 Makefile 注释中引用的 issue 背景（打标签行为随RELEASE_OLD_VERSION开关而变化）。

底层打标签机制：retag 函数

每个标签都由脚本内的retag()函数（脚本第 31～51 行）处理，源镜像统一为${NAMESPACE}/node-firefox:${TAG_VERSION}（即selenium/node-firefox:4.32.0-20250505）。默认路径下执行：

docker tag "${__source}" "${NAMESPACE}/${__image}:${__tag}" docker push ... # 仅当 PUSH_IMAGE=true 时

本次PUSH_IMAGE=false，因此只是本地打标签而不推送。此外，脚本支持发布流水线中的两种进阶模式：

• PROMOTE_TAGS=true（脚本第 12 行，由 CI 的deploy.yml在"直接提升已测试镜像而非重新构建"时注入）：改用docker buildx imagetools create在 registry 间直接复制 manifest，避免本地docker pull只能取回单架构镜像、导致多架构索引丢失的问题；
• PROMOTE_GHCR_NAMESPACE（脚本第 13、38～40 行）：在同一调用内同时向 GHCR 命名空间镜像标签，解决"本路径下本地镜像存储为空、后续docker images发现不到待镜像标签"的困境。

这两处设计均为构建器/CI 上下文服务的，普通使用者不需要关心，但有助于理解日志中每条Tagged输出背后的发布语义。

如何消费这些版本化标签

通过 docker compose 使用固定版本

仓库根目录的 docker-compose-v3.yml 是标准 Selenium Grid 三节点示例，其中 Firefox 节点固定引用selenium/node-firefox:4.48.0-20260905（第 23～29 行），并配置shm_size: 2gb与SE_EVENT_BUS_HOST=selenium-hub环境变量：

firefox: image: selenium/node-firefox:4.48.0-20260905 shm_size: 2gb depends_on: - selenium-hub environment: - SE_EVENT_BUS_HOST=selenium-hub

对照可知：日常拉取时应优先选择"短版本"标签（如129.0-geckodriver-0.36-grid-4.32.0-20250505）以锁定浏览器主版本与驱动兼容组合；而发布记录中的129.0.2-geckodriver-0.36.0-grid-4.32.0-20250505这类全量标签适合在需要精确复现补丁级版本（如排查 Firefox 129.0.2 特有行为）时使用。

手工验证镜像内版本

无论选择哪个标签，都可沿用脚本同款方式核对容器内实际版本：

docker run --rm selenium/node-firefox:129.0-geckodriver-0.36-grid-4.32.0-20250505 firefox --version docker run --rm selenium/node-firefox:129.0-geckodriver-0.36-grid-4.32.0-20250505 geckodriver --version

复现发布打标签流程

若需在本地为已构建的镜像复现同样流程（例如自建私有 registry 时），可参考 Makefile 的tag_and_push_firefox_images目标调用脚本；该目标也是tag_and_push_browser_images（Makefile）的五种浏览器汇总目标之一。注意脚本会以docker run探测镜像内版本，因此要求本机已存在selenium/node-firefox:${VERSION}-${BUILD_DATE}镜像或可从远端拉取。

小结

CHANGELOG/archived/4.32.0/firefox_129.md不是一段孤立的日志，而是 docker-selenium 发布流水线中"浏览器镜像打标签"环节的完整快照：它展示了tag_and_push_browser_images.sh如何通过运行时版本探测生成覆盖完整/短版本、驱动版本、Grid 版本与构建日期的 6 组标签，如何受RELEASE_OLD_VERSION开关控制标签集合，以及retag()在本地打标与 CI 多架构提升两种模式下的行为差异。掌握这些信息后，读者既能精确阅读任意版本的发布记录，也能在自己的环境中按需锁定、验证乃至复现 Firefox 相关镜像的版本化发布。

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