测试后端云原生容器编排可观测性【免费下载链接】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点击查看免费下载本指南以仓库 CHANGELOG/4.48.0/chrome_110.md 为骨架完整解读这份 changelog 背后的一整套浏览器镜像标签生成机制。你将掌握 docker-selenium 镜像标签的命名规范与含义、Chrome 110 / ChromeDriver 110 与 Grid 4.48.0 的配套关系以及如何拉取、运行和编排这些固定版本镜像用于跨浏览器测试或版本锁定场景。这份 changelog 记录了什么CHANGELOG/4.48.0/chrome_110.md是 docker-selenium 发布流程中由 tag_and_push_browser_images.sh 自动生成的输出日志完整记录了一次针对 Chrome 110 的镜像打标签操作。原始内容如下./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true Tagging images for browser chrome, version 4.48.0, build date 20260909, namespace selenium Selenium Grid version - 4.48.0-20260909 Chrome version - 110.0.5481.177 Short Chrome version - 110.0 ChromeDriver version - 110.0.5481.77 Short ChromeDriver version - 110.0从这段输出可以提取出本次发布的核心版本事实组件完整版本短版本Selenium Grid4.48.0-20260909构建日期 202609094.48.0Google Chrome110.0.5481.177110.0ChromeDriver110.0.5481.77110.0随后脚本为node-chrome与standalone-chrome两组镜像各生成了 10 个标签合计 20 个镜像标签全部面向selenium命名空间Docker Hub 的selenium/node-chrome、selenium/standalone-chrome系列。这些标签正是本次 changelog 的正文将在下一节逐一解析。标签命名规范深度解析对照 tag_and_push_browser_images.sh 的源码可以精确还原每个标签的构造逻辑。脚本以VERSION、BUILD_DATE、NAMESPACE、PUSH_IMAGE、BROWSER、RELEASE_OLD_VERSION为参数本次调用的完整语义为./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true # 参数1 VERSION 4.48.0 Selenium Grid 版本 # 参数2 BUILD_DATE 20260909 构建日期 # 参数3 NAMESPACE selenium 镜像命名空间 # 参数4 PUSH_IMAGE false 只打标签不推送false # 参数5 BROWSER chrome 浏览器类型 # 参数6 RELEASE_OLD_VERSION true 保留旧版本发布时间线标签脚本首先通过docker run进入已构建的selenium/node-chrome:4.48.0-20260909镜像分别执行google-chrome --version与chromedriver --version再用short_version()函数按.分割取前两段得到短版本号。随后按CHROME_TAGS数组顺序生成三组不同粒度的标签第一组完整版本号 构建日期6 个110.0.5481.177-chromedriver-110.0.5481.77-grid-4.48.0-20260909 110.0.5481.177-chromedriver-110.0.5481.77-20260909 110.0.5481.177-20260909 110.0-chromedriver-110.0-grid-4.48.0-20260909 110.0-chromedriver-110.0-20260909 110.0-20260909第二组纯版本号4 个仅在 RELEASE_OLD_VERSIONfalse 时追加110.0.5481.177-chromedriver-110.0.5481.77 110.0.5481.177 110.0-chromedriver-110.0 110.0从源码可以看出几个关键点标签信息递进同一镜像被赋予从浏览器驱动Grid日期到仅浏览器短版本号的多重标签精度逐级降低用户可按需选择锁定粒度。RELEASE_OLD_VERSION的作用为true时只保留带构建日期的标签避免覆盖历史版本时间线上的标签Makefile 中对应RELEASE_OLD_VERSION变量用于旧版本发布防止破坏已存在的时间点标签为false时追加不带日期的纯版本标签供常规使用。retag()的两种路径常规路径执行docker tag 可选docker push本 changelog 中PUSH_IMAGEfalse因此只打标签不推送当PROMOTE_TAGStrue时改用docker buildx imagetools create在 registry 之间直接创建 manifest 索引标签以保留多架构镜像详见 tag_and_push_browser_images.sh 头部注释。镜像名与浏览器参数的对应chrome分支固定对node-chrome与standalone-chrome两个镜像名循环打标签tag_and_push_browser_images.sh同理chromium、edge、firefox、chrome-for-testing分支分别对应各自的 node/standalone 镜像。最终selenium/node-chrome与selenium/standalone-chrome各获得 10 个标签其中带grid-4.48.0-20260909的标签明确表达了浏览器 110 配套 Grid 4.48.0的完整组合信息。为什么需要固定浏览器版本CHANGELOG/README.md 开篇解释了这套矩阵与标签体系的动机项目希望持续供应最新的 Selenium Grid 核心版本及其新功能同时让用户仍能用于跨浏览器测试或因为特定浏览器版本存在兼容性问题、支持范围限制而固定pin某个浏览器版本。因此仓库同时交付 Node 与 Standalone 两种镜像形态并各自打包特定 Grid 与驱动/浏览器版本组合——用户只需在矩阵中找到镜像标签、拉取所需镜像即可开始测试。对于 Chrome 110 这类较老版本而言其价值正在于可复现当新版本 Chrome 行为变更导致回归、或被测系统只兼容旧浏览器时selenium/standalone-chrome:110.0.5481.177-20260909这样的标签就是一个确定性的、可反复拉取的测试环境。README 也明确提示项目并未对每一种 Grid×浏览器组合做完整全量测试用户应根据自身测试需求评估后自行决策CHANGELOG/README.md。Chrome 110 与 ChromeDriver 110 的配套逻辑Chrome 110 是一个特殊的版本分水岭。查看 NodeChrome/install-chromedriver.sh 源码可以发现脚本对115 之前的 Chrome 版本走了一条独立的legacy路径install-chromedriver.sh# Chrome versions before 115 predate Chrome for Testing and are served by the frozen # chromedriver.storage.googleapis.com API, which only ever had linux64. if [ ${ARCH} amd64 ] [ -n ${CHROME_MAJOR_VERSION} ] [ ${CHROME_MAJOR_VERSION} -lt 115 ]; then DRIVER_SOURCElegacy DRIVER_ARCHlinux64即Chrome 110 先于 Chrome for TestingCfT体系其 ChromeDriver 必须从冻结的chromedriver.storage.googleapis.com/LATEST_RELEASE_110旧接口解析且只提供linux64架构。这解释了本 changelog 中 ChromeDriver 版本 110.0.5481.77 与 Chrome 版本 110.0.5481.177 的配套来源——两者同属 110.x 系列由旧版 LATEST_RELEASE 接口按大版本号自动匹配。此外NodeChrome/Dockerfile 还展示了镜像构建时的版本可配置性ARG CHROME_VERSIONgoogle-chrome-stable可通过google-chrome-stable版本、google-chrome-beta、google-chrome-unstable指定 Chrome 的渠道或精确版本对应 install-chrome.sh 中的 apt 精确安装分支ARG CHROME_DRIVER_VERSION不传则自动按已安装 Chrome 的主版本号解析驱动install-chromedriver.sh 通过google-chrome --version提取 major 版本镜像构建时还会把 Chrome 版本写入/opt/selenium/browsers/chrome/version供 Grid 的浏览器能力匹配使用NodeChrome/Dockerfile。如何在实战中使用这些镜像标签拿到 changelog 中的标签后可直接用于三种典型场景。场景一直接拉取并验证版本组合docker pull selenium/standalone-chrome:110.0.5481.177-chromedriver-110.0.5481.77-grid-4.48.0-20260909 docker run --rm selenium/standalone-chrome:110.0.5481.177-chromedriver-110.0.5481.77-grid-4.48.0-20260909 \ google-chrome --version docker run --rm selenium/standalone-chrome:110.0.5481.177-chromedriver-110.0.5481.77-grid-4.48.0-20260909 \ chromedriver --version场景二docker-compose 编排固定版本 Grid以 Node Standalone 形态启动 Chrome 110 节点可与仓库 docker-compose-v3.yml 的结构类比services: chrome-110: image: selenium/node-chrome:110.0.5481.177-chromedriver-110.0.5481.77-grid-4.48.0-20260909 shm_size: 2gb depends_on: - selenium-hub environment: - SE_EVENT_BUS_PUBLISH_PORT4442 - SE_EVENT_BUS_SUBSCRIBE_PORT4443场景三在测试脚本中固定浏览器能力Selenium 客户端只需指向 Grid/Hub 地址并请求对应浏览器能力即可由服务端根据浏览器版本文件自动匹配节点例如ChromeOptions options new ChromeOptions(); options.setBrowserVersion(110.0); WebDriver driver new RemoteWebDriver(new URL(http://localhost:4444), options);注意Chrome 110 对应的镜像标签仅代表已打包的确定性组合实际运行效果仍受宿主机平台amd64与 Docker 资源共享内存、CPU、内存影响建议在正式使用前先做一次版本探测与冒烟验证。从版本矩阵定位镜像与 ChangelogCHANGELOG/README.md 是一张完整的Selenium Grid × 浏览器版本矩阵每一格 ✓ 都链接到对应 Grid 版本目录下的详细 changelog如本文件4.48.0/chrome_110.md。矩阵按浏览器Chrome、Chrome For Testing、Edge、Firefox分别建表最新版本在前、降序排列历史版本则被归档到archived/目录下如archived/4.47.0/chrome_110.md等供追溯旧组合使用。这套矩阵的生成与维护由 CHANGELOG/generate-matrix-readme.py 完成其工作分三步归档旧版本把当前目录下除最新版以外的 Grid 版本目录整体移入archived/扫描 changelog用正则([\w-])_(\d)\.md解析每个版本目录下的文件提取浏览器 版本号构建matrix[grid_version][browser]集合生成 README按浏览器与 Grid 版本双向排序渲染矩阵表格并在每格写入指向 changelog 的相对链接。在仓库 Makefile 中该脚本被update_browser_versions_matrix目标调用Makefile与fetch_version.py等版本抓取脚本串联构成抓版本 → 生成 changelog → 更新矩阵的自动化发布流水线。因此chrome_110.md这类文件不仅是版本记录也是矩阵索引与 CI 发布状态的证据链。使用限制与注意事项结合源码与文档使用这些固定版本标签时需注意以下几点覆盖范围声明README 明确表示没有对所有 Grid×浏览器组合做完整测试是否采用取决于用户的测试需求CHANGELOG/README.md架构限制Chrome 110 时代的 ChromeDriver 仅提供linux64legacy路径只在 amd64 下生效arm64 下 115 之前版本需要回退到 Debianchromium-driver包install-chromedriver.sh这也是 Chrome 110 组合仅适合 amd64 测试场景的原因标签精度差异110.0短版本标签会随该系列后续镜像构建被移动指向新镜像若需严格复现应优先使用带构建日期或完整版本号的标签运行环境上述命令与配置以当前仓库发布内容为准使用前请以 tag_and_push_browser_images.sh 与 NodeChrome/Dockerfile 中的实际参数为准进行核对。赞分享测试后端云原生容器编排可观测性【免费下载链接】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 浏览器镜像版本标签全解析以 Selenium Grid 4.48.0 与 Chrome for Testing 115 为例docker selenium 浏览器镜像版本标签全解析以 Selenium Grid 4.48.0 与 Chrome for Testing 115 为例测试后端云原生容器编排可观测性X6 Highlighter 高亮机制完全指南从内置 Stroke/ClassName 到自定义高亮器X6 Highlighter 高亮机制完全指南从内置 Stroke/ClassName 到自定义高亮器 X6JavaScript 图形编辑库基于 SVG测试后端云原生容器编排可观测性docker-selenium 浏览器镜像标签生成机制全解析以 Chrome 117 在 Selenium Grid 4.48.0 中的发布为例docker selenium 浏览器镜像标签生成机制全解析以 Chrome 117 在 Selenium Grid 4.48.0 中的发布为例 在 dock测试后端云原生容器编排可观测性上一篇codex-plugin-cc review gate如何开启给Claude加一道停止前质量门禁下一篇HMCL启动器跨平台支持解析Windows、macOS与Linux功能对比及实现原理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考