企业官网建设流程全解析

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

本篇技术指南围绕 docker-selenium 仓库中的镜像发布记录CHANGELOG/archived/4.32.0/chrome_105.md展开，完整剖析其背后的自动化脚本 tag_and_push_browser_images.sh 如何为一个浏览器版本批量生成并打上十余个语义化 Docker 标签。读者读完本文后，将理解 docker-selenium 版本矩阵的生成原理、Chrome 与 ChromeDriver 版本的自动探测方式、标签命名约定的每种组合含义，以及如何根据这些标签精确拉取自己所需的 Selenium Grid 镜像。

一次发布记录里藏着什么

关联文档 CHANGELOG/archived/4.32.0/chrome_105.md 的全文是tag_and_push_browser_images.sh的一次真实执行输出。表面上看它只是一段命令日志，实际上它完整记录了 docker-selenium 项目发布某个浏览器版本时的全部动作：调用脚本、传入参数、探测浏览器版本、计算短版本号、为node-chrome与standalone-chrome两个镜像各打上 10 个标签。还原这次发布的关键信息如下：

./tag_and_push_browser_images.sh 4.32.0 20250515 selenium false chrome true

对应版本组合：

脚本参数：一条命令如何驱动整个发布流程

从 tag_and_push_browser_images.sh 的源码可以看到，脚本共支持 7 个位置参数：

VERSION=$1 # Grid 主版本，如 4.32.0 BUILD_DATE=$2 # 构建日期，如 20250515 NAMESPACE=$3 # 镜像命名空间，如 selenium PUSH_IMAGE="${4:-false}" # 是否推送镜像到仓库，默认 false BROWSER=$5 # 浏览器类型：chrome / chromium / edge / firefox / chrome-for-testing RELEASE_OLD_VERSION="${6:-false}" # 是否为旧版本补打标签，默认 false PLATFORM="${7:-linux/amd64}" # 探测版本时使用的平台，默认 linux/amd64

其中两个关键行为值得注意：

• PUSH_IMAGE控制是否调用docker push。记录中的调用传入了false（第 4 个参数），因此只执行本地docker tag不打推送，适合作为发布前的验证步骤。
• RELEASE_OLD_VERSION决定是否补打"仅含浏览器版本"的标签（如105.0.5195.125、105.0）。结合 Makefile 中的发布流程可以推断，新版本发布时该参数为false，会打全 10 个标签；而为旧浏览器版本补发标签时设为true，只打 6 个含 Grid 版本或日期的标签，避免覆盖当前浏览器主版本对应的"最新"标签。

脚本开头的TAG_VERSION=${VERSION}-${BUILD_DATE}将 Grid 版本与构建日期拼接为形如4.32.0-20250515的基础版本串，后续所有标签都以此为根。

版本自动探测：从镜像里读出真实版本号

脚本不会硬编码版本号，而是通过临时运行已经构建好的 Node 镜像来探测浏览器与驱动版本（tag_and_push_browser_images.sh）：

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

docker run --rm临时拉起node-chrome:4.32.0-20250515，执行google-chrome --version与chromedriver --version，再用awk提取版本号字段。这样既验证了镜像可运行，又保证了标签与镜像内实际二进制版本严格一致，杜绝人工维护版本号造成的漂移。

随后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]}" }

因此105.0.5195.125得到105.0，105.0.5195.52得到105.0。短版本标签的价值在于：当 Chrome 105 发布补丁版本时，短标签105.0无需改动即可指向该系列的最新构建，方便使用者锁定主版本又自动跟进补丁。

十种标签的生成规则

脚本为每个浏览器版本维护一个标签数组（tag_and_push_browser_images.sh），由 Chrome 长/短版本、ChromeDriver 长/短版本、Grid 版本串、构建日期四类信息组合而成：

其中 7～10 仅在RELEASE_OLD_VERSION=false时追加。记录输出中node-chrome与standalone-chrome各出现 10 行Tagged，正是两套镜像分别套用同一标签集合的结果，与脚本尾部retag node-chrome "${chrome_tag}"; retag standalone-chrome "${chrome_tag}"的循环逻辑完全对应（tag_and_push_browser_images.sh）。

底层打标与发布：docker tag 到 buildx imagetools

脚本核心的retag函数（tag_and_push_browser_images.sh）有两条路径：

• 常规路径：docker tag本地打标，若PUSH_IMAGE=true则追加docker push。
• 提升路径（PROMOTE_TAGS=true）：改用docker buildx imagetools create直接在 registry 之间创建清单索引标签。脚本注释解释了原因：docker tag需要镜像在本地，且docker pull只能拉回 runner 单一架构，无法表达多架构清单；而imagetools在 index 层面操作，可从 registry 到 registry 保留多架构属性。这与 Makefile 中 release 阶段的PROMOTE_NAMESPACE提升流程形成配套。

发布阶段的完整链条是：CI 构建出NAMESPACE/镜像:TAG_VERSION（如selenium/node-chrome:4.32.0-20250515）→ 脚本探测版本 → 生成标签数组 → 对 node/standalone 镜像逐一打标 → 可选推送。CHANGELOG 中记录的4.32.0 20250515 selenium false chrome true调用即对应这条链路中的浏览器镜像打标环节。

同构设计：四种浏览器共用一套发布脚本

脚本的case "${BROWSER}"分支（tag_and_push_browser_images.sh）为chrome、chromium、edge、firefox、chrome-for-testing五种浏览器实现了完全对称的逻辑，仅版本探测命令不同：

正因为脚本与浏览器类型解耦，CHANGELOG/README.md 才能生成 Chrome、Chrome for Testing、Edge、Firefox 四个维度、横跨数十个浏览器版本的矩阵表。该矩阵的动机在文档中写得很清楚：在持续提供最新 Selenium Grid 核心版本的同时，让用户能够锁定特定浏览器版本进行跨浏览器测试或规避特定版本的兼容性问题；其"如何阅读"一节说明每个 ✓ 链接指向对应 Grid 版本下的详细 changelog。

镜像内版本从哪来：NodeChrome 构建链路

标签里出现的105.0.5195.125并非凭空产生，而是源于 NodeChrome/Dockerfile 的构建期固化：镜像通过 install-chrome.sh 安装指定版本的google-chrome-stable，通过 install-chromedriver.sh 安装 ChromeDriver，并将版本写入/opt/selenium/browsers/chrome/version（见 NodeChrome/Dockerfile）。docker run ... google-chrome --version之所以能取到准确版本，正是依赖这条"构建期写入、运行期探测"的一致性设计。

实战：根据标签拉取并运行镜像

理解了标签体系之后，实际使用只需按需选择。docs 目录下的镜像说明（如 docs/docker-hub/node-chrome.md、docs/docker-hub/standalone-chrome.md）给出的标签模板为：

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

以本文的 Chrome 105 为例，对应本次发布记录中的两个典型标签：

• selenium/standalone-chrome:105.0.5195.125-20250515：锁定 Chrome 补丁版本与构建日期，适合可复现的 CI 环境；
• selenium/standalone-chrome:105.0-chromedriver-105.0：锁定主版本与驱动主版本，补丁自动跟进，适合日常开发。

Standalone 模式的启动方式（见 docs/docker-hub/standalone-chrome.md）：

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

Node 模式需要先建网络再接 Hub（见 docs/docker-hub/node-chrome.md）：

docker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:latest docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-hub \ --shm-size="2g" \ selenium/node-chrome:105.0.5195.125-20250515

两种模式都必须加--shm-size="2g"使用宿主机共享内存，否则浏览器进程可能因/dev/shm空间不足而崩溃；如需可视化调试，可访问http://localhost:7900/?autoconnect=1&resize=scale&password=secret。

小结

一次看似平凡的发布日志，背后是 docker-selenium 精心设计的版本矩阵工程：以 tag_and_push_browser_images.sh 为引擎，通过镜像内版本探测、短版本推导、多组合标签数组和docker tag/buildx imagetools双路径打标，为每个 Grid 版本和浏览器版本组合生成从"完全锁定"到"滚动跟进"的 10 种标签。当你在 CHANGELOG/README.md 的矩阵中选中某个 ✓ 链接时，看到的正是这样一次完整、可复现、语义清晰的发布过程。

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