企业官网建设流程全解析

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

导读

本文围绕 CHANGELOG/archived/4.35.0/edge_131.md 这份发布变更记录展开，深入剖析 docker-selenium 项目在 Selenium Grid 4.35.0 版本中随 Edge 131.0.2903.147 一同发布的node-edge与standalone-edge镜像的完整标签命名体系、底层生成脚本逻辑与镜像构建原理。读完本文，你将能够准确解读 docker-selenium 浏览器镜像的每一个标签片段，理解 Edge 131 这类历史版本镜像在仓库中的归档位置与检索方式，并掌握如何按需拉取、运行这些镜像进行跨浏览器测试。

一、发布快照：Edge 131.0.2903.147 × Selenium Grid 4.35.0

edge_131.md记录了 4.35.0 版本（构建日期 20250909，即 2025 年 9 月 9 日）发布 Edge 131 浏览器镜像时的完整打标签日志，其触发命令为：

./tag_and_push_browser_images.sh 4.35.0 20250909 selenium false edge true

命令执行后识别出的版本组合如下：

日志随后为selenium/node-edge与selenium/standalone-edge两个镜像各打上了 6 组核心标签（共 12 行输出）：

Tagged selenium/node-edge:131.0.2903.147-edgedriver-131.0.2903.147-grid-4.35.0-20250909 Tagged selenium/standalone-edge:131.0.2903.147-edgedriver-131.0.2903.147-grid-4.35.0-20250909 Tagged selenium/node-edge:131.0.2903.147-edgedriver-131.0.2903.147-20250909 Tagged selenium/standalone-edge:131.0.2903.147-edgedriver-131.0.2903.147-20250909 Tagged selenium/node-edge:131.0.2903.147-20250909 Tagged selenium/standalone-edge:131.0.2903.147-20250909 Tagged selenium/node-edge:131.0-edgedriver-131.0-grid-4.35.0-20250909 Tagged selenium/standalone-edge:131.0-edgedriver-131.0-grid-4.35.0-20250909 Tagged selenium/node-edge:131.0-edgedriver-131.0-20250909 Tagged selenium/standalone-edge:131.0-edgedriver-131.0-20250909 Tagged selenium/node-edge:131.0-20250909 Tagged selenium/standalone-edge:131.0-20250909

可以看到，镜像命名空间统一为selenium，发布入口脚本的 7 个位置参数分别控制着版本、构建日期、命名空间、是否推送、浏览器类型、是否保留旧版本别名标签以及目标平台，其完整定义可参见 tag_and_push_browser_images.sh。该脚本是理解这套标签体系的关键，下文第三节将逐段拆解。

二、镜像标签命名规范：每一段都代表什么

2.1 官方标签结构

docs/docker-hub/node-edge.md 明确给出了node-edge镜像的两种标签基础结构：

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

即：标签 = 浏览器版本（可带驱动信息）- Selenium Grid 主版本 - 构建日期，构建日期使用YYYYMMDD格式（如20250909）。

2.2 6 组核心标签的语义映射

对照上面日志中的 12 行输出，可以归纳出本次发布为每个镜像生成的 6 组核心标签：

其中"短版本"只取主版本号的前两段（如131.0），用于快速锁定主版本线。需要说明的是，这份归档日志只收录了上述 6 组核心标签；从脚本源码看，当第 6 个参数RELEASE_OLD_VERSION为false时，脚本还会额外追加 4 个不带构建日期的别名标签（131.0.2903.147-edgedriver-131.0.2903.147、131.0.2903.147、131.0-edgedriver-131.0、131.0），用于指向同一发布（详见 tag_and_push_browser_images.sh 与 docs/docker-hub/node-edge.md 中的排列组合说明）。

2.3 为什么需要这么多标签

归档在 CHANGELOG/archived/4.35.0/ 目录下的 README.md 说明 给出了动机：项目希望在持续提供最新 Selenium Grid 核心版本的同时，让用户能够针对特定浏览器版本做"锁定"，例如做跨浏览器测试，或因某个浏览器版本存在兼容性问题而固定版本。用户只需找到对应标签、拉取镜像即可开始测试，无需关心镜像内部如何组合 Grid 与驱动。

三、标签生成脚本源码解析：版本如何被探测与打标

3.1 版本探测：以容器内命令输出为准

tag_and_push_browser_images.sh 中edge分支的版本探测逻辑是：

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

即：以构建出的node-edge:<Grid版本-构建日期>镜像为唯一事实来源，在容器内执行microsoft-edge --version与msedgedriver --version提取真实版本号，再经short_version()函数（tag_and_push_browser_images.sh）按.分割取前两段得到短版本。这与 generate_release_notes.sh 生成发布说明时使用的探测方式完全一致，保证打标与实际内容一致。

3.2 打标签与推送：retag() 与 PROMOTE_TAGS

retag()函数（tag_and_push_browser_images.sh）负责执行docker tag，当PUSH_IMAGE=true（即调用命令中的第 4 个参数true）时追加docker push。此外它还支持PROMOTE_TAGS=true的"发布提升"模式：此时不经过本地镜像，而是直接用docker buildx imagetools create在 registry 之间复制 manifest，从而保留测试过的多架构镜像摘要，避免docker pull只能拉取单架构的问题。

3.3 Makefile 集成

该脚本通过 Makefile 的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 镜像本身的构建目标edge依赖node_base与edge_only，后者在 Makefile 中对PLATFORMS做了严格校验——Microsoft Edge 仅支持 linux/amd64，其他平台直接跳过构建。这一点同样体现在 generate_release_notes.sh 的发布说明表中（Edge 与 EdgeDriver 的 arm64 列为x）。

四、镜像内部：NodeEdge Dockerfile 如何组装 Edge 131

理解了标签之后，再来看看node-edge镜像内部到底装了什么。核心文件是 NodeEdge/Dockerfile。

4.1 Edge 浏览器的安装与版本回退机制

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

• EDGE_VERSION，默认microsoft-edge-stable，可指定其他渠道（如microsoft-edge-beta）；
• EDGE_ARCHIVE_SITE，指向按版本归档的下载源。

安装时先导入微软 GPG 密钥并配置packages.microsoft.com/repos/edge软件源；若EDGE_VERSION形如microsoft-edge-stable=版本号，则从归档站点拉取对应.deb并以--allow-downgrades降级安装——这是因为微软会从官方源清理旧版本，归档源恰好解决了历史版本的可获取性问题。

4.2 EdgeDriver 的版本解析与多级回退

EDGE_DRIVER_VERSION参数的解析逻辑（NodeEdge/Dockerfile）是理解"为什么标签中 Edge 与 EdgeDriver 版本始终一致"的关键：

1. 若未显式指定，则从microsoft-edge --version提取主版本号，请求https://msedgedriver.microsoft.com/LATEST_RELEASE_<主版本>_LINUX获取最新驱动版本；
2. 若该接口返回为空（历史版本常被微软清理），则直接回退使用浏览器自身完整版本号131.0.2903.147；
3. 下载edgedriver_linux64.zip（arm64 时为edgedriver_linux-aarch64.zip），失败时回退到EDGE_ARCHIVE_SITE归档源；
4. 解压到/opt/selenium，按版本号命名并软链到/usr/bin/msedgedriver。

这也解释了日志中Edge version -> 131.0.2903.147与EdgeDriver version -> 131.0.2903.147完全一致的来源——历史版本场景下驱动版本即浏览器版本。

4.3 启动包装器与浏览器信息上报

• NodeEdge/wrap_edge_binary 会将/usr/bin/microsoft-edge替换为包装脚本：设置umask 002、支持--lang参数映射为LANGUAGE环境变量、收集所有SE_BROWSER_ARGS_前缀的环境变量追加到启动参数，并始终以--no-sandbox启动，以适配容器内以非 root 用户（SEL_UID）运行的环境。
• 构建阶段还会向/opt/selenium/browsers/edge/写入浏览器元数据：名称MicrosoftEdge、版本号，以及包含ms:edgeOptions.binary的二进制路径 JSON（默认/usr/bin/microsoft-edge，可通过SE_BROWSER_BINARY_LOCATION覆盖），供 Selenium Grid 节点注册时自动发现（NodeEdge/Dockerfile）。
• 镜像默认启用SE_OTEL_SERVICE_NAME="selenium-node-edge"与SE_NODE_ENABLE_MANAGED_DOWNLOADS="true"两个环境变量（NodeEdge/Dockerfile）。

4.4 残留进程与临时文件清理

为保证长时间运行的节点不被堆积的 Edge 进程拖垮，镜像内置了由 supervisord 托管的清理守护进程 edge-cleanup.conf（受SE_ENABLE_BROWSER_LEFTOVERS_CLEANUP开关控制），其实现 edge-cleanup.sh 按循环执行两项任务：

• 清理运行超过SE_BROWSER_LEFTOVERS_PROCESSES_SECS秒的msedge残留进程（kill -9）；
• 删除/tmp下超过SE_BROWSER_LEFTOVERS_TEMPFILES_DAYS天的.com.microsoft.Edge.*临时目录；

两个清理动作之间间隔SE_BROWSER_LEFTOVERS_INTERVAL_SECS秒。这三个环境变量均可通过-e按需调整。

五、实战：如何拉取并使用这批镜像

5.1 按需拉取

根据日志，本发布可用的镜像与典型标签组合如下：

# 信息最全的标签 docker pull selenium/node-edge:131.0.2903.147-edgedriver-131.0.2903.147-grid-4.35.0-20250909 docker pull selenium/standalone-edge:131.0.2903.147-edgedriver-131.0.2903.147-grid-4.35.0-20250909 # 主版本线标签 docker pull selenium/node-edge:131.0-20250909 docker pull selenium/standalone-edge:131.0-20250909

5.2 以 Hub + Node 方式运行

参考 docs/docker-hub/node-edge.md 的标准流程，Hub 与 Node 在同一自定义网络内通过容器名互相发现：

# 1. 创建网络 docker network create grid # 2. 启动 Hub（暴露 4442-4444 端口） docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:latest # 3. 启动 Edge 节点 docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-edge:131.0-20250909

Windows PowerShell 下使用反引号续行即可。测试代码只需指向http://localhost:4444。两点提醒：

• 凡包含浏览器的镜像，务必使用--shm-size=2g以使用宿主机共享内存；
• 示例中的latest仅为演示，生产场景应使用像131.0-20250909这样锁定具体浏览器与 Grid 版本的完整标签。

如需要，可访问http://localhost:7900/?autoconnect=1&resize=scale&password=secret通过 noVNC 观察容器内的浏览器画面。使用结束后可用docker network rm grid清理网络。

若希望直接以单机形态运行，可使用standalone-edge镜像，它会将完整的 Selenium Grid（含 Router、Distributor 等组件）与 Edge 打包在同一个容器中，通过docker run -p 4444:4444 --shm-size=2g selenium/standalone-edge:131.0-20250909即可对外提供测试端点。

六、变更记录矩阵：如何定位历史版本

edge_131.md并非孤立文件，它是整个版本矩阵的一格。仓库根目录的 CHANGELOG/README.md 以"Grid 版本 × 浏览器版本"矩阵的形式列出每个可用镜像组合，每个 ✓ 都链接到对应 Grid 版本目录下的详细变更记录（如 archived/4.35.0/edge_131.md）。该 README 由 CHANGELOG/generate-matrix-readme.py 自动生成：脚本扫描当前与archived目录下的所有版本目录，按浏览器_版本号.md命名规则提取组合并渲染矩阵，同时负责将旧版本目录移入archived/（generate-matrix-readme.py）。

以 Edge 为例，最新版本 4.48.0 的对应记录为 CHANGELOG/4.48.0/edge_152.md，其格式与本篇分析的 4.35.0 记录完全一致。因此，无论你锁定的是 Edge 131（4.35.0 时代）还是更新版本，都可以通过矩阵快速跳转到对应 changelog，从中提取该发布对应的全部可用镜像标签。需要留意的是，CHANGELOG/README.md 的说明指出：项目并未对"每个 Grid 与浏览器版本的组合"都做完整回归测试，用户在挑选组合时仍应结合自身测试需求自行评估。

结语

一份看似只有打标签日志的 changelog，实际上串联起了 docker-selenium 发布体系中的完整链路：从 tag_and_push_browser_images.sh 的版本探测与打标，到 NodeEdge/Dockerfile 中 Edge 与 EdgeDriver 的版本解析、包装器与清理守护进程，再到 CHANGELOG/generate-matrix-readme.py 驱动的版本矩阵归档。掌握这套标签命名体系后，你不仅能在任意版本组合中准确拉取镜像，也能在浏览器版本升级或回退时快速判断哪个标签指向哪一次发布。

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