测试后端云原生容器编排可观测性【免费下载链接】docker-seleniumProvides 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点击查看免费下载本篇技术指南围绕 docker-selenium 仓库中 CHANGELOG/4.48.0/chrome-for-testing_119.md 记录的真实发布日志展开完整解析tag_and_push_browser_images.sh脚本如何为 Selenium Grid 4.48.0、Chrome for Testing 119.0.6045.105 组合生成 11 个 Docker 镜像标签并深入追溯浏览器/驱动配对安装、版本矩阵管理与镜像使用方式。读完本文你将掌握 docker-selenium 的浏览器镜像 Tag 命名规律、CfT 固定版本机制的原理以及如何在自动化测试中精准选用对应版本的 Node/Standalone 镜像。一、日志内容一次 Chrome for Testing 119 镜像的完整打标记录该文档本质上是一份发布流程的实况记录展示了发布脚本执行时的完整输出。原文内容如下完整继承未做删减./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome-for-testing true Tagging images for browser chrome-for-testing, version 4.48.0, build date 20260909, namespace selenium Selenium Grid version - 4.48.0-20260909 Chrome for Testing version - 119.0.6045.105 Short Chrome for Testing version - 119.0 ChromeDriver version - 119.0.6045.105 Short ChromeDriver version - 119.0 Tagged selenium/node-chrome-for-testing:119.0.6045.105-chromedriver-119.0.6045.105-grid-4.48.0-20260909 Tagged selenium/standalone-chrome-for-testing:119.0.6045.105-chromedriver-119.0.6045.105-grid-4.48.0-20260909 Tagged selenium/node-chrome-for-testing:119.0.6045.105-chromedriver-119.0.6045.105-20260909 Tagged selenium/standalone-chrome-for-testing:119.0.6045.105-chromedriver-119.0.6045.105-20260909 Tagged selenium/node-chrome-for-testing:119.0.6045.105-20260909 Tagged selenium/standalone-chrome-for-testing:119.0.6045.105-20260909 Tagged selenium/node-chrome-for-testing:119.0-chromedriver-119.0-grid-4.48.0-20260909 Tagged selenium/standalone-chrome-for-testing:119.0-chromedriver-119.0-grid-4.48.0-20260909 Tagged selenium/node-chrome-for-testing:119.0-chromedriver-119.0-20260909 Tagged selenium/standalone-chrome-for-testing:119.0-chromedriver-119.0-20260909 Tagged selenium/node-chrome-for-testing:119.0-20260909 Tagged selenium/standalone-chrome-for-testing:119.0-20260909从输出可以看到同一次发布同时产出两类镜像的标签Node 模式selenium/node-chrome-for-testing注册到 Grid 的节点与Standalone 模式selenium/standalone-chrome-for-testing单机自带 Hub 语义的完整实例。每次retag都会把同一镜像源再打上一个新标签因此 Node 与 Standalone 各自获得 11 个日志中列出 11 对但最终实际标签数量还与RELEASE_OLD_VERSION参数相关见下文源码分析。二、命令参数逐项解析一次调用如何驱动整个发布日志第一行即为完整命令其参数与 tag_and_push_browser_images.sh 脚本的参数定义一一对应参数值对应脚本变量含义4.48.0Selenium Grid 版本VERSION主版本号与BUILD_DATE拼成TAG_VERSION4.48.0-2026090920260909构建日期BUILD_DATE用于组成TAG_VERSION及各类带日期的标签selenium镜像命名空间NAMESPACE镜像前缀最终 tag 为selenium/node-chrome-for-testing:...false是否推送PUSH_IMAGE默认false时只docker tag不执行docker pushchrome-for-testing浏览器类型BROWSER决定走case分支中的chrome-for-testing)逻辑true是否为旧版本发布RELEASE_OLD_VERSION关键开关为true时不生成不带日期/不带 Grid 版本的短别名标签见下文此外脚本还支持两个环境变量PROMOTE_TAGS默认false为true时改用docker buildx imagetools create在 registry 间复制 manifest保证多架构与PROMOTE_GHCR_NAMESPACE同时镜像到 GHCR 命名空间。日志中这两个变量均未启用走的是本地docker tag路径。三、Tag 命名规范全解11 个标签从何而来日志中出现的 11 个标签并非随机命名而是由 tag_and_push_browser_images.sh 中CHROME_TAGS数组的构造逻辑决定的。以chrome-for-testing分支为例脚本先通过两条探测命令拿到真实版本号CHROME_VERSION$(docker run --platform ${PLATFORM} --rm \ ${NAMESPACE}/node-chrome-for-testing:${TAG_VERSION} google-chrome --version | awk {print $5}) CHROMEDRIVER_VERSION$(docker run --platform ${PLATFORM} --rm \ ${NAMESPACE}/node-chrome-for-testing:${TAG_VERSION} chromedriver --version | awk {print $2})注意 Chrome 版本提取的是awk {print $5}第 5 个字段即119.0.6045.105与普通 Chrome 镜像的awk {print $3}不同——这正是 CfT 版本的google-chrome --version输出格式差异所决定的。随后short_version()函数把119.0.6045.105截断为119.0。于是生成 6 组基础标签组别标签模式以 Chrome 完整版本为例1${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}-grid-${TAG_VERSION}2${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}-${BUILD_DATE}3${CHROME_VERSION}-${BUILD_DATE}4${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}-grid-${TAG_VERSION}5${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}-${BUILD_DATE}6${CHROME_SHORT_VERSION}-${BUILD_DATE}关键逻辑RELEASE_OLD_VERSIONtrue的作用。当该参数为false时脚本还会追加 4 个无日期、无 Grid 版本的浮动别名标签${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}、${CHROME_VERSION}、${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}、${CHROME_SHORT_VERSION}。而在本日志中参数为true代表这是为历史浏览器版本119补发标签避免用最新版别名误导用户以为 119 是最新版本因此只打 6 组带日期/带 Grid 版本的精确标签这就是日志中每类镜像只有 6 个标签Node Standalone 共 12 行输出的原因。这种设计在 docs/docker-hub/node-chrome-for-testing.md 中被总结为官方 Tag 结构selenium/node-chrome-for-testing-Major.Minor.Patch-YYYYMMDD selenium/node-chrome-for-testing-browserVersion-browserDriver-browserDriverVersion-Major.Minor.Patch-YYYYMMDD即用户既可以按浏览器完整版本精确锁定如119.0.6045.105-chromedriver-119.0.6045.105-grid-4.48.0-20260909也可以按短版本简化如119.0-chromedriver-119.0-20260909或者只按构建日期如4.48.0-20260909跟随该批次最新浏览器。Makefile 中通过tag_and_push_chrome-for-testing_images等 target见 Makefile封装了这组调用供 CI 在每次发布时统一执行。四、Chrome for Testing 119 镜像内部浏览器与驱动的版本锁定原理这份日志输出的核心事实是Chrome for Testing 与 ChromeDriver 版本完全一致都是 119.0.6045.105。这是 CfT 机制天然保证的而非巧合。4.1 安装脚本如何落地 CfT 版本NodeChrome/install-chrome-for-testing.sh 负责在镜像构建时安装指定 CfT 版本关键步骤版本解析CFT_VERSION支持直接写版本号也支持通道名STABLE|BETA|DEV|CANARY此时会通过 CfT 的LATEST_RELEASE_${CHANNEL}接口解析出最新版本号下载从https://storage.googleapis.com/chrome-for-testing-public/${CFT_VERSION}/${CFT_PLATFORM}/chrome-${CFT_PLATFORM}.zip下载CFT_PLATFORM默认linux64并用wget --spider预检版本是否存在不存在则直接报错退出安装解压后安装到/opt/chrome并创建/usr/bin/google-chrome软链接依赖处理优先读取 CfT 包内自带的deb.deps文件并解析依赖去除版本约束、处理pkg1 | pkg2替代包、将libasound2归一化为libasound2t64无该文件时使用脚本内置的完整依赖列表兜底。4.2 Dockerfile 中的 CFT 开关NodeChrome/Dockerfile 通过构建参数控制走哪条安装路径ARG CFT_VERSIONSTABLE ARG INSTALL_CFTfalse COPY ... install-chrome-for-testing.sh /opt/bin/ RUN ... if [ ${INSTALL_CFT} true ]; then \ CFT_VERSION${CFT_VERSION} /opt/bin/install-chrome-for-testing.sh; \ else \ /opt/bin/install-chrome.sh; \ fi构建node-chrome-for-testing镜像时INSTALL_CFTtrue、CFT_VERSION119.0.6045.105从而产出固定版本、不自动更新的 CfT 浏览器同时写入浏览器版本元数据awk {print $5}提取版本写入/opt/selenium/browsers/chrome/version供 Grid 节点上报能力。4.3 ChromeDriver 来源解析NodeChrome/resolve-chromedriver-source.sh 决定了 ChromeDriver 从哪个渠道获取优先使用 CfT 官方渠道与浏览器同版本锁步发布探测chromedriver-linux64.zip是否存在对于 amd64 架构若 CfT 渠道不可达则直接失败设计上不允许 amd64 静默回退到第三方源而 arm64 在旧版本Chrome 153 之前无 arm64 构建会回退到 Debianchromium-driver包。这也解释了本日志中node-chrome-for-testing的 ChromeDriver 与 Chrome 同为119.0.6045.105的根源——驱动与浏览器来自同一个 CfT 版本构建。4.4 平台限制CfT 只发布linux64因此selenium/node-chrome-for-testing仅支持linux/amd64日志中的--platform参数正是为探测版本而指定的。在 ARM64 环境应改用selenium/node-chrome或selenium/node-chromium。五、版本矩阵119 在 4.48.0 发布中的定位CHANGELOG/README.md 维护了一张 Selenium Grid x Browser Version Matrix每行是一个 Grid 版本每列是一个浏览器大版本✓链接到对应发布记录。在 4.48.0 的 Chrome For Testing 行中覆盖 113 到 152 共 40 个浏览器版本本文主题的119正是其中之一对应 chrome-for-testing_119.md相邻版本记录见 chrome-for-testing_120.md。矩阵文档明确说明了其动机与边界动机为最新 Selenium Grid 核心版本持续提供新功能的同时保留锁定浏览器版本的能力——例如某个浏览器版本存在兼容性问题或测试要求必须在特定版本上回归验证使用方式用户只需在矩阵中找到所需 Grid 浏览器组合按对应 tag 拉取镜像即可开始测试边界声明官方并未对每一种 Grid × 浏览器组合做全量功能测试用户需结合自身测试需求评估选择。据此可以得出本日志的实际意义它记录了 4.48.0 发布批次中为 119.0.6045.105 这一较旧浏览器版本补发精确标签的过程让仍在使用 Chrome 119 的测试团队可以在最新 Grid 4.48.0 上继续运行而不必被迫升级浏览器。六、实战拉取并使用 119.0.6045.105 组合镜像6.1 按日志中的标签拉取以日志中最完整的标签为例docker pull selenium/node-chrome-for-testing:119.0.6045.105-chromedriver-119.0.6045.105-grid-4.48.0-202609096.2 与 Grid Hub 联动运行 Node参考 docs/docker-hub/node-chrome-for-testing.md 的标准流程docker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:4.48.0-20260909 docker run -d --net grid -e SE_EVENT_BUS_HOSTselenium-hub \ --platform linux/amd64 \ --shm-size2g \ selenium/node-chrome-for-testing:119.0.6045.105-chromedriver-119.0.6045.105-grid-4.48.0-20260909要点包含浏览器的镜像建议显式加--shm-size2g使用宿主共享内存避免浏览器崩溃该 Node 注册的能力为browserNamechrome已有测试脚本无需改动测试指向http://localhost:4444可通过http://localhost:7900/?autoconnect1resizescalepasswordsecret观察容器内浏览器画面需要SE_VNC_NO_PASSWORD等默认配置且对应端口已映射若使用短版本标签如119.0-chromedriver-119.0-20260909会自动指向该短版本系列的最新补丁版本。6.3 镜像体积与版本信息的核验拉取后可自行核验容器内版本是否与日志一致docker run --rm --platform linux/amd64 \ selenium/node-chrome-for-testing:119.0.6045.105-chromedriver-119.0.6045.105-grid-4.48.0-20260909 \ google-chrome --version docker run --rm --platform linux/amd64 \ selenium/node-chrome-for-testing:119.0.6045.105-chromedriver-119.0.6045.105-grid-4.48.0-20260909 \ chromedriver --version输出应分别为Google Chrome 119.0.6045.105与ChromeDriver 119.0.6045.105——这正是发布脚本在打标前用于探测版本的同款命令见 tag_and_push_browser_images.sh。七、总结一份看似简单的打标日志背后串联了 docker-selenium 发布体系的三层设计Tag 即契约浏览器版本-驱动版本-Grid 版本-日期的完整标签让镜像内容自描述用户无需拉取即可推断内部组合tag_and_push_browser_images.shCfT 固定版本机制Chrome for Testing 与 ChromeDriver 同版本发布安装脚本与驱动解析脚本共同保证已知的良好配对install-chrome-for-testing.sh、resolve-chromedriver-source.sh矩阵化管理通过 CHANGELOG/README.md 将 Grid 与浏览器版本解耦既支持尝鲜最新 Grid 功能也支持在旧浏览器版本上做回归而RELEASE_OLD_VERSIONtrue正是为后者设计的发布路径。对于仍需在 Chrome 119 上运行的测试团队selenium/node-chrome-for-testing:119.0.6045.105-chromedriver-119.0.6045.105-grid-4.48.0-20260909就是官方提供的、可追溯、可复现的固定组合镜像。赞分享测试后端云原生容器编排可观测性【免费下载链接】docker-seleniumProvides 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点击查看免费下载相关推荐解读 Selenium Grid 4.48.0 的 Chrome for Testing 133 发布记录镜像 Tag 体系与打标机制全解析解读 Selenium Grid 4.48.0 的 Chrome for Testing 133 发布记录镜像 Tag 体系与打标机制全解析 本篇技术指南以测试后端云原生容器编排可观测性docker-selenium 4.48.0 发布 Chrome for Testing 120.0 镜像Tag 生成机制与命名规范全解析docker selenium 4.48.0 发布 Chrome for Testing 120.0 镜像Tag 生成机制与命名规范全解析 本篇技术指南以 C测试后端云原生容器编排可观测性Selenium Grid 浏览器镜像发布记录解读Chrome for Testing 124.0.6367.207 的镜像 Tag 体系与发布机制Selenium Grid 浏览器镜像发布记录解读Chrome for Testing 124.0.6367.207 的镜像 Tag 体系与发布机制 CHAN测试后端云原生容器编排可观测性上一篇FastDownloader用OkHttp链式API搞定Android多线程分块下载下一篇Dism 系统清理指南如何腾出 C 盘空间并给系统上保险创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考