docker-selenium 的 Edge 132 镜像标签体系：从 `tag_and_push_browser_images.sh` 读懂版本号与发布流程

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

本篇技术指南以 docker-selenium 仓库的 edge_132.md 记录为主线，还原一次完整的 Edge 浏览器镜像发布过程，系统拆解tag_and_push_browser_images.sh脚本的标签生成逻辑、Edge 镜像的版本构成规则，以及标签如何与node-edge、standalone-edge镜像一一对应。读完你将能够：读懂任何一条selenium/node-edge或selenium/standalone-edge标签的真实含义，独立运行发布脚本为指定 Grid 版本打标签，并据此精确定位与锁定适合自己测试环境的镜像版本。

一次真实的 Edge 镜像发布记录

CHANGELOG/archived/4.32.0/edge_132.md完整记录了 docker-selenium 在 4.32.0 版本中为 Edge 浏览器镜像执行标签与推送的原始输出：

./tag_and_push_browser_images.sh 4.32.0 20250515 selenium false edge true Tagging images for browser edge, version 4.32.0, build date 20250515, namespace selenium Selenium Grid version -> 4.32.0-20250515 Edge version -> 132.0.2957.140 Short Edge version -> 132.0 EdgeDriver version -> 132.0.2957.140 Short EdgeDriver version -> 132.0 Tagged selenium/node-edge:132.0.2957.140-edgedriver-132.0.2957.140-grid-4.32.0-20250515 Tagged selenium/standalone-edge:132.0.2957.140-edgedriver-132.0.2957.140-grid-4.32.0-20250515 Tagged selenium/node-edge:132.0.2957.140-edgedriver-132.0.2957.140-20250515 Tagged selenium/standalone-edge:132.0.2957.140-edgedriver-132.0.2957.140-20250515 Tagged selenium/node-edge:132.0.2957.140-20250515 Tagged selenium/standalone-edge:132.0.2957.140-20250515 Tagged selenium/node-edge:132.0-edgedriver-132.0-grid-4.32.0-20250515 Tagged selenium/standalone-edge:132.0-edgedriver-132.0-grid-4.32.0-20250515 Tagged selenium/node-edge:132.0-edgedriver-132.0-20250515 Tagged selenium/standalone-edge:132.0-20250515 Tagged selenium/node-edge:132.0-20250515 Tagged selenium/standalone-edge:132.0-20250515

这条命令执行完成后，node-edge与standalone-edge两类镜像各获得 10 个新标签，共 20 个。它展示了 docker-selenium 发布体系中的一个核心动作：对已构建好的浏览器镜像，根据浏览器、驱动与 Grid 的版本信息追加多级语义化标签。

命令参数逐项解析

发布记录的起点是一行可复现的 shell 命令，其参数与 tag_and_push_browser_images.sh 脚本开头的位置参数一一对应：

脚本第 15 行将前两个参数拼接为统一的版本戳：TAG_VERSION=${VERSION}-${BUILD_DATE}，即4.32.0-20250515。第 16 行则做了默认值兜底：NAMESPACE=${NAME:-selenium}，也就是说即便第 3 个参数传空，命名空间也会回退为selenium。

此外脚本还支持两个环境变量（第 12-13 行）：PROMOTE_TAGS与PROMOTE_GHCR_NAMESPACE。当发布流程采用"复用已测试镜像"而非"重新构建"时（由 CI 的 deploy.yml 设置），脚本会跳过docker tag/docker push的本地链路，改用docker buildx imagetools create在 registry 之间直接复制 manifest 索引（第 31-51 行的retag()函数）。这样做的原因在脚本注释中说明得很清楚：docker tag无法表达"镜像从未存在于本地"的情形，而docker pull只能拉回 runner 所在架构的单架构镜像，会破坏多架构 manifest——这正是PROMOTE_TAGS=true路径存在的必要性。

Edge 镜像内版本探测的底层逻辑

标签不是凭空生成的。脚本在edge分支（第 151-192 行）先通过docker run临时启动已构建的 node-edge 镜像，从容器内部解析出三个关键版本号：

1. Edge 浏览器版本：执行microsoft-edge --version并取第 3 个字段（awk '{print $3}'），得到132.0.2957.140；
2. EdgeDriver 版本：执行msedgedriver --version并取第 4 个字段（awk '{print $4}'），得到132.0.2957.140；
3. 短版本号：由short_version()函数（第 53-57 行）对完整版本按.切分后取前两段，得到132.0。

以 Edge 132 为例，完整版本号132.0.2957.140与短版本号132.0同时存在于标签体系中的原因在于：短版本号作为"稳定渠道"的锚点，让用户无需关心 patch 级更新；完整版本号则保证可精确复现。

需要留意的是，edge分支与其他浏览器分支在解析字段上存在差异：Chrome 取--version输出的第 3 个字段、ChromeDriver 取第 2 个字段，而 Edge 的 msedgedriver 输出版本信息时版本号位于第 4 个字段。这些细节是脚本针对不同浏览器二进制输出格式的适配，也解释了为什么发布日志中每个浏览器都有专属字段解析逻辑。

这些版本的来源可以追溯到镜像构建期。NodeEdge/Dockerfile 展示了 Edge 与 EdgeDriver 在镜像内的安装方式：

• Edge 浏览器通过 Microsoft 的 apt 仓库安装，默认EDGE_VERSION="microsoft-edge-stable"（第 16 行）；当需要锁定具体版本时，支持microsoft-edge-stable=132.0.2957.140形式的构建参数，此时会改从EDGE_ARCHIVE_SITE（NDViet/microsoft-edge-stable 的 releases）拉取对应架构的.deb安装（第 24-30 行），以规避 Microsoft 对旧版本的清理；
• EdgeDriver 默认通过msedgedriver.microsoft.com/LATEST_RELEASE_<major>_LINUX获取最新版，若该指针已被 Microsoft 移除，则回退到与浏览器完全一致的版本号，并尝试从归档站点下载edgedriver_linux64.zip或edgedriver_linux-aarch64.zip（第 52-68 行）；
• 构建末尾会把MicrosoftEdge、浏览器版本等信息写入/opt/selenium/browsers/edge/目录（第 82-85 行），供 node 启动时生成浏览器配置（stereotype）使用。

也就是说，发布脚本探测到的版本号，正是 Dockerfile 在构建阶段安装并固定的二进制版本，二者经由镜像本身天然对齐——这正是"标签与镜像内容一致"的保证。

十组标签的生成规则：从精确到简写

脚本在edge分支中先构造了 6 个"基础标签"（第 163-175 行），随后根据RELEASE_OLD_VERSION是否为false再追加 4 个"常规版本标签"（第 176-187 行），最终得到完整版本和短版本两组、每组 5 种形态的标签矩阵。以本次发布为具体示例，可归纳为五类：

1. 浏览器完整版 + 驱动完整版 + Grid 版本（最精确）

selenium/node-edge:132.0.2957.140-edgedriver-132.0.2957.140-grid-4.32.0-20250515 selenium/standalone-edge:132.0.2957.140-edgedriver-132.0.2957.140-grid-4.32.0-20250515

-grid-段后面跟的是TAG_VERSION（Grid 版本 + 构建日期）。这是信息最完整、最适合生产环境锁定版本的标签，浏览器、驱动、Grid、日期四个维度全部固化。

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

selenium/node-edge:132.0.2957.140-edgedriver-132.0.2957.140-20250515

去掉了-grid-段，适用于明确知道某一天构建、但不关心 Grid 版本号的场景。

3. 浏览器完整版 + 构建日期

selenium/node-edge:132.0.2957.140-20250515

只锁定浏览器精确版本与构建日期，驱动跟随镜像内容。

4. 短版本号组合（4 种）

selenium/node-edge:132.0-edgedriver-132.0-grid-4.32.0-20250515 selenium/node-edge:132.0-edgedriver-132.0-20250515 selenium/node-edge:132.0-20250515

三组短版本标签与完整版标签一一对应，只是将浏览器与驱动版本压缩为major.minor。短版本标签的价值在于：当 Edge 发布新的 patch 版本（如 132.0.2957.141）时，132.0系列标签会被新构建覆盖，用户无需修改自己的引用即可获得修复。

5. 仅浏览器版本（仅当RELEASE_OLD_VERSION=false时追加）

selenium/node-edge:132.0.2957.140-edgedriver-132.0.2957.140 selenium/node-edge:132.0.2957.140 selenium/node-edge:132.0-edgedriver-132.0 selenium/node-edge:132.0

这 4 个标签是常规发布（非历史补发）时才会添加的"浮动标签"，省略了日期与 Grid 版本。它们的语义是"这个版本的最新可用形态"，适合开发环境快速取用。当RELEASE_OLD_VERSION=true时（如本次记录），脚本有意跳过这 4 个标签，避免旧版本的浮动标签反过来污染新版本，防止用户误拉到过期组合。

上述规则在 docs/docker-hub/node-edge.md 的"Tagging Conventions"部分也有对应表述：其给出了selenium/node-edge-<browserVersion>-<browserDriver>-<browserDriverVersion>-<Major>.<Minor>.<Patch>-<YYYYMMDD>以及<BrowserMajor>.<BrowserMinor>-edgedriver-<DriverMajor>.<DriverMinor>-grid-...等形态，与脚本生成的标签矩阵完全吻合。

标签与镜像的对应关系：node 与 standalone 成对发布

从发布日志可以清楚看到，脚本的retag()调用模式是成对出现的（第 189-192 行）：

for edge_tag in "${EDGE_TAGS[@]}"; do retag node-edge "${edge_tag}" retag standalone-edge "${edge_tag}" done

即每一组标签都会同时打到node-edge与standalone-edge两个镜像上，保证同一版本的两个镜像形态永远拥有等价的标签。二者的构建关系在 Makefile 的edge_upgrade_version目标中体现：

edge_upgrade_version: cd ./NodeEdge && docker buildx build --platform $(PLATFORMS) $(BUILD_ARGS) \ --build-arg NAMESPACE=$(NAMESPACE) --build-arg VERSION=$(VERSION) \ --build-arg AUTHORS=$(AUTHORS) -t $(NAME)/node-edge:$(TAG_VERSION) . cd ./Standalone && docker buildx build --platform $(PLATFORMS) $(BUILD_ARGS) \ $(FROM_IMAGE_ARGS) --build-arg BASE=node-edge -t $(NAME)/standalone-edge:$(TAG_VERSION) . docker run --rm $(NAME)/standalone-edge:$(TAG_VERSION) microsoft-edge --version docker run --rm $(NAME)/standalone-edge:$(TAG_VERSION) msedgedriver --version

standalone-edge是基于node-edge构建的（--build-arg BASE=node-edge），所以二者的浏览器与驱动版本天然一致，标签自然成对。发布前的验证步骤也复用了与标签脚本相同的探测方式：microsoft-edge --version与msedgedriver --version。

在架构上，docs/docker-hub/node-edge.md 说明node-edge是 Selenium Grid 的 Node 角色（需要配合 Hub 使用），适合分布式 Grid 场景；而standalone-edge则把 Server 与浏览器打包在单容器内，适合独立运行。从镜像构成看，二者都通过wrap_edge_binary对 Edge 启动命令做了包装——NodeEdge/wrap_edge_binary 会把/usr/bin/microsoft-edge重定向到 wrapper 脚本，自动注入--no-sandbox、--lang语言环境变量以及SE_BROWSER_ARGS_前缀环境变量携带的浏览器参数，这也是容器内 Edge 能稳定运行在 rootless 与沙箱受限环境下的基础。

发布编排：Makefile 如何串联整个流程

tag_and_push_browser_images.sh并不是孤立存在的，它被 Makefile 统一编排：

tag_and_push_browser_images: tag_and_push_chrome_images tag_and_push_chrome-for-testing_images \ tag_and_push_chromium_images tag_and_push_firefox_images tag_and_push_edge_images tag_and_push_edge_images: ./tag_and_push_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) edge $(RELEASE_OLD_VERSION)

因此 edge_132.md 中手动执行的命令，在正式发布流程中等价于：

make tag_and_push_edge_images \ VERSION=4.32.0 BUILD_DATE=20250515 NAMESPACE=selenium PUSH_IMAGE=false RELEASE_OLD_VERSION=true

Makefile 还提供tag_and_push_browser_images_ghcr目标（第 798-808 行），它枚举node-edge standalone-edge等镜像，通过docker buildx imagetools create把 Docker Hub 上刚打的标签镜像复制到 GHCR 命名空间，实现多 registry 同步发布。

此外，发布后还需要 update_tag_in_docs_and_files.sh 这类脚本同步更新仓库文档、配置中的版本占位符——发布记录与版本同步脚本共同构成了 docker-selenium 完整、可回溯的发布闭环。

实践：如何读懂并复现一次 Edge 发布

结合以上分析，在实际工作中可以按以下思路使用这份发布记录：

1. 通过标签选择镜像版本

• 生产环境锁版本：使用132.0.2957.140-edgedriver-132.0.2957.140-grid-4.32.0-20250515这类五段式完整标签，浏览器、驱动、Grid、日期全部固定；
• 需要跟随 patch 更新：使用132.0-20250515或132.0短版本标签；
• 需要与本次发布完全一致：直接选用 edge_132.md 中列出的 20 个标签中的任意一个。

2. 复现本次标签动作

cd /data/web/disk1/git_repo/GitHub_Trending/do/docker-selenium ./tag_and_push_browser_images.sh 4.32.0 20250515 selenium false edge true

前置条件：本地已存在selenium/node-edge:4.32.0-20250515与selenium/standalone-edge:4.32.0-20250515镜像（edge_upgrade_version目标产物），且本机已安装 Docker。若希望标签同步推送到 registry，将第 4 个参数改为true（脚本默认false，见第 6 行）。

3. 自定义参数组合

• 换命名空间：./tag_and_push_browser_images.sh 4.32.0 20250515 myorg false edge false；
• 普通新版本发布（追加浮动标签）：把第 6 个参数RELEASE_OLD_VERSION设为false；
• 历史版本补发（不加浮动标签）：保持true，即本次记录所示。

4. 运行 Node 容器验证标签可用性

docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-edge:132.0-20250515

注意：docker-selenium 要求浏览器容器使用--shm-size=2g以保证足够的主机共享内存（docs/docker-hub/node-edge.md 中明确提示）。

总结

CHANGELOG/archived/4.32.0/edge_132.md表面上是 20 行标签输出，背后却是 docker-selenium 一整套可工程化的发布机制：以 tag_and_push_browser_images.sh 为核心的版本探测与标签矩阵生成、以 Makefile 为入口的构建与发布编排、以 NodeEdge/Dockerfile 为根基的浏览器/驱动版本固化，以及 node 与 standalone 镜像的成对标签同步。掌握这套标签体系之后，无论是定位历史版本、锁定生产镜像，还是手动复现发布，都能做到有的放矢——而 Edge 132 这次发布，正是理解整个机制的绝佳样例。

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