docker-selenium 浏览器镜像 Tag 发布记录解读：以 Chrome 128 为例的标签命名规范与发布脚本全解析-平芜编程栈

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

【免费下载链接】docker-selenium

Provides a simple way to run Selenium Grid with Chrome, Firefox, and Edge using Container Platform, making it easier to perform browser automation at scale

项目地址：https://gitcode.com/GitHub_Trending/do/docker-selenium

点击查看免费下载

本文围绕 CHANGELOG/archived/4.28.1/chrome_128.md 这份发布记录展开，它完整记录了 docker-selenium 项目在 Selenium Grid 4.28.1 版本中为 Chrome 128.0.6613.137 镜像生成并打上全部标签的过程。通过对照根目录下的 tag_and_push_browser_images.sh 发布脚本源码，读者可以彻底理解：一套标签的命名构成规则、脚本参数的含义与默认值、短版本号的计算逻辑，以及如何在 CI（Makefile）中触发这套发布流程，最终在自己的测试环境中精准选择、拉取并验证对应版本的 Chrome 节点镜像。

发布记录里发生了什么

chrome_128.md是一份由发布脚本直接生成的执行日志，记录了为 Chrome 128 镜像打标签并推送（push）的完整过程。日志开头的命令说明了本次发布的核心参数：

./tag_and_push_browser_images.sh 4.28.1 20250202 selenium false chrome true

随后脚本依次输出了本次发布涉及的关键版本信息：

Selenium Grid 版本：4.28.1-20250202（Grid 版本号与构建日期的组合，即脚本中的TAG_VERSION）
Chrome 版本：128.0.6613.137
Short Chrome 版本（短版本）：128.0
ChromeDriver 版本：128.0.6613.137
Short ChromeDriver 版本（短版本）：128.0

这里可以看到一个值得注意的事实：Chrome 与 ChromeDriver 在该次发布中版本号完全一致（128.0.6613.137），这正是 Chrome for Testing（CfT）模式出现后 Chrome 与驱动版本严格对齐的典型表现。

12 个标签的完整清单与命名拆解

发布脚本为node-chrome与standalone-chrome两个镜像各打上了 6 个标签，合计 12 个。原始记录如下：

Tagged selenium/node-chrome:128.0.6613.137-chromedriver-128.0.6613.137-grid-4.28.1-20250202 Tagged selenium/standalone-chrome:128.0.6613.137-chromedriver-128.0.6613.137-grid-4.28.1-20250202 Tagged selenium/node-chrome:128.0.6613.137-chromedriver-128.0.6613.137-20250202 Tagged selenium/standalone-chrome:128.0.6613.137-chromedriver-128.0.6613.137-20250202 Tagged selenium/node-chrome:128.0.6613.137-20250202 Tagged selenium/standalone-chrome:128.0.6613.137-20250202 Tagged selenium/node-chrome:128.0-chromedriver-128.0-grid-4.28.1-20250202 Tagged selenium/standalone-chrome:128.0-chromedriver-128.0-grid-4.28.1-20250202 Tagged selenium/node-chrome:128.0-chromedriver-128.0-20250202 Tagged selenium/standalone-chrome:128.0-chromedriver-128.0-20250202 Tagged selenium/node-chrome:128.0-20250202 Tagged selenium/standalone-chrome:128.0-20250202

逐项拆解这 6 种标签后缀，其语义分别是：

标签后缀示例	语义
`128.0.6613.137-chromedriver-128.0.6613.137-grid-4.28.1-20250202`	完整浏览器版本 + 完整驱动版本 + 完整 Grid 版本 + 构建日期
`128.0.6613.137-chromedriver-128.0.6613.137-20250202`	完整浏览器版本 + 完整驱动版本 + 构建日期
`128.0.6613.137-20250202`	完整浏览器版本 + 构建日期
`128.0-chromedriver-128.0-grid-4.28.1-20250202`	短浏览器版本 + 短驱动版本 + 完整 Grid 版本 + 构建日期
`128.0-chromedriver-128.0-20250202`	短浏览器版本 + 短驱动版本 + 构建日期
`128.0-20250202`	短浏览器版本 + 构建日期

每一类标签都同时打在node-chrome和standalone-chrome两个镜像上，因为浏览器节点（Node）与独立（Standalone）形态共享同一套浏览器与驱动的组合，区别只在于前者需配合 Hub 组成 Grid，后者自带 Grid 服务。

这套标签命名结构在 docs/docker-hub/node-chrome.md 中有官方化的描述，其通用模板为：

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

以及简化形态：

selenium/node-chrome-<Major>.<Minor>.<Patch>-<YYYYMMDD>

标签从何而来：脚本源码中的生成逻辑

这 12 个标签并不是手工拼写的，而是 tag_and_push_browser_images.sh 在chrome分支中自动生成的。脚本首先通过docker run临时启动刚刚构建好的node-chrome:4.28.1-20250202镜像，从容器内部探测真实的浏览器与驱动版本：

CHROME_VERSION=$(docker run --platform ${PLATFORM} --rm ${NAMESPACE}/node-chrome:${TAG_VERSION} google-chrome --version | awk '{print $3}') CHROMEDRIVER_VERSION=$(docker run --platform ${PLATFORM} --rm ${NAMESPACE}/node-chrome:${TAG_VERSION} chromedriver --version | awk '{print $2}')

这两条命令分别从容器内的google-chrome --version与chromedriver --version输出中提取版本字段，保证标签与镜像内实际安装的二进制版本严格一致，而不是依赖构建参数中声明的版本号。随后脚本根据浏览器/驱动版本构造标签数组（见 tag_and_push_browser_images.sh），并循环调用retag函数为node-chrome与standalone-chrome同时打标签：

for chrome_tag in "${CHROME_TAGS[@]}"; do retag node-chrome "${chrome_tag}" retag standalone-chrome "${chrome_tag}" done

从源码结构看，脚本的其他分支（chromium、edge、firefox、chrome-for-testing）遵循完全相同的模式，只是探测命令与驱动名不同，例如 Edge 用microsoft-edge --version/msedgedriver --version，Firefox 用firefox --version/geckodriver --version。

短版本号的由来：short_version 函数

日志中 Chrome 与 ChromeDriver 都输出了"Short 版本"128.0，这一简化版本由脚本中的short_version()函数计算得出（见 tag_and_push_browser_images.sh）：

function short_version() { local __long_version=$1 local __version_split=(${__long_version//./ }) echo "${__version_split[0]}.${__version_split[1]}" }

其逻辑是把完整版本号按.拆分成数组，只取前两个数字（主版本与次版本）拼接。128.0.6613.137因此得到128.0。短版本标签的价值在于：它提供了一个不随补丁版本变化的稳定入口，当 Chrome 从128.0.6613.137升级到128.0.6613.140这类同主次版本的补丁发布时，selenium/node-chrome:128.0-20250202这类标签无需改写即可滚动指向新的构建，方便团队在测试配置中维持一个较长周期的稳定引用。

脚本的七个参数与默认行为

发布日志开头的命令是理解整个记录的关键，其参数映射如下（对应 tag_and_push_browser_images.sh 的位置参数解析）：

位置	命令中的值	参数	含义
$1	`4.28.1`	VERSION	Selenium Grid 版本号
$2	`20250202`	BUILD_DATE	镜像构建日期（YYYYMMDD）
$3	`selenium`	NAMESPACE	Docker Hub 命名空间
$4	`false`	PUSH_IMAGE	是否在打标签后执行`docker push`，默认`false`
$5	`chrome`	BROWSER	目标浏览器（chrome / chromium / edge / firefox / chrome-for-testing）
$6	`true`	RELEASE_OLD_VERSION	是否为旧版本补发标签，默认`false`
$7	（未传）	PLATFORM	探测版本时使用的平台，默认`linux/amd64`

其中RELEASE_OLD_VERSION参数直接决定了本日志中标签清单的长度。看脚本源码，当该值为false（即常规发布）时，标签数组会额外追加 4 个不带构建日期的"纯版本"标签（见 tag_and_push_browser_images.sh）：

${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION} ${CHROME_VERSION} ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION} ${CHROME_SHORT_VERSION}

而本次记录中RELEASE_OLD_VERSION=true，意味着这是一次对已归档旧版本的补发/补标操作，因此不带构建日期的通用标签被跳过（避免覆盖当前仍在滚动更新的latest语义标签），只保留了带构建日期的 6 个标签，这正是日志中恰好出现 12 条 Tagged 输出的原因。

retag 与推送：打标签与推送的实际动作

日志中每条Tagged输出都来自retag()函数（见 tag_and_push_browser_images.sh）。默认路径下它的核心动作是：

docker tag "${__source}" "${NAMESPACE}/${__image}:${__tag}" echo "Tagged ${NAMESPACE}/${__image}:${__tag}" if [ "${PUSH_IMAGE}" = true ]; then docker push "${NAMESPACE}/${__image}:${__tag}" fi

即先基于已构建的selenium/node-chrome:4.28.1-20250202源镜像执行docker tag生成别名标签，再根据PUSH_IMAGE决定是否执行docker push推送。本记录中PUSH_IMAGE=false，所以日志只停留在Tagged阶段——这也解释了记录里没有出现 push 相关输出。

源码中还保留了PROMOTE_TAGS与PROMOTE_GHCR_NAMESPACE两个环境变量分支（由发布工作流deploy.yml设置）：当发布直接复用已测试通过的镜像而非重新构建时，retag()会改用docker buildx imagetools create在 registry 之间复制 manifest index，从而保住多架构镜像特性，并可同步镜像到 GHCR 命名空间。这属于从源码注释与分支结构可以推断的发布机制细节，普通手工发布并不涉及。

在 Makefile 与 CI 中的触发方式

这套打标签流程在项目中由 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_chrome_images: ./tag_and_push_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) chrome $(RELEASE_OLD_VERSION)

其中$(VERSION)、$(BUILD_DATE)、$(NAMESPACE)、$(PUSH_IMAGE)、$(RELEASE_OLD_VERSION)均由 Makefile 变量注入，Makefile的.PHONY列表中也将tag_and_push_browser_images声明为伪目标。tag_and_push_browser_images_ghcr目标则对应上文提到的 GHCR 镜像镜像流程：通过docker images枚举本地标签后，逐一用docker buildx imagetools create打到$(GHCR_NAMESPACE)命名空间下。

发布记录的来源与版本矩阵定位

本记录存放于 CHANGELOG/README.md 定义的"浏览器版本矩阵"体系中。该 README 明确指出矩阵的目的：在持续供给最新 Selenium Grid 核心版本的同时，允许用户固定（pin）某个浏览器版本进行跨浏览器测试，或规避特定浏览器版本的已知问题。矩阵表格中，4.28.1行的 Chrome 128 列即链接到本文分析的chrome_128.md；同目录下的chrome_127.md、chrome_126.md等文件结构与本文完全一致，只是浏览器版本号不同。

同时矩阵 README 也给出了重要免责声明：项目并未对"每个 Grid 版本 × 浏览器版本"的组合都做全量测试，用户需要依据自身测试需求自行评估组合可用性。

如何用这套标签拉取并验证镜像

理解了标签命名后，实际使用就非常直观。例如在 README.md 描述的 Hub + Node 模式下固定 Chrome 128 与 Grid 4.28.1：

docker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:4.28.1-20250202 docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-chrome:128.0.6613.137-chromedriver-128.0.6613.137-grid-4.28.1-20250202

若希望团队配置在补丁升级时保持稳定，可选用短版本标签，例如selenium/node-chrome:128.0-20250202。拉取后可通过与发布脚本相同的方式核对镜像内真实版本：

docker run --rm selenium/node-chrome:128.0-20250202 google-chrome --version docker run --rm selenium/node-chrome:128.0-20250202 chromedriver --version

对照 CHANGELOG/archived/4.28.1/chrome_128.md 中的128.0.6613.137，即可验证镜像内容与发布记录一致。README 同时提醒：运行含浏览器的镜像务必携带--shm-size="2g"使用宿主机共享内存，避免 Chrome 在容器内因/dev/shm过小而崩溃。

版本来源的底层支撑：NodeChrome 镜像构建

标签中的版本号最终来源于 NodeChrome/Dockerfile 构建的镜像本身。该 Dockerfile 通过ARG CHROME_VERSION="google-chrome-stable"指定 Chrome 安装通道（stable/beta/unstable），并依次执行 NodeChrome/install-chrome.sh、NodeChrome/install-chromedriver.sh 完成浏览器与驱动的安装；构建末尾还会把google-chrome --version解析出的版本写入/opt/selenium/browsers/chrome/version供 Grid 节点上报能力。install-chromedriver.sh中针对 Chrome 128 这类 115 以后的版本走 Chrome for Testing（CfT）下载源，amd64 架构从chrome-for-testing-public存储桶获取与 Chrome 同版本号的驱动，这也是日志中两者版本号一致的根本原因。

小结

chrome_128.md虽是一份简短的脚本输出，但它是理解 docker-selenium 镜像发布与标签体系的理想样本：一次命令、两次版本探测、12 个标签，背后是脚本中参数化、短版本化、按RELEASE_OLD_VERSION裁剪标签数组、retag统一执行打标/推送的一套成熟设计。结合 tag_and_push_browser_images.sh 与 CHANGELOG/README.md 的版本矩阵，测试团队既可以把它当作排查镜像内容、核对版本组合的审计档案，也可以复用其命名规律，为自有测试基础设施设计可预测、可滚动的镜像标签策略。

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

【免费下载链接】docker-selenium

Provides a simple way to run Selenium Grid with Chrome, Firefox, and Edge using Container Platform, making it easier to perform browser automation at scale

项目地址：https://gitcode.com/GitHub_Trending/do/docker-selenium

点击查看免费下载