企业官网建设流程全解析

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

本篇技术指南以 docker-selenium 仓库归档变更日志 CHANGELOG/archived/4.29.0/chrome_104.md 中记录的 Chrome 104 镜像打标日志为核心，拆解其背后由 tag_and_push_browser_images.sh 驱动的标签生成机制。读者读完将掌握：docker-selenium 镜像标签的完整命名约定、如何读懂一份浏览器镜像构建日志、如何根据测试需求精确挑选selenium/node-chrome与selenium/standalone-chrome的历史版本镜像，以及如何复用该脚本生成自定义标签。

一、这份归档日志记录了什么事

CHANGELOG/archived/4.29.0/目录下的每个文件对应一次浏览器镜像发布记录。chrome_104.md的完整内容是一次tag_and_push_browser_images.sh脚本执行的标准输出：

./tag_and_push_browser_images.sh 4.29.0 20250303 selenium false chrome true Tagging images for browser chrome, version 4.29.0, build date 20250303, namespace selenium Selenium Grid version -> 4.29.0-20250303 Chrome version -> 104.0.5112.101 Short Chrome version -> 104.0 ChromeDriver version -> 104.0.5112.79 Short ChromeDriver version -> 104.0

日志表明：发布方在 2025 年 3 月 3 日（构建日期20250303），为 Selenium Grid4.29.0这一代归档版本补发/记录 Chrome104的镜像标签。其中包含三组关键版本事实：

日志末尾的 12 行Tagged ...则展示了脚本为selenium/node-chrome与selenium/standalone-chrome两个镜像各生成的 6 个标签（下文第三节详解）。这份日志之所以归档在4.29.0下，是因为它对应 CHANGELOG/README.md 中“Archived Grid Versions”矩阵里的一个条目：Grid 4.29.0 × Chrome 104，用户可以通过矩阵上的 ✓ 链接逐版本查看这类打标明细。

二、驱动这份日志的脚本：tag_and_push_browser_images.sh

2.1 脚本参数与本次调用的对应关系

tag_and_push_browser_images.sh 是生成浏览器镜像标签的唯一入口，它接收最多 7 个位置参数：

脚本首先拼接出基础镜像标签TAG_VERSION=${VERSION}-${BUILD_DATE}，即4.29.0-20250303（对应日志第 4 行Selenium Grid version -> 4.29.0-20250303）。

2.2 浏览器版本信息的动态探测

与人工填写版本号不同，脚本通过临时运行已构建的node-chrome镜像来动态探测Chrome 与 ChromeDriver 的真实版本（脚本第 65-73 行）：

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 104.0.5112.101，取第 3 个字段得到104.0.5112.101；
• chromedriver --version输出形如ChromeDriver 104.0.5112.79 ...，取第 2 个字段得到104.0.5112.79；
• short_version()函数（脚本第 53-57 行）以.分割版本号并保留前两段，得到短版本104.0，与日志第 6、8 行完全吻合。

这种“以容器内真实二进制为准”的设计，保证了标签永远与实际打包的浏览器一致，不会出现版本漂移。同样的探测逻辑在脚本中还覆盖 chromium、edge、firefox、chrome-for-testing 分支，每个分支的awk取字段位置各不相同（如 Edge 取microsoft-edge --version的第 3 个字段、msedgedriver --version的第 4 个字段），反映了各浏览器版本输出格式的差异。

2.3 标签数组的构造规则

脚本为 chrome 分支构建了CHROME_TAGS数组（脚本第 75-99 行），核心规律是“三段式组合”：浏览器版本 × 驱动版本 × Grid 版本/构建日期，并同时提供完整版本与短版本两套：

CHROME_TAGS=( ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}-grid-${TAG_VERSION} ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}-${BUILD_DATE} ${CHROME_VERSION}-${BUILD_DATE} ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}-grid-${TAG_VERSION} ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}-${BUILD_DATE} ${CHROME_SHORT_VERSION}-${BUILD_DATE} )

当RELEASE_OLD_VERSION=false时，还会追加 4 个不带构建日期的“纯版本”标签（104.0.5112.101-chromedriver-104.0.5112.79、104.0.5112.101、104.0-chromedriver-104.0、104.0）。本次调用第 6 个参数为true，即发布归档旧版本，因此不追加纯版本标签，最终每个镜像恰好生成 6 个标签。

三、日志中的 12 个标签逐行解读

将脚本的retag调用（对node-chrome与standalone-chrome各执行一次）展开，就得到日志末尾的 12 行输出。以node-chrome为例，6 个标签及其语义如下：

同样的 6 个标签同时打到standalone-chrome上，形成镜像的“Node/Standalone”双形态。这种设计（在 docs/docker-hub/node-chrome.md 与 docs/docker-hub/standalone-chrome.md 中有完整说明）让使用者可以按精度需求选择标签：追求可复现用“完整版本 + grid + 日期”最长标签；追求便捷用最短的104.0-20250303即可锁定该次发布。

3.1 retag 函数：打标还是跨仓库镜像复制

retag() 是实际执行打标的函数。常规路径下执行docker tag并将源镜像selenium/node-chrome:4.29.0-20250303打上目标标签，若PUSH_IMAGE=true则随后docker push。它还支持一种特殊模式：当环境变量PROMOTE_TAGS=true时（发布流水线直接推广已测试镜像而非重建），改用docker buildx imagetools create在仓库与仓库之间复制多架构镜像清单——这是docker tag无法胜任的场景，因为docker pull只能拉取运行者自身架构，而imagetools直接操作 registry index，可保留多架构属性。

3.2 Makefile 如何编排这些目标

根目录 Makefile（第 781-808 行）将上述调用封装为发布目标：

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 第 15-16 行：PUSH_IMAGE=false、RELEASE_OLD_VERSION=false）。一次完整的make tag_and_push_browser_images会按顺序为五种浏览器镜像生成标签，归档日志中的单条记录正是该流程中 chrome 分支的一次快照。

四、如何利用归档版本标签落地测试

4.1 直接拉取精确版本镜像

基于本日志，你可以在任意需要 Chrome 104 场景下使用：

docker pull selenium/node-chrome:104.0.5112.101-chromedriver-104.0.5112.79-grid-4.29.0-20250303 docker pull selenium/standalone-chrome:104.0-20250303

重要前提：4.29.0属于 CHANGELOG/README.md 中“Archived Grid Versions”归档段，意味着这批标签对应的是历史发布，适合复现旧版本兼容性问题、回归测试或锁定浏览器行为；全新项目应优先使用最新 Grid 版本（如当前 4.48.0 行对应的最新 Chrome 标签）。同时该矩阵也明确提示：项目并未对每一种 Grid × 浏览器组合做全量测试，使用者需根据自身测试要求评估取舍。

4.2 与 Node/Standalone 镜像结合使用

标签里的node-chrome与standalone-chrome对应两种运行模式（完整命令可参考 docs/docker-hub/node-chrome.md 与 docs/docker-hub/standalone-chrome.md）：

• Node 模式：加入 Hub 所在的 Docker 网络，注册为 Grid 节点：

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

• Standalone 模式：单容器自含 Grid，适合本地快速验证：

docker run -d -p 4444:4444 -p 7900:7900 --shm-size="2g" \ selenium/standalone-chrome:104.0-20250303

两条命令都带上了--shm-size="2g"，这是运行含浏览器镜像时使用宿主机共享内存的标准实践；测试代码统一指向http://localhost:4444，可选通过http://localhost:7900/?autoconnect=1&resize=scale&password=secret观察容器内界面。此外，仓库根目录的 docker-compose-v3.yml 展示了将selenium/node-chrome纳入完整 Grid 编排的典型方式，把其中的 tag 替换为本日志中的归档标签即可整体锁定到 Chrome 104。

4.3 自定义打标：按需复用脚本

若你的内部流程需要为自己的镜像生成类似标签，可直接按第三节的规则复用脚本。例如只打本地标签、不推送、且追加纯版本标签：

./tag_and_push_browser_images.sh 4.29.0 20250303 myregistry false chrome false

此时会在myregistry/node-chrome与myregistry/standalone-chrome上额外生成104.0.5112.101、104.0等不带日期的标签，便于后续按浏览器版本直接引用。跨架构或跨仓库复制场景则参考前文PROMOTE_TAGS=true与PROMOTE_GHCR_NAMESPACE环境变量的用法。

五、标签与镜像构建的底层对应

日志中的版本组合之所以可信，是因为它们与 NodeChrome/Dockerfile 的构建逻辑一一对应：

• Chrome 版本由ARG CHROME_VERSION（默认google-chrome-stable）控制，也可通过ARG CHROME_DRIVER_VERSION固定 ChromeDriver 版本（NodeChrome/Dockerfile 第 18-51 行）；
• 构建阶段会把浏览器与驱动信息写入/opt/selenium/browsers/chrome/（name、version、binary_location），其中 version 提取方式与打标脚本一致——google-chrome --version | awk '{print $3}'；
• Standalone/Dockerfile 以node-chrome为基础层叠加 Selenium Server 与start-selenium-standalone.sh，因此standalone-chrome与node-chrome天然共享同一套浏览器版本标签。

换句话说：一份归档日志 = 一次完整发布动作的可复现证据，从命令参数、版本探测到最终标签产物都被完整留存。需要横向对比不同浏览器（chromium/edge/firefox）在同一 Grid 版本的打标差异时，可参照CHANGELOG/archived/4.29.0/下的同名日志文件（如chrome_105.md、edge_133.md、firefox_136.md等），它们的输出结构与本文解读的chrome_104.md完全同构。

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