企业官网建设流程全解析

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

本篇技术指南以仓库 CHANGELOG/archived/4.30.0/edge_117.md 记录的一次 Edge 镜像打标签作业为线索，结合仓库内的发布脚本、Dockerfile 与官方文档，完整拆解 docker-selenium 如何在每次 Grid 发布时，为 Edge 浏览器生成一整套语义化镜像标签。读完本文，你将能读懂任意一次浏览器镜像发布日志、理解 12 个标签的命名规则与取舍逻辑，并能直接使用固定版本标签部署 Edge 测试节点。

这份 Changelog 记录了什么：一次 Edge 镜像打标签作业的完整输出

该文档并非普通的功能变更说明，而是一份真实的发布执行日志——它记录了 2025 年 3 月 23 日（构建日期20250323）为 Selenium Grid4.30.0发布 Edge 浏览器镜像时，打标签脚本产生的全部输出：

./tag_and_push_browser_images.sh 4.30.0 20250323 selenium false edge true Tagging images for browser edge, version 4.30.0, build date 20250323, namespace selenium Selenium Grid version -> 4.30.0-20250323 Edge version -> 117.0.2045.55 Short Edge version -> 117.0 EdgeDriver version -> 117.0.2045.55 Short EdgeDriver version -> 117.0

日志揭示了这次发布的四个关键版本信息：

其中 "Short" 版本由脚本的short_version()函数从完整版本号中截取前两段得到，用于生成易记忆的短标签。值得注意，Edge 117 与 EdgeDriver 117 恰好完全同版，这源于微软官方对 Chromium 系浏览器"浏览器与 Driver 逐版本对齐"的发布策略。

标签命名约定：读懂 6 + 6 个镜像标签

日志中共出现 12 个Tagged行，分别作用于selenium/node-edge（网格节点镜像）与selenium/standalone-edge（独立模式镜像），每个镜像各 6 个标签：

这套约定与仓库文档 docs/docker-hub/node-edge.md 描述的标签结构完全一致：形如selenium/node-edge-<BrowserVersion>-<browserDriver>-<DriverVersion>-<Major>.<Minor>.<Patch>-<YYYYMMDD>，以及其全部排列组合。其设计意图是：用户既可以用"浏览器版本 + 构建日期"锁定某个确切构建，也可以用117.0-20250323这样的短标签快速引用同一天发布的最新补丁。

为什么这次只打了 6 个标签，而不是 10 个？

阅读脚本 tag_and_push_browser_images.sh 的 edge 分支可以发现，标签数组EDGE_TAGS实际定义了两组：

• 基础 6 个标签（永远生成）：即上表列出的 6 个，全部带构建日期，能精确锁定"某一天发布的确切内容"；
• 4 个"旧版标签"（仅当RELEASE_OLD_VERSION=false时追加）：即不带构建日期的117.0.2045.55-edgedriver-117.0.2045.55、117.0.2045.55、117.0-edgedriver-117.0、117.0。

本次日志中命令的第六个参数为true（对应RELEASE_OLD_VERSION），因此脚本跳过了这 4 个标签，只产生 6 × 2 = 12 个Tagged行。这正是发布历史版本的刻意取舍：避免不带日期、可"漂移"的短标签覆盖到旧版本镜像上，确保117.0这类标签始终只指向最新的发布。

脚本内部：tag_and_push_browser_images.sh 如何生成这些标签

日志中的每一条输出都能在 tag_and_push_browser_images.sh 中找到对应实现。该脚本按浏览器分支（chrome / chromium / edge / firefox / chrome-for-testing）工作，edge 分支的核心流程如下：

参数约定

版本探测：在容器内执行浏览器二进制

脚本并不读取文件，而是直接以TAG_VERSION（即4.30.0-20250323）运行已构建好的 node-edge 容器，从标准输出解析版本号：

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

这正是日志中Edge version -> 117.0.2045.55与EdgeDriver version -> 117.0.2045.55两行的来源：先构建镜像，再从镜像内部实际产出版本号，从而保证标签与镜像内容严格一致，杜绝手写版本号导致的错标。

打标签与推送：retag 函数

function retag() { docker tag "${NAMESPACE}/${__image}:${TAG_VERSION}" "${NAMESPACE}/${__image}:${__tag}" echo "Tagged ${NAMESPACE}/${__image}:${__tag}" if [ "${PUSH_IMAGE}" = true ]; then docker push "${NAMESPACE}/${__image}:${__tag}" fi }

edge 分支末尾对所有EDGE_TAGS逐一执行retag node-edge与retag standalone-edge，形成日志中 node 与 standalone 交替出现的 12 行输出。若PUSH_IMAGE为 true 则随后推送；同时，当PROMOTE_TAGS=true（发布流水线采用"测试镜像晋升发布"模式时）会改用docker buildx imagetools create在 registry 之间直接复制 manifest，以保持多架构索引完整。

Makefile 中的调用链

该脚本由 Makefile 的tag_and_push_edge_images目标触发：

./tag_and_push_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) edge $(RELEASE_OLD_VERSION)

而VERSION、BUILD_DATE等变量默认值（如VERSION := 4.49.0、BUILD_DATE := $(shell date '+%Y%m%d')）同样定义在 Makefile 顶部。此外tag_and_push_browser_images_ghcr目标还会遍历本地全部 edge 标签，用docker buildx imagetools create将同一 manifest 镜像到 GHCR，实现 Docker Hub 与 GHCR 的双注册表发布。

Edge 镜像如何构建：从 Dockerfile 看 117.0.2045.55 的由来

日志中的版本号不是凭空出现的，NodeEdge/Dockerfile 展示了版本固定的底层实现：

• 浏览器安装：默认安装microsoft-edge-stable，也可通过EDGE_VERSION指定如microsoft-edge-beta。由于微软会从官方仓库清理旧版本，脚本对指定版本（形如microsoft-edge-stable=117.0.2045.55-1）从EDGE_ARCHIVE_SITE（NDViet/microsoft-edge-stable的 GitHub Releases 归档）下载对应.deb安装，最新版才走 apt 仓库；
• Driver 安装：EDGE_DRIVER_VERSION为空时，先查询微软的LATEST_RELEASE_<major>_LINUX指针（https://msedgedriver.microsoft.com/LATEST_RELEASE_117_LINUX），失败则回退到与浏览器完全一致的版本号，再下载edgedriver_linux64.zip并软链到/usr/bin/msedgedriver；
• 平台限制：FROM --platform=linux/amd64明确声明 Edge 镜像仅支持linux/amd64；Makefile 的edge_only目标也会先校验PLATFORMS是否包含linux/amd64，否则直接跳过构建。因此日志中的 12 个标签均为 amd64 单架构镜像；
• 浏览器信息注入：构建末尾将MicrosoftEdge、版本号与二进制路径写入/opt/selenium/browsers/edge/，供 Selenium Grid 生成 Node 的 stereotype 能力；其中binary_location指向${SE_BROWSER_BINARY_LOCATION:-/usr/bin/microsoft-edge}，允许运行时通过环境变量覆盖浏览器二进制位置。

此外 NodeEdge/wrap_edge_binary 为/usr/bin/microsoft-edge生成了一层包装脚本：设置umask 002、处理--lang参数、合并所有SE_BROWSER_ARGS_*前缀环境变量，并以--no-sandbox启动浏览器，以满足容器内以非 root 用户（SEL_UID）运行的约束。

如何拉取并使用这些固定版本标签

日志中的标签可以直接用于部署。以本次发布的node-edge为例，拉取与 Grid 1.0 式（Hub + Node）部署方式如下：

docker network create grid # 启动 Hub（端口 4442-4444） docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:4.30.0-20250323 # 启动 Edge 节点（务必使用 --shm-size 共享宿主机内存） docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-edge:117.0-edgedriver-117.0-grid-4.30.0-20250323

• 想让 WebDriver 测试连接到 Grid，将测试指向http://localhost:4444即可；
• 日志中 12 个标签的完整形态同样适用于selenium/standalone-edge:117.0.2045.55-20250323等独立模式镜像，可直接单容器运行整套 Grid；
• 若使用 docker-compose-v3.yml 一类的编排文件，把其中selenium/node-edge:latest替换为上述任一固定标签，即可将整个集群锁定到 Edge 117 与 Grid 4.30.0 的组合；
• 运行完清理网络：docker network rm grid。

更完整的标签组合示例（含<Major>、<Major>.<Minor>等无日期标签）可参见 docs/docker-hub/node-edge.md。官方建议：生产环境优先使用"浏览器版本 + 构建日期"的完整标签来锁定具体构建。

相关环境变量与节点清理机制

固定版本标签之外，Edge 节点镜像还暴露了若干与浏览器生命周期相关的运行时配置（默认值见 ENV_VARIABLES.md）：

清理守护进程由 NodeEdge/edge-cleanup.conf 注册到 supervisord（priority=20），实际逻辑在 NodeEdge/edge-cleanup.sh：先kill -9超龄的 msedge 进程，等待 5 秒后删除临时文件，再休眠一个间隔周期循环执行。这对长时间运行、大量会话反复创建销毁的测试集群非常实用——避免僵尸进程与磁盘碎片累积导致节点劣化。

如何继续查阅完整发布历史

本次日志是 4.30.0 版本归档记录的一部分。仓库的 CHANGELOG 目录按版本组织浏览器发布档案，其中archived/4.30.0/下还有同期的edge_114.md至edge_136.md以及 Chrome、Firefox 对应档案，格式与本文件一致；CHANGELOG/4.48.0/则存放当前维护期的同类记录。需要横向对比不同浏览器、不同版本的标签差异，或复现某次历史发布时，这些档案与根目录的 tag_and_push_browser_images.sh 是相互印证的完整证据链。

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