企业官网建设流程全解析

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

本篇技术指南以仓库归档变更记录 CHANGELOG/archived/4.33.0/chrome_123.md 为起点，逐行解读一次针对 Chrome 123 的镜像打标运行输出，并结合 tag_and_push_browser_images.sh、Makefile 与 NodeChrome/Dockerfile 等源码，完整还原 docker-selenium 项目"构建后为浏览器镜像生成多形态版本标签"的自动化流程。读完本文，你将掌握浏览器镜像标签命名规范、版本探测原理、RELEASE_OLD_VERSION参数的行为差异，以及如何在自己的测试环境中选用精确版本标签运行 Selenium Grid。

一、发布记录解读：一次打标运行输出了什么

归档变更记录全文如下（位于CHANGELOG/archived/4.33.0/，属于已被归档的 4.33.0 版本记录）：

./tag_and_push_browser_images.sh 4.33.0 20250606 selenium false chrome true Tagging images for browser chrome, version 4.33.0, build date 20250606, namespace selenium Selenium Grid version -> 4.33.0-20250606 Chrome version -> 123.0.6312.122 Short Chrome version -> 123.0 ChromeDriver version -> 123.0.6312.122 Short ChromeDriver version -> 123.0 Tagged selenium/node-chrome:123.0.6312.122-chromedriver-123.0.6312.122-grid-4.33.0-20250606 Tagged selenium/standalone-chrome:123.0.6312.122-chromedriver-123.0.6312.122-grid-4.33.0-20250606 Tagged selenium/node-chrome:123.0.6312.122-chromedriver-123.0.6312.122-20250606 Tagged selenium/standalone-chrome:123.0.6312.122-chromedriver-123.0.6312.122-20250606 Tagged selenium/node-chrome:123.0.6312.122-20250606 Tagged selenium/standalone-chrome:123.0.6312.122-20250606 Tagged selenium/node-chrome:123.0-chromedriver-123.0-grid-4.33.0-20250606 Tagged selenium/standalone-chrome:123.0-chromedriver-123.0-grid-4.33.0-20250606 Tagged selenium/node-chrome:123.0-chromedriver-123.0-20250606 Tagged selenium/standalone-chrome:123.0-chromedriver-123.0-20250606 Tagged selenium/node-chrome:123.0-20250606 Tagged selenium/standalone-chrome:123.0-20250606

这段输出可以拆解为四个层次：

1. 调用参数：脚本被调用时传入 6 个位置参数——4.33.0（Grid 版本）、20250606（构建日期）、selenium（命名空间）、false（是否 push）、chrome（浏览器类型）、true（是否为旧版本补发标签）。
2. 版本探测结果：脚本从已构建的镜像内实际读出 Chrome 与 ChromeDriver 的版本号，并各自派生出x.y形式的短版本号。
3. 标签生成结果：共 6 种标签形态，每种形态同时作用于node-chrome与standalone-chrome两个镜像，因此日志中两种镜像交替出现——这并非偶然，而是脚本按"标签"为外层循环、按"镜像"为内层循环的执行顺序使然。
4. 关键细节：本次运行未生成不带 Grid 版本、不带构建日期的"裸版本标签"（如123.0.6312.122或123.0），原因在第六节结合RELEASE_OLD_VERSION参数说明。

二、脚本入口：位置参数与 Makefile 联动

tag_and_push_browser_images.sh 是本次记录的真正执行者，其位置参数定义见脚本 第 1-13 行：

其中TAG_VERSION由${VERSION}-${BUILD_DATE}拼接而成，即记录中的4.33.0-20250606——这是镜像最初的构建标签（Grid 版本标签），脚本基于它派生出全部浏览器版本标签。

日常使用中通常不需要直接调用脚本，而是通过 Makefile 封装的目标驱动。相关目标集中在 第 779-796 行：

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)

Makefile 顶部的默认值定义（第 2-16 行）为这些变量提供了可覆盖的默认值：BUILD_DATE默认取当前日期$(shell date '+%Y%m%d')、NAMESPACE默认selenium、PUSH_IMAGE默认false、RELEASE_OLD_VERSION默认false。也就是说，一个不带任何覆盖变量的make tag_and_push_chrome_images会以"今天"为构建日期、以selenium为命名空间执行打标。

三、版本探测：在容器内读出真实版本号

打标的前提是拿到镜像内实际安装的浏览器与驱动版本。脚本的chrome分支（第 63-104 行）通过docker run临时启动容器并执行版本命令：

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的输出形如Google Chrome 123.0.6312.122，因此awk '{print $3}'取出第 3 个字段即得到123.0.6312.122；
• chromedriver --version的输出以ChromeDriver 123.0.6312.122 ...开头，取第 2 个字段得到123.0.6312.122。

随后short_version()函数（第 53-57 行）按.分割版本号并只保留前两段：

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

由此得到记录中的Short Chrome version -> 123.0与Short ChromeDriver version -> 123.0。

两个细节值得注意：

• 探测命令带--platform ${PLATFORM}，保证在异构环境下按目标平台读取版本（PLATFORM默认linux/amd64）；
• 版本字段索引与 NodeChrome/Dockerfile 中记录浏览器版本的方式保持一致：常规 Chrome 安装（INSTALL_CFT=false）用google-chrome --version | awk '{print $3}'，而 Chrome for Testing 分支用{print $5}，脚本的chrome与chrome-for-testing两个分支也分别使用$3与$5——两者是一一对应的。

镜像内的 Chrome 与 ChromeDriver 分别由 install-chrome.sh（默认从 Google 官方 apt 源安装google-chrome-stable，也支持指定google-chrome-beta/google-chrome-unstable或精确版本）和 install-chromedriver.sh（自动根据 Chrome 主版本号探测匹配的 ChromeDriver，amd64 从 Chrome for Testing 渠道获取）在构建阶段安装，并在构建结束时分别执行google-chrome --version与chromedriver --version自检。打标脚本的探测因此得到的是"镜像内二进制文件实际报告"的版本，而非构建参数中的期望值，从机制上杜绝了版本漂移。

四、标签命名规范：6 种形态背后的设计逻辑

脚本为node-chrome与standalone-chrome各生成一组标签。本次记录（RELEASE_OLD_VERSION=true）生成了 6 种形态，可以归纳为"长版本/短版本 × 是否携带 Grid 版本"的排列组合：

标签数组在脚本 第 75-87 行 中按此顺序定义，随后以"标签"为外层、以"镜像"为内层执行打标（第 101-104 行）：

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

这正是变更记录中node-chrome与standalone-chrome交替出现的直接原因。

这套命名体系与镜像文档中描述的 tag 结构一致。以 docs/docker-hub/node-chrome.md 的说明为例，通用结构是：

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

并在此基础上派生全部排列组合（短版本、含/不含日期、含/不含 grid 版本）。设计意图可以概括为：标签越长越精确、越适合回归与复现；标签越短越易记、越适合快速取用。例如123.0-20250606用于日常测试，而123.0.6312.122-chromedriver-123.0.6312.122-grid-4.33.0-20250606用于需要把浏览器、驱动、Grid 三者全部钉死的场景。

五、RELEASE_OLD_VERSION：为什么这次只有 6 个标签

变更记录的最后两个参数是chrome true，其中第 6 个参数true对应RELEASE_OLD_VERSION。脚本在 第 88-99 行 对该参数进行判断：

if [ "${RELEASE_OLD_VERSION}" = "false" ]; then CHROME_TAGS+=( # Browser version and browser driver version ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION} # Browser version ${CHROME_VERSION} # Browser version and browser driver version ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION} # Browser version ${CHROME_SHORT_VERSION} ) fi

只有当RELEASE_OLD_VERSION=false（即当前正在发布"新"版本）时，才会追加 4 个不带 Grid 版本、不带构建日期的裸版本标签：123.0.6312.122-chromedriver-123.0.6312.122、123.0.6312.122、123.0-chromedriver-123.0、123.0。

因此，一次完整的新版本发布会产生每镜像 10 个标签（6 + 4），而本次记录是为旧版本（Chrome 123 对应的 4.33.0）补发带日期/Grid 信息的标签，所以只产生了 6 个。这样做的合理性在于：裸版本标签（如selenium/node-chrome:123.0.6312.122）在版本首发时已经存在，旧版本补发时无需也不应覆盖或重复创建，只需补上带构建日期与 Grid 版本的精确标签即可。

六、retag 实现：本地 tag 与 registry 直通两条路径

标签的最终落地由retag()函数完成（第 31-51 行）：

function retag() { local __image=$1 local __tag=$2 local __source="${NAMESPACE}/${__image}:${TAG_VERSION}" if [ "${PROMOTE_TAGS}" = "true" ]; then local __targets=(--tag "${NAMESPACE}/${__image}:${__tag}") if [ -n "${PROMOTE_GHCR_NAMESPACE}" ]; then __targets+=(--tag "${PROMOTE_GHCR_NAMESPACE}/${__image}:${__tag}") fi docker buildx imagetools create "${__targets[@]}" "${__source}" echo "Tagged ${NAMESPACE}/${__image}:${__tag}" return fi docker tag "${__source}" "${NAMESPACE}/${__image}:${__tag}" echo "Tagged ${NAMESPACE}/${__image}:${__tag}" if [ "${PUSH_IMAGE}" = true ]; then docker push "${NAMESPACE}/${__image}:${__tag}" fi }

两条路径的分工是：

• 常规路径（PROMOTE_TAGS未开启）：以docker tag在本地为镜像添加新标签；若调用时第 4 个参数PUSH_IMAGE=true，再对每个新标签执行docker push。
• 发布推广路径（PROMOTE_TAGS=true，由环境变量PROMOTE_TAGS与PROMOTE_GHCR_NAMESPACE控制）：直接使用docker buildx imagetools create在 registry 之间（registry to registry）为 manifest index 创建新标签。脚本头部注释（第 18-30 行）解释了原因：docker tag需要镜像存在于本地，而docker pull只能拉取运行方架构的镜像，会让浏览器标签退化为单架构；imagetools直接操作 index，可完整保留多架构 manifest。若设置了PROMOTE_GHCR_NAMESPACE，还会在同一个调用中把标签同步镜像到 GHCR 命名空间。

此外，Makefile 还提供了 tag_and_push_browser_images_ghcr 与 mirror_browser_images_ghcr 等目标，用于在打标完成后通过docker buildx imagetools create把浏览器标签镜像到$(GHCR_NAMESPACE)（默认ghcr.io/seleniumhq），覆盖 Docker Hub 与 GHCR 双仓库发布场景。

七、实战：用精确标签运行 Chrome 123 节点与独立容器

变更记录生成的标签可以直接用于docker run，以123.0-20250606为例：

Node 模式（Hub + Node，参考 docs/docker-hub/node-chrome.md）：

# 1. 创建网络 docker network create grid # 2. 启动 Hub docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:4.33.0-20250606 # 3. 启动 Node（使用本次记录生成的精确标签） docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-chrome:123.0-20250606

Standalone 模式（参考 docs/docker-hub/standalone-chrome.md）：

docker run -d -p 4444:4444 -p 7900:7900 --shm-size="2g" selenium/standalone-chrome:123.0-20250606

随后将 WebDriver 测试指向http://localhost:4444；如需观察容器内运行情况，可访问http://localhost:7900/?autoconnect=1&resize=scale&password=secret（noVNC，默认密码secret）。

两点使用前提提醒：

• 运行含浏览器的镜像时务必使用--shm-size="2g"挂载宿主共享内存，否则浏览器进程容易因/dev/shm不足而崩溃；
• 生产或回归场景建议优先使用123.0.6312.122-chromedriver-123.0.6312.122-grid-4.33.0-20250606这类全信息标签，把浏览器、驱动与 Grid 三者全部钉死，避免latest类标签带来的隐性升级。

八、总结

CHANGELOG/archived/4.33.0/chrome_123.md 表面上只是一段打标命令的输出，背后却完整承载了 docker-selenium 的浏览器镜像标签体系：tag_and_push_browser_images.sh通过"容器内版本探测 → 短版本派生 → 标签组合 → 循环打标"四步，为node-chrome与standalone-chrome生成从全信息到短版本、从带 Grid 版本到仅带构建日期的多形态标签；RELEASE_OLD_VERSION参数则区分了新版本首发（10 个标签）与旧版本补发（6 个标签）两种场景；retag()的docker tag与docker buildx imagetools create双路径兼顾了本地打标推送与多架构 registry 直通。理解这套流程，既能帮你在使用中准确选择标签、锁定测试环境版本，也能为自维护镜像仓库的版本管理提供可借鉴的设计范式。

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