测试后端云原生容器编排可观测性【免费下载链接】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_106.md这一版本变更记录逐行拆解 Selenium Grid 4.48.0 时代下 Chrome 106 镜像的完整发布流程从tag_and_push_browser_images.sh的参数语义、版本自动探测到 12 个规范标签的命名规则与正确拉取姿势帮助你读懂版本矩阵、按需固定浏览器版本并精准选取镜像标签。一、版本矩阵changelog 文件在整个仓库中的位置docker-selenium 为每个 Grid 主版本维护一套「Selenium Grid × 浏览器版本矩阵」总览入口是 CHANGELOG/README.md。矩阵中每一格是一个✓链接指向对应 Grid 版本 浏览器版本的详细变更记录文件例如本篇文章的主角 CHANGELOG/4.48.0/chrome_106.md 就对应「Grid 4.48.0 Chrome 106」这一格。该矩阵的设计动机正如 CHANGELOG/README.md 开头所述既要持续供应最新的 Selenium Grid 核心版本又要让用户能固定pin某个浏览器版本用于跨浏览器测试或规避特定浏览器版本上的兼容性问题。因此仓库会同时发布 Node 与 Standalone 两类镜像并在其中打包「Grid 版本 浏览器版本 驱动版本」三元组用户只需找到目标标签、拉取镜像即可开始测试。需要特别说明的是README 中明确提示项目并未对「Grid × 浏览器」的每一种组合做全量回归测试用户应根据自身测试需求评估选择版本记录文件记录的是「该组合确实被打包并打上了标签」这一事实。二、逐行解读一次真实的 Chrome 106 标签发布会话chrome_106.md全文是一段命令执行日志完整记录了针对旧版浏览器 Chrome 106 执行镜像打标签脚本的过程。命令本身为./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true对应脚本 tag_and_push_browser_images.sh 的参数定义见脚本 L3-L9各位置参数含义如下位置参数值对应变量含义14.48.0VERSIONSelenium Grid 版本号220260909BUILD_DATE构建日期YYYYMMDD3seleniumNAMESPACE镜像命名空间默认selenium4falsePUSH_IMAGE是否推送镜像到 Registry默认false5chromeBROWSER目标浏览器6trueRELEASE_OLD_VERSION是否为旧版本浏览器打标签默认false7未传PLATFORM目标平台默认linux/amd64日志的第 3 行Tagging images for browser chrome, version 4.48.0, build date 20260909, namespace selenium对应脚本 L59 的输出随后脚本进入case ${BROWSER}的chrome)分支L61-L106。2.1 版本号的自动探测docker run awk脚本并不会假设镜像内装了什么版本而是直接运行刚构建好的 Node 镜像去探测L65-L73CHROME_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 106.0.5249.119因此awk {print $3}取到106.0.5249.119chromedriver --version的输出形如ChromeDriver 106.0.5249.61 (...), 因此awk {print $2}取到106.0.5249.61。日志中Chrome version - 106.0.5249.119与ChromeDriver version - 106.0.5249.61正是这一探测结果。随后short_version()函数L53-L57将完整版本号按.切分并只取前两段106.0.5249.119→106.0106.0.5249.61→106.0。这就是日志中Short Chrome version - 106.0与Short ChromeDriver version - 106.0的由来。短版本号的存在意义在于它不会随补丁版本patch更新而失效便于用户引用「某个大版本系列」的最新构建。2.2 为什么 Chrome 106 走的是「legacy」驱动源Chrome 106 是一个值得注意的版本分界Chrome 115 之前的版本先于 Chrome for TestingCfT体系存在。在 NodeChrome/install-chromedriver.sh 中L44-L47可以看到明确的兼容分支if [ ${ARCH} amd64 ] [ -n ${CHROME_MAJOR_VERSION} ] [ ${CHROME_MAJOR_VERSION} -lt 115 ]; then DRIVER_SOURCElegacy DRIVER_ARCHlinux64 ...即 Chrome 主版本号小于 115 时ChromeDriver 不会走 CfT 下载路径而是使用已冻结的chromedriver.storage.googleapis.com旧版 API脚本 L62-L66通过LATEST_RELEASE_106这类端点解析对应主版本的驱动并下载chromedriver_linux64.zip。这正是 Chrome 106 这类「老版本浏览器」仍能在 4.48.0 新 Grid 中正常工作的底层保证之一同时说明该路径仅有 linux64 架构产物属脚本注释中明确指出的历史遗留事实。三、12 个标签的语义命名规范全解析脚本在chrome)分支中构建CHROME_TAGS数组L75-L99随后对node-chrome与standalone-chrome两种镜像各打一遍标签L101-L104。日志中的 12 行Tagged ...因此拆分为两个 6 元组。以node-chrome为例完整标签如下standalone-chrome同理#标签语义1106.0.5249.119-chromedriver-106.0.5249.61-grid-4.48.0-20260909完整版 Chrome ChromeDriver Grid 版本 构建日期信息最全2106.0.5249.119-chromedriver-106.0.5249.61-20260909完整版 Chrome ChromeDriver 构建日期3106.0.5249.119-20260909完整版 Chrome 构建日期4106.0-chromedriver-106.0-grid-4.48.0-20260909短版 Chrome ChromeDriver Grid 版本 构建日期5106.0-chromedriver-106.0-20260909短版 Chrome ChromeDriver 构建日期6106.0-20260909短版 Chrome 构建日期这套标签体系与 docs/docker-hub/node-chrome.md 中记载的 Tagging Convention 完全一致——该文档给出了通用形式selenium/node-chrome-Major.Minor.Patch-YYYYMMDD selenium/node-chrome-browserVersion-browserDriver-browserDriverVersion-Major.Minor.Patch-YYYYMMDD并注明「plus all the permutations from the above one」即上述所有组合的排列变体。也就是说标签从「最精确钉死一切版本」到「最宽松仅钉浏览器大版本 构建日期」都有覆盖用户可以按自己的可重复性需求挑选。3.1 关键细节为什么这里没有「浮动标签」细心的读者会发现日志中并没有出现selenium/node-chrome:106.0这类不带构建日期的短标签。原因在于脚本第 6 个参数RELEASE_OLD_VERSIONtrue。对照 tag_and_push_browser_images.sh 的 L88-L99if [ ${RELEASE_OLD_VERSION} false ]; then CHROME_TAGS( ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION} ${CHROME_VERSION} ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION} ${CHROME_SHORT_VERSION} ) fi只有当RELEASE_OLD_VERSIONfalse即发布的是当前最新浏览器版本时才会额外追加106.0、106.0.5249.119等「浮动标签」——这类标签不带构建日期会随同系列后续构建被不断覆写语义上指向该系列的最新构建。而本次记录的对象是 4.48.0 时代已经「过时」的 Chrome 106因此脚本以RELEASE_OLD_VERSIONtrue运行只为旧版本生成带构建日期的不可变标签避免无意中把「最新 106」的浮动指针移动到旧构建上。这正是本次输出恰好 12 个标签而非 20 个的原因。3.2 打标签但不推送PUSH_IMAGEfalse 的行为日志中每条都是Tagged ...没有任何docker push输出。对照retag()函数L31-L51当PUSH_IMAGEtrue时每个docker tag之后会跟随docker push而false时只执行本地docker tag。同时注释L18-L30还说明了另一种发布模式当PROMOTE_TAGStrue由 deploy.yml 在发布时设置脚本改用docker buildx imagetools create在 registry 之间直接创建多架构 manifest 别名而不是重新构建——这是 CI 发布链路的优化路径日常在本地复现标签流程时并不涉及。四、实战拉取并运行 Chrome 106 镜像4.1 直接拉取固定版本# 信息最全的标签推荐用于可复现测试 docker pull selenium/node-chrome:106.0.5249.119-chromedriver-106.0.5249.61-grid-4.48.0-20260909 # 或更简短短版 Chrome 构建日期 docker pull selenium/node-chrome:106.0-20260909注意若使用不带grid-段落的标签如106.0-20260909镜像内实际打包的 Grid 版本需结合 generate_release_notes.sh 生成的版本矩阵见 CHANGELOG/README.md交叉确认要绝对钉死「Grid 4.48.0 Chrome 106」首选包含grid-4.48.0-20260909的完整标签。4.2 以 Node 模式接入 Selenium Grid参考 docs/docker-hub/node-chrome.md 的标准接入流程先建网络、再起 Hub、最后起 Node。将文档中的latest替换为本次的固定标签# 1. 创建网络 docker network create grid # 2. 启动 Hub docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:latest # 3. 启动固定版本的 Chrome Node docker run -d --net grid \ -e SE_EVENT_BUS_HOSTselenium-hub \ --shm-size2g \ selenium/node-chrome:106.0-chromedriver-106.0-grid-4.48.0-20260909随后将 WebDriver 测试指向http://localhost:4444即可如需观察容器内浏览器运行情况可访问http://localhost:7900/?autoconnect1resizescalepasswordsecret。务必注意对含浏览器的镜像运行docker run时官方建议使用--shm-size2g以使用宿主机共享内存避免 Chrome 因/dev/shm过小崩溃。测试完毕后可执行docker network rm grid清理。4.3 以 Standalone 模式单机运行若不需要 Hub-Node 架构可直接使用standalone-chrome镜像一个容器内同时包含 Grid 服务器与 Chrome 浏览器docker run -d -p 4444:4444 --shm-size2g \ selenium/standalone-chrome:106.0-chromedriver-106.0-grid-4.48.0-20260909Standalone 与 Node 的区别在于Node 需要自行注册到 Hub/EventBus而 Standalone 自带完整的 Grid 组件开箱即用。五、如何自助验证与复现核对版本号仓库提供了 generate_release_notes.sh发布时同样通过docker run探测各镜像中的 Chrome、ChromeDriver、Grid 版本并生成「Released versions」表格——它与 CHANGELOG/README.md 的矩阵相互印证可用来核对本文记录中的版本三元组。复现打标签流程若本地已有selenium/node-chrome:4.48.0-20260909镜像可直接执行本文开头那条命令把selenium替换为你的命名空间观察与日志逐行一致的输出。驱动解析逻辑的单测tests/node_chrome/test_resolve_chromedriver_source.py对 ChromeDriver 来源解析legacy/CfT/Chromium 包三路有自动化断言是理解「Chrome 106 走 legacy 路径」行为的最佳测试佐证。自定义构建版本如需构建含特定 Chrome 版本的镜像可参考 NodeChrome/Dockerfile 中的CHROME_VERSION默认google-chrome-stable可传google-chrome-beta/unstable或google-chrome-stable106.0.5249.119-1这类 apt 精确版本与CHROME_DRIVER_VERSION参数构建逻辑分别由 NodeChrome/install-chrome.sh 与 NodeChrome/install-chromedriver.sh 实现。六、标签选择建议结合 docs/docker-hub/node-chrome.md 的 Tagging Convention 与本次 Chrome 106 记录给出选择策略追求最强可复现性CI 流水线、回归基线使用完整五段标签如106.0.5249.119-chromedriver-106.0.5249.61-grid-4.48.0-20260909浏览器、驱动、Grid、构建日期全部钉死。需要「某大版本系列最新」对旧版浏览器使用106.0-20260909带构建日期最稳妥对当前最新浏览器106.0浮动标签会指向同系列最新构建但注意它会被后续构建覆写。只想固定浏览器、跟随 Grid 更新优先选node-chrome:106.0-chromedriver-106.0-grid-新版本-新日期形式的标签前提是该组合存在于对应 Grid 版本的矩阵中在 CHANGELOG/README.md 中可查。从源码结构看这套「完整版 短版 × 是否含 Grid 版本 × 是否含构建日期」的标签生成逻辑在chrome / chromium / edge / firefox / chrome-for-testing五个分支中完全对称见 tag_and_push_browser_images.sh 的 L61-L281因此本文对 Chrome 106 的解读方式可直接迁移到矩阵中的任何浏览器与版本组合。赞分享测试后端云原生容器编排可观测性【免费下载链接】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点击查看免费下载相关推荐PostHog 趋势视图选型指南折线趋势Trend Line与斜率视图Slope View的正确打开方式PostHog 趋势视图选型指南折线趋势Trend Line与斜率视图Slope View的正确打开方式 导读 在 PostHog 产品分析中X测试后端云原生容器编排可观测性docker-selenium 版本矩阵解析Selenium Grid 4.48.0 与 Chrome 121.0.6167.184 镜像标签及 Tag 生成机制详解docker selenium 版本矩阵解析Selenium Grid 4.48.0 与 Chrome 121.0.6167.184 镜像标签及 Tag 生成测试后端云原生容器编排可观测性Selenium Grid 4.48.0 的 Chrome 133 镜像标签全解析读懂 node-chrome / standalone-chrome 版本矩阵的生成逻辑Selenium Grid 4.48.0 的 Chrome 133 镜像标签全解析读懂 node chrome / standalone chrome 版本矩测试后端云原生容器编排可观测性上一篇为什么Monty没有socket、subprocess和eval沙箱模块白名单设计解析下一篇智谱AutoGLM 2.0震撼发布全球首款手机Agent改写人机协作规则开启AI执行新纪元创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考