Docker Selenium 4.31.0 Edge 130 镜像标签生成全解析：从 tag_and_push_browser_images.sh 到可用的 node-edge/standalone-edge 镜像

本篇技术指南围绕 CHANGELOG/archived/4.31.0/edge_130.md 展开，完整解读 Docker Selenium 项目在 Grid 4.31.0 版本发布时，如何为 Edge 130.0.2849.80 与 EdgeDriver 130.0.2849.78 生成并推送 node-edge、standalone-edge 两类镜像的全部标签。读完后你将掌握：浏览器版本标签的完整构成与命名约定、tag_and_push_browser_images.sh 的底层实现原理、Edge 镜像在 NodeEdge/Dockerfile 中的构建方式，以及如何在 Selenium Grid 中实际拉取与使用这些固定版本标签。

一、发布背景：一次 Edge 130 的镜像标签发布记录

在 4.31.0 版本发布周期中，项目的发布流水线通过执行 tag_and_push_browser_images.sh 脚本，为 Edge 130 浏览器镜像批量打上标签并推送到容器仓库。关联文档 edge_130.md 记录了这一过程在构建日期 20250414、命名空间 selenium 下的完整输出，其核心信息如下：

./tag_and_push_browser_images.sh 4.31.0 20250414 selenium false edge true
Tagging images for browser edge, version 4.31.0, build date 20250414, namespace selenium
Selenium Grid version -> 4.31.0-20250414
Edge version -> 130.0.2849.80
Short Edge version -> 130.0
EdgeDriver version -> 130.0.2849.78
Short EdgeDriver version -> 130.0

这段输出揭示了本次发布的版本组合：

组件	完整版本	短版本
Selenium Grid Server	4.31.0-20250414	-
Microsoft Edge	130.0.2849.80	130.0
EdgeDriver (msedgedriver)	130.0.2849.78	130.0

关于参数的取值来源，可以从 Makefile 中找到佐证：tag_and_push_browser_images 目标是 tag_and_push_chrome_images、tag_and_push_edge_images 等多个子目标的聚合，其中 tag_and_push_edge_images 正是以 $(VERSION)、$(BUILD_DATE)、$(NAMESPACE)、$(PUSH_IMAGE)、edge、$(RELEASE_OLD_VERSION) 的顺序调用该脚本，与文档第 2 行的命令参数一一对应。

二、命令参数逐一拆解：五个位置参数各司其职

从脚本头部定义（tag_and_push_browser_images.sh）可以看到完整的参数语义：

参数	位置	默认值	本次调用值	含义
VERSION	1	无	4.31.0	Selenium Grid 版本号
BUILD_DATE	2	无	20250414	构建日期（YYYYMMDD）
NAMESPACE	3	无	selenium	镜像命名空间
PUSH_IMAGE	4	false	false	是否在打标签后执行 docker push
BROWSER	5	无	edge	浏览器类型
RELEASE_OLD_VERSION	6	false	true	是否为旧版本补发标签
PLATFORM	7	linux/amd64	-	目标平台

需要特别说明两点：

1. RELEASE_OLD_VERSION=true 的含义：从脚本的 case 分支可以看到，当该参数为 false（即正常发布）时，会额外追加"浏览器版本 + 驱动版本"、"纯浏览器版本"、"短版本 + 驱动版本"、"纯短版本"这 4 组不带构建日期的标签（tag_and_push_browser_images.sh）；而当其为 true（如本文档对应的补发场景）时，只生成带 -20250414 构建日期的标签。对照关联文档第 9-20 行的输出，所有标签均包含日期后缀，与 true 的行为一致——这也解释了为什么文档中没有出现 selenium/node-edge:130.0 这类不带日期的精简标签。
2. PUSH_IMAGE=false 的含义：脚本的 retag 函数在 PUSH_IMAGE = true 时才会执行 docker push（tag_and_push_browser_images.sh），本次调用为 false，因此文档输出只展示了 Tagged ... 的本地打标签结果。

三、标签生成规则：全版本、短版本、构建日期的组合矩阵

3.1 版本信息如何获得

脚本在 edge) 分支中，通过临时启动已构建好的 node-edge 镜像来探测浏览器与驱动的真实版本（tag_and_push_browser_images.sh）：

EDGE_VERSION=$(docker run --rm ${NAMESPACE}/node-edge:${TAG_VERSION} microsoft-edge --version | awk '{print $3}')
EDGEDRIVER_VERSION=$(docker run --rm ${NAMESPACE}/node-edge:${TAG_VERSION} msedgedriver --version | awk '{print $4}')

• microsoft-edge --version 输出形如 Microsoft Edge 130.0.2849.80，取第 3 列得到 130.0.2849.80；
• msedgedriver --version 输出中第 4 列即为 130.0.2849.78；
• short_version 函数（tag_and_push_browser_images.sh）按 . 切分版本号，只保留前两段，从而得到短版本 130.0，作为精简标签的依据。

3.2 六类标签的完整构成

关联文档第 9-20 行逐行列出了本次生成的全部 12 个标签（node-edge 与 standalone-edge 各 6 个），按格式可分为以下三类，每类又分为长/短版本两种：

第一类：全信息标签（长版本）

selenium/node-edge:130.0.2849.80-edgedriver-130.0.2849.78-grid-4.31.0-20250414
selenium/standalone-edge:130.0.2849.80-edgedriver-130.0.2849.78-grid-4.31.0-20250414

构成规则为 浏览器版本-edgedriver-驱动版本-grid-Grid版本-构建日期，是信息最完整、定位最精确的标签，适用于需要完全固定浏览器、驱动与 Grid 三方版本的 CI 场景。

第二类：浏览器 + 构建日期标签

selenium/node-edge:130.0.2849.80-20250414
selenium/standalone-edge:130.0.2849.80-20250414

构成规则为 浏览器版本-构建日期，适用于只关注浏览器主版本与发布时间的场景。

第三类：短版本标签（全部基于 130.0）

selenium/node-edge:130.0-edgedriver-130.0-grid-4.31.0-20250414
selenium/node-edge:130.0-edgedriver-130.0-20250414
selenium/node-edge:130.0-20250414

短版本标签只锁定浏览器与驱动的主次版本（130.0），底层实际指向包含补丁版本（130.0.2849.x）的镜像。在 docs/docker-hub/node-edge.md 的标签约定说明中同样给出了 <Major>.<Minor>-edgedriver-<DriverMajor>.<DriverMinor>-grid-<Grid版本>-<YYYYMMDD> 的完整格式，两者相互印证。

3.3 同一组标签的生成逻辑

从 tag_and_push_browser_images.sh 的源码可以看到，脚本先用数组 EDGE_TAGS 收集全部标签后缀，再通过双重循环同时对 node-edge 和 standalone-edge 两个镜像执行 retag：

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

这解释了关联文档中每一行标签都成对出现（node 与 standalone 各一份）的原因——一次发布同时覆盖 Grid 集群的节点镜像与单机模式镜像。

四、retag 背后的推送机制：普通打标签与 Promote 模式

retag 函数（tag_and_push_browser_images.sh）是发布流水线的关键环节，其行为由环境变量 PROMOTE_TAGS 决定：

• 普通模式（PROMOTE_TAGS=false，默认）：先执行 docker tag 将 selenium/node-edge:4.31.0-20250414 复制为新标签；若 PUSH_IMAGE=true 再执行 docker push 推送。关联文档对应的 PUSH_IMAGE=false 场景只停留在本地打标签。
• Promote 模式（PROMOTE_TAGS=true）：跳过本地 docker tag，改用 docker buildx imagetools create 在 registry 之间直接复制 manifest。脚本注释明确说明其原因：docker tag 无法表达"已发布镜像的多架构 manifest"——docker pull 只会带回来执行机所在架构的单架构镜像，而 release 标签需要保留多架构索引。若同时设置了 PROMOTE_GHCR_NAMESPACE，则会在同一次调用中把标签同步镜像到 GHCR 命名空间。

从 Makefile 的 tag_and_push_browser_images_ghcr 目标还可以看到另一种 GHCR 镜像方式：遍历本地 docker images 中的全部标签，逐一用 docker buildx imagetools create --tag $(GHCR_NAMESPACE)/... 复制到 GHCR 命名空间。

五、源码纵深：Edge 镜像里到底是什么版本

理解标签背后的版本组合，需要回到镜像构建源头 NodeEdge/Dockerfile。

5.1 浏览器安装：官方源与版本归档回退

Dockerfile 通过 EDGE_VERSION 构建参数控制 Edge 安装（NodeEdge/Dockerfile）：

• 默认值为 microsoft-edge-stable，此时直接从 Microsoft 官方 apt 源（packages.microsoft.com/repos/edge）安装最新稳定版；
• 若要固定历史版本（如 130.0.2849.80），格式为 microsoft-edge-stable=130.0.2849.80-1，脚本会检测到该模式后，从归档站点 EDGE_ARCHIVE_SITE（NDViet/microsoft-edge-stable 的 GitHub Releases）下载对应版本号与架构的 .deb 包，并使用 --allow-downgrades 安装。注释特别说明：Microsoft 会从 packages.microsoft.com 清除旧版本，因此历史版本必须走归档通道。

5.2 驱动安装：LATEST_RELEASE 探测与双通道下载

EdgeDriver（msedgedriver）的安装逻辑（NodeEdge/Dockerfile）体现了完整的版本匹配策略：

1. 若未显式指定 EDGE_DRIVER_VERSION，先解析出 Edge 主版本号（如 130），访问 https://msedgedriver.microsoft.com/LATEST_RELEASE_130_LINUX 获取官方推荐的最新驱动版本；
2. 若该探测接口失效（Microsoft 会清除旧版 msedgedriver 构建及对应的 LATEST_RELEASE_<major> 指针），则直接使用与浏览器完全一致的版本号；
3. 下载同样有双通道：优先官方 msedgedriver.microsoft.com/<版本>/edgedriver_<架构>.zip，失败则回退到归档站点；架构方面 amd64 对应 linux64，其余架构对应 linux-aarch64。

安装完成后，驱动被重命名为 msedgedriver-<版本> 并软链接到 /usr/bin/msedgedriver——这正是上一节探测命令 msedgedriver --version 能直接执行的原因。

5.3 浏览器信息导出与 Node 配置

Dockerfile 末尾（NodeEdge/Dockerfile）将 Edge 信息写入 /opt/selenium/browsers/edge/ 目录：

echo "MicrosoftEdge" > /opt/selenium/browsers/edge/name
microsoft-edge --version | awk '{print $3}' > /opt/selenium/browsers/edge/version
echo '{"ms:edgeOptions": {"binary": "${SE_BROWSER_BINARY_LOCATION:-/usr/bin/microsoft-edge}"}}' > /opt/selenium/browsers/edge/binary_location

同时设置 SE_OTEL_SERVICE_NAME="selenium-node-edge" 与 SE_NODE_ENABLE_MANAGED_DOWNLOADS="true"。此外，wrap_edge_binary 会被拷贝到 /opt/bin/wrap_edge_binary 并执行，用于包装 Edge 启动命令，确保以正确参数拉起浏览器。

六、实战：如何拉取并使用这批 Edge 130 标签

6.1 在 Docker Compose 全网格中使用固定版本

在 Selenium Grid 中，Hub 与 Node 通过同一 Docker 网络和容器名互相发现（参考 docs/docker-hub/node-edge.md 的启动流程）。以本次发布的标签为例，可以直接从 docker-compose-v3.yml 这类编排文件（如仓库根目录下的 docker-compose-v3.yml）替换 node 镜像版本：

services:
  node-edge:
    image: selenium/node-edge:130.0.2849.80-edgedriver-130.0.2849.78-grid-4.31.0-20250414
    shm_size: 2gb
    depends_on:
      - selenium-hub
    environment:
      - SE_EVENT_BUS_HOST=selenium-hub
      - SE_EVENT_BUS_PUBLISH_PORT=4442
      - SE_EVENT_BUS_SUBSCRIBE_PORT=4443

6.2 独立 Node 与 Standalone 两种运行方式

若需要单独运行 Node，可按 docs/docker-hub/node-edge.md 中的三步流程操作：

docker network create grid
docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:4.31.0-20250414
docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \
    --shm-size="2g" \
    selenium/node-edge:130.0-edgedriver-130.0-grid-4.31.0-20250414

注意：包含浏览器的镜像必须使用 --shm-size=2g 或等价方式放大共享内存，否则浏览器进程可能因 /dev/shm 不足而崩溃。

若不需要 Hub/Node 架构，直接使用单机镜像（Standalone/Dockerfile 基于 node-base 构建，暴露 4442-4444 端口并内置完整 Grid 服务器）：

docker run -d -p 4444:4444 --shm-size="2g" \
    selenium/standalone-edge:130.0-20250414

随后将 WebDriver 测试指向 http://localhost:4444 即可。需要观察容器内浏览器界面时，可访问 VNC 前端 http://localhost:7900/?autoconnect=1&resize=scale&password=secret。

6.3 在版本矩阵中快速定位

CHANGELOG/README.md 维护了"Grid 版本 × 浏览器版本"的完整矩阵：在 Archived Grid Versions 的 Edge 表格中，4.31.0 行覆盖了 Edge 114 至 134 的各个版本，每个 ✓ 都链接到对应的详细发布记录文档（如本文档 edge_130.md）。该 README 还明确指出：项目并未对每个 Grid 与浏览器的组合做全量测试，用户需根据自身测试需求评估后选择标签——这也是发布方建议尽量使用完整标签固定版本、避免 latest 的原因。

七、小结：读懂一份浏览器发布记录的三个层次

一份看似只有 21 行的 edge_130.md，实际承载了三层信息：

1. 结果层：Grid 4.31.0 与 Edge 130.0.2849.80 / EdgeDriver 130.0.2849.78 的版本组合，以及 12 个正式发布的镜像标签；
2. 机制层：tag_and_push_browser_images.sh 以"探测真实版本 → 拼装标签数组 → 双镜像循环 retag → 可选 push"的流水线实现标签生成，并通过 RELEASE_OLD_VERSION、PROMOTE_TAGS 等开关区分补发旧版本、多架构 promote 等不同发布场景；
3. 构建层：NodeEdge/Dockerfile 中官方源 + 归档站点的双通道安装策略，保证了历史浏览器版本的可复现性。

当你在 CI 中需要固定某个浏览器版本做回归测试时，参考本文档对应的标签（如 selenium/node-edge:130.0-20250414）即可精确复现与本次发布完全一致的环境；当浏览器或驱动版本被上游厂商清理时，镜像构建侧的双通道回退机制也保证了这些历史标签的可追溯性。