测试后端云原生容器编排可观测性【免费下载链接】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/archived/4.34.0/chrome_108.md 中 Chrome 108 的完整打标签日志为骨架结合仓库根目录发布脚本 tag_and_push_browser_images.sh、CHANGELOG/README.md 版本矩阵与 Makefile 构建目标逐行解读selenium/node-chrome、selenium/standalone-chrome镜像那 20 个标签的生成逻辑、命名规则与实战选取方法。读完你既能读懂这套「浏览器版本 × Selenium Grid 版本」矩阵背后的自动化发布流程也能熟练挑选并验证适合自己测试场景的镜像标签。一、变更记录在版本矩阵中的位置与阅读方式该文档属于CHANGELOG/archived/4.34.0/目录下的归档变更记录其主题为Selenium Grid 4.34.0 发布周期内为 Chrome 108108.0.5359.124与 ChromeDriver 108108.0.5359.71生成的镜像标签清单。在 CHANGELOG/README.md 的「Archived Grid Versions Chrome」矩阵中4.34.0一行覆盖了从 Chrome 137 一路回溯到 Chrome 95 的诸多版本其中 135、138 等个别版本空缺chrome_108.md就是这一行里 Chrome 108 单元格✓链接指向的详细变更记录。矩阵的阅读约定是最新 Grid 版本在前浏览器版本按数字降序排列每个 ✓ 链接到对应 Grid 版本 × 浏览器版本组合的详细日志。这份矩阵存在的动机在 CHANGELOG/README.md 中写得很清楚在持续供给最新 Selenium Grid 核心功能的同时允许用户出于跨浏览器测试、或因特定浏览器版本存在兼容问题而需要固定浏览器版本等诉求按需选择历史浏览器版本。仓库为 Node 与 Standalone 两类镜像同时打包 Grid 与指定的驱动/浏览器版本用户只需找到标签、拉取镜像即可开始测试。矩阵文档同时提示并非每个 Grid × 浏览器组合都经过完整测试验证使用者需按自身测试要求自行评估——这是阅读任何一条 changelog 前都应记住的前提。二、命令行入口与每个参数的语义chrome_108.md的第一行给出了触发本次打标签动作的完整命令./tag_and_push_browser_images.sh 4.34.0 20250727 selenium false chrome true对照 tag_and_push_browser_images.sh 顶部的参数解析7 个位置参数依次为位置参数本次取值含义$1VERSION4.34.0Selenium Grid 版本号$2BUILD_DATE20250727构建日期格式 YYYYMMDD与 VERSION 拼接成4.34.0-20250727的 TAG_VERSION$3NAMESPACEselenium镜像命名空间脚本第 16 行还会用NAME环境变量兜底$4PUSH_IMAGEfalse是否在打标签后执行docker pushfalse表示仅本地打标签$5BROWSERchrome浏览器类型脚本 case 分支支持 chrome / chromium / edge / firefox / chrome-for-testing$6RELEASE_OLD_VERSIONtrue是否补打「旧版本」追加标签详见下文第五节$7PLATFORM未传默认查询版本信息时容器运行的平台默认linux/amd64用于交叉架构构建日志第 2 行输出的Selenium Grid version - 4.34.0-20250727正是TAG_VERSION${VERSION}-${BUILD_DATE}脚本第 15 行的展开结果之后的每一行Tagged ...都对应一次 retag() 调用。三、版本来源镜像自身是唯一事实来源日志第 3、5 行给出了两组关键版本号Chrome 108.0.5359.124、ChromeDriver 108.0.5359.71短版本号均为 108.0。它们并非硬编码在脚本里而是在打标签之前实时从已构建好的selenium/node-chrome:4.34.0-20250727镜像中探测出来的脚本第 65、70 行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})即临时启动 node-chrome 容器分别执行google-chrome --version与chromedriver --version再用awk提取输出中的第 3、第 2 个字段得到精确版本号。随后short_version()函数脚本第 53-57 行按.切分版本号并取前两段得到短版本108.0。这种方式保证了「镜像里实际装的浏览器版本」与「标签上宣称的版本」永远一致不会出现脚本里手写版本号与镜像内容漂移的问题。这些版本号最终落盘于镜像的构建阶段——NodeChrome/Dockerfile 中会执行google-chrome --version | awk {print $3}将版本写入/opt/selenium/browsers/chrome/version并在binary_location中登记 Chrome 可执行文件路径Node 启动时据此向 Grid 注册能力capabilities。四、标签矩阵全解码20 个标签的完整含义日志中除版本探测与提示行外共输出 20 行Taggednode-chrome 与 standalone-chrome 各 10 个标签。这正是脚本第 101-104 行的循环行为for chrome_tag in ${CHROME_TAGS[]}; do retag node-chrome ${chrome_tag} retag standalone-chrome ${chrome_tag} doneCHROME_TAGS数组脚本第 75-99 行在RELEASE_OLD_VERSIONtrue时共 10 个元素按日志顺序解码如下#标签命名语义1108.0.5359.124-chromedriver-108.0.5359.71-grid-4.34.0-20250727完整浏览器版本 完整驱动版本 完整 Grid 版本信息最全2108.0.5359.124-chromedriver-108.0.5359.71-20250727完整浏览器/驱动版本 构建日期无 Grid 版本3108.0.5359.124-20250727完整浏览器版本 构建日期4108.0-chromedriver-108.0-grid-4.34.0-20250727短版本浏览器/驱动 完整 Grid 版本5108.0-chromedriver-108.0-20250727短版本浏览器/驱动 构建日期6108.0-20250727短版本浏览器 构建日期7108.0.5359.124-chromedriver-108.0.5359.71完整浏览器/驱动版本无日期、无 Grid8108.0.5359.124仅完整浏览器版本9108.0-chromedriver-108.0短版本浏览器/驱动10108.0仅短浏览器版本其中第 16 个标签无条件生成第 710 个标签仅当RELEASE_OLD_VERSION ! false时追加脚本第 88-99 行。就本次命令而言true意味着这是一次为历史/旧版本 Chrome 补全「干净」标签的归档操作让用户可以直接使用selenium/node-chrome:108.0、selenium/standalone-chrome:108.0这类简洁标签而不必携带冗长的 Grid 版本与构建日期。每个retag调用的执行细节脚本第 31-51 行默认路径下使用docker tag将NAMESPACE/${image}:${TAG_VERSION}打上新标签PUSH_IMAGEtrue时再对每个标签执行docker push若PROMOTE_TAGStrue由 CI 的 deploy 流程设置则改用docker buildx imagetools create直接在 registry 之间为多架构 manifest 建立别名避免docker pull只带回 runner 单一架构镜像的问题。五、为什么需要一整套标签固定浏览器版本的实战价值从使用者的角度看这 10 类标签分别服务于不同诉求跨浏览器矩阵测试用短版本标签如108.0即可锁定 Chrome 主版本配合其它浏览器镜像构建兼容性矩阵精确复现缺陷用完整版本标签如108.0.5359.124-chromedriver-108.0.5359.71同时锁定浏览器与驱动补丁版本排除「驱动与浏览器不完全匹配」的干扰追溯构建产物带构建日期的标签如108.0.5359.124-20250727让镜像与某次具体发布强绑定便于审计与回滚严格复现发布环境...-grid-4.34.0-20250727完整三元组标签把 Grid、浏览器、驱动、构建日期一次性全部钉死适合需要在与 CI 完全相同环境里复现问题的场景。注意node-chrome与standalone-chrome的差异前者是Node 镜像需要搭配 Router/Hub 组成分布式 Grid后者是Standalone 镜像单容器内即包含完整的 Selenium Grid 与浏览器适合本地开发或小规模并行。因此同一套版本组合会被同时打到两种镜像上日志中每个 node-chrome 标签之后紧跟同名的 standalone-chrome 标签。六、与构建工作流的衔接Makefile 中的调用链这条命令不会在发布流程中单独出现而是由 Makefile 聚合驱动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_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) chrome $(RELEASE_OLD_VERSION)tag_and_push_browser_images目标会依次对 chrome、chrome-for-testing、chromium、edge、firefox 五个浏览器分支执行同一脚本对应脚本第 61-285 行 case 分支各分支的版本探测命令与标签数组结构完全同构仅浏览器/驱动命令与字段位置不同。当某次发布需要「复用已经测试通过的镜像而不是重建」时通过PROMOTE_TAGStrue走 imagetools 路径而像 Chrome 108 这类历史版本的归档日志则对应RELEASE_OLD_VERSIONtrue的补标签场景即本次chrome_108.md记录的内容。七、如何在你的测试中选用这些标签结合 tests/docker-compose-v3-test-standalone.yml 等仓库自带的示例编排文件选用方式非常直接# 拉取并运行 Standalone Chrome 108短版本标签最常用 docker run -d -p 4444:4444 --shm-size2g selenium/standalone-chrome:108.0 # 精确锁定浏览器与驱动补丁版本 docker run -d -p 4444:4444 --shm-size2g \ selenium/standalone-chrome:108.0.5359.124-chromedriver-108.0.5359.71 # 以 Node 形态接入已有 Grid需替换为你的 Hub/Router 地址 docker run -d --shm-size2g -e SE_EVENT_BUS_PUBLISH_PORT4442 \ selenium/node-chrome:108.0启动后可用仓库根目录的 check-grid.sh 同款逻辑curl http://localhost:4444/wd/hub/status验证 Grid 就绪状态再向/wd/hub发送标准的 WebDriver 请求声明browserName: chrome、browserVersion: 108.0即可让 Grid 调度到对应节点。若测试脚本对browserVersion有精确匹配要求直接使用完整版本标签对应的镜像最稳妥——这正是本文第三节所述「版本由镜像自身探测生成」这一设计的意义所在。结语一条看似只有 21 行打标签日志的归档 changelog背后是 docker-selenium 一整套「镜像版本自探测 多级标签矩阵 双镜像同步」的发布机制。理解 tag_and_push_browser_images.sh 的标签构造规则就等于掌握了 CHANGELOG 矩阵每一格 ✓ 的生成原理也就能在跨浏览器测试、缺陷复现与版本归档等场景中从数百个候选标签里准确挑出恰好满足需求的那一个。赞分享测试后端云原生容器编排可观测性【免费下载链接】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 4.48.0 版本 Chrome 145 镜像标签生成全解析从 tag_and_push_browser_images.sh 看版本矩阵与镜像标签体系docker selenium 4.48.0 版本 Chrome 145 镜像标签生成全解析从 tag_and_push_browser_images.sh测试后端云原生容器编排可观测性docker-selenium Edge 115 镜像发布标签全解析从 tag_and_push_browser_images.sh 到 Selenium Grid 4.29.0 版本矩阵docker selenium Edge 115 镜像发布标签全解析从 tag_and_push_browser_images.sh 到 Selenium G测试后端云原生容器编排可观测性docker-selenium 镜像版本发布实战解读 Chrome 111 版本矩阵 Changelog 与 tag_and_push_browser_images.shdocker selenium 镜像版本发布实战解读 Chrome 111 版本矩阵 Changelog 与 tag_and_push_browser_ima测试后端云原生容器编排可观测性上一篇10分钟从零到Terraform代码Terraformer安装与首次导入实战教程含4种安装方式下一篇KarakeepHoarder开发环境搭建全指南从 start-dev.sh 一键启动到 Web、移动端与浏览器扩展调试创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考