测试后端云原生容器编排可观测性【免费下载链接】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 项目中每一轮浏览器版本发布都会执行tag_and_push_browser_images.sh脚本为node-chrome与standalone-chrome等镜像批量打上可读性极强的语义化标签。本文以 CHANGELOG/4.48.0/chrome_117.md 中记录的 Chrome 117 发布日志为骨架结合仓库内 tag_and_push_browser_images.sh 的完整实现深入讲解标签的命名规范、版本探测逻辑、短版本截断规则以及 Makefile 的集成方式。读完本文你将能够读懂任意一条浏览器镜像标签的含义并能在自己的 Selenium Grid 集群中精准拉取指定 Chrome/ChromeDriver 组合的镜像。一、一次发布日志背后的完整命令chrome_117.md记录的是发布 Chrome 117 镜像时脚本的完整输出其起始命令为./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true对照脚本开头的参数解析tag_and_push_browser_images.sh这 7 个位置参数分别表示参数值含义$1VERSION4.48.0Selenium Grid 版本号$2BUILD_DATE20260909镜像构建日期YYYYMMDD$3NAMESPACEselenium镜像命名空间镜像仓库前缀$4PUSH_IMAGEfalse是否在打标签后立即 push 到仓库true/false$5BROWSERchrome目标浏览器类型$6RELEASE_OLD_VERSIONtrue是否为旧版本发布true时不追加纯净版本标签$7PLATFORM默认探测版本时使用的平台默认linux/amd64脚本运行时首先生成基准标签TAG_VERSION${VERSION}-${BUILD_DATE}即4.48.0-20260909——这也是 CI 构建阶段给所有 Grid 组件镜像base、hub、node-chrome 等打的统一标签。随后脚本启动node-chrome:4.48.0-20260909容器读取内部浏览器与驱动版本Chrome 版本117.0.5938.149ChromeDriver 版本117.0.5938.149日志中第三行起依次输出Selenium Grid version - 4.48.0-20260909、Chrome version - 117.0.5938.149、Short Chrome version - 117.0等完整还原了后续打标签所需的全部版本信息。二、十组镜像标签的命名规范深度拆解日志第 920 行展示了为 Chrome 117 生成的全部 10 个标签node-chrome与standalone-chrome各一组共 20 条 Tagged 记录。将其去重归类标签体系由三类信息组合而成1. 长版本 驱动版本 Grid 版本定位最精确selenium/node-chrome:117.0.5938.149-chromedriver-117.0.5938.149-grid-4.48.0-20260909这是信息最完整的标签浏览器完整版本、ChromeDriver 完整版本、Grid 完整版本含构建日期三要素齐全适合需要锁定到某个具体补丁版本的回归测试场景。2. 长版本 驱动版本 构建日期selenium/node-chrome:117.0.5938.149-chromedriver-117.0.5938.149-20260909浏览器与驱动版本一致Chrome 与 ChromeDriver 通常同源同版本再辅以构建日期区分同版本多批次构建。3. 浏览器版本 构建日期selenium/node-chrome:117.0.5938.149-20260909只关心浏览器主版本驱动跟随镜像内部默认。4. 短版本变体117.0系列selenium/node-chrome:117.0-chromedriver-117.0-grid-4.48.0-20260909 selenium/node-chrome:117.0-chromedriver-117.0-20260909 selenium/node-chrome:117.0-20260909这是short_version()函数的作用。从源码看tag_and_push_browser_images.sh它把完整版本号按.切分后仅保留前两段function short_version() { local __long_version$1 local __version_split(${__long_version//./ }) echo ${__version_split[0]}.${__version_split[1]} }117.0.5938.149→117.0。短版本标签适合粗粒度锁定大版本号例如只想固定 117 主线的场景在跨大版本兼容性排查时非常实用。5. 纯净版本标签仅在非旧版本发布时追加日志中的第 920 行没有出现这类标签原因是本次调用第 6 个参数为trueRELEASE_OLD_VERSIONtrue。当该参数为false时脚本会额外追加 4 个不含日期、不含 Grid 版本的最简标签tag_and_push_browser_images.sh117.0.5938.149-chromedriver-117.0.5938.149 117.0.5938.149 117.0-chromedriver-117.0 117.0RELEASE_OLD_VERSIONtrue的含义是本次发布的是历史旧版浏览器如为兼容遗留测试环境而补发的 Chrome 117为避免selenium/node-chrome:117.0这类无日期标签与未来再次发布同版本时产生歧义故不再追加纯净标签。三、源码级原理版本探测与标签组装版本探测是打标签流程的前置步骤。以 Chrome 为例tag_and_push_browser_images.shCHROME_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})这里有两个值得注意的实现细节平台参数Chrome 分支的docker run显式携带--platform ${PLATFORM}默认linux/amd64保证跨架构环境下探测到的版本准确字段截取google-chrome --version输出形如Google Chrome 117.0.5938.149取第 3 列即版本号chromedriver --version输出形如ChromeDriver 117.0.5938.149...取第 2 列。标签组装通过CHROME_TAGS数组完成tag_and_push_browser_images.sh数组中 6 个RELEASE_OLD_VERSIONfalse 时为 10 个模板依次展开。实际打标签由retag()函数统一处理tag_and_push_browser_images.shfunction retag() { local __image$1 local __tag$2 local __source${NAMESPACE}/${__image}:${TAG_VERSION} docker tag ${__source} ${NAMESPACE}/${__image}:${__tag} if [ ${PUSH_IMAGE} true ]; then docker push ${NAMESPACE}/${__image}:${__tag} fi }即先对selenium/node-chrome:4.48.0-20260909打本地标签再按PUSH_IMAGE决定是否推送。日志中 PUSH_IMAGEfalse因此 20 条输出均为本地 Tagged 记录没有 Push 记录。retag()还支持一种PROMOTE_TAGStrue的发布路径当发布采用promote晋升策略时直接用docker buildx imagetools create在 registry 与 registry 之间复制 manifest避免在本地重建镜像——这正是 Makefile 中promote_release_images目标Makefile所描述发布的 digest 就是被测试过的 digest的核心思想。四、Makefile 集成一条命令驱动全部浏览器发布tag_and_push_browser_images.sh的调用被封装在 Makefile 的tag_and_push_browser_images目标中Makefiletag_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)Makefile 顶层定义了VERSION4.49.0、BUILD_DATE$(CURRENT_DATE)、NAMESPACE$(NAME)、PUSH_IMAGEfalse、RELEASE_OLD_VERSIONfalse等变量Makefile可直接通过环境变量或命令行覆盖例如make tag_and_push_browser_images VERSION4.48.0 BUILD_DATE20260909 PUSH_IMAGEtrue这意味着 5 种浏览器变体chrome、chrome-for-testing、chromium、edge、firefox共用同一套打标签逻辑仅版本探测命令与标签后缀不同。以同批发布的 edge_117.md 和 firefox_117.md 为例浏览器版本探测命令输出标签后缀Chromegoogle-chrome --version取第 3 列-chromedriver-Chrome for Testinggoogle-chrome --version取第 5 列-chromedriver-Edgemicrosoft-edge --version取第 3 列-edgedriver-Firefoxfirefox --version取第 3 列、geckodriver --version取首行第 2 列-geckodriver-日志显示 Edge 117 实际版本为117.0.2045.55Firefox 为117.0.1配套 geckodriver0.37.1Chrome 为117.0.5938.149——三者主版本号均为 117但完整补丁版本各不相同恰好说明为什么标签中必须携带完整版本号才能做到精确区分。五、为什么需要Grid 版本 浏览器版本双维度标签CHANGELOG/README.md 的版本矩阵文档明确阐述了设计动机CHANGELOG/README.md项目既要持续跟进最新的 Selenium Grid 核心版本又要让用户能够把浏览器版本固定在自己需要的版本上例如某些浏览器版本存在已知问题、或团队环境只支持特定版本时。因此每个浏览器镜像都同时打包了 Grid 核心、驱动与浏览器用户只需在矩阵表CHANGELOG/4.48.0目录下的chrome_*.md系列文件中找到 Grid 版本与浏览器版本的交叉点按标签命名规则拼出镜像标签直接docker pull并启动测试。同时该文档也给出了一个重要提醒CHANGELOG/README.md项目并未对每种 Grid 与浏览器版本的组合做全量兼容性测试用户需要根据自己的测试需求评估选择。六、实战如何在测试中选用 Chrome 117 镜像在docker-compose-v3.yml或 Selenium Grid Hub Node 部署中直接修改镜像标签即可固定浏览器版本。例如固定使用 Chrome 117 ChromeDriver 117 Grid 4.48.0 的完整组合services: chrome: image: selenium/node-chrome:117.0.5938.149-chromedriver-117.0.5938.149-grid-4.48.0-20260909 shm_size: 2gb depends_on: - selenium-hub environment: - SE_EVENT_BUS_HOSTselenium-hub - SE_EVENT_BUS_PUBLISH_PORT4442 - SE_EVENT_BUS_SUBSCRIBE_PORT4443若只需单容器快速验证可直接使用 Standalone 变体docker run -d -p 4444:4444 --shm-size2g \ selenium/standalone-chrome:117.0.5938.149-20260909标签选择建议需要精确复现某次测试环境 → 使用三要素完整标签含-grid-段需要固定主版本、容忍补丁差异→ 使用短版本标签117.0-20260909需要跟随 Grid 升级但锁定浏览器→ 换用新版 Grid 的chrome_117.md对应的标签。七、镜像内的版本来源构建期安装逻辑浏览器与驱动版本最终由镜像构建阶段决定。NodeChrome/Dockerfile通过CHROME_VERSION与CHROME_DRIVER_VERSION两个构建参数控制NodeChrome/Dockerfileinstall-chrome.sh默认安装google-chrome-stable渠道也支持google-chrome-stable版本号形式精确指定 apt 版本install-chromedriver.sh默认根据已装 Chrome 的主版本号自动解析匹配的 ChromeDriver——115 以前的版本走chromedriver.storage.googleapis.com遗留接口115 及以后从 Chrome for Testing 公共存储桶下载非 amd64 架构则回退到 Debianchromium-driver包。这也解释了为什么日志中 Chrome 与 ChromeDriver 版本完全一致均为117.0.5938.149驱动版本默认跟随浏览器主版本自动匹配只有显式传入CHROME_DRIVER_VERSION时才会出现两者版本不同的镜像。构建时探测逻辑google-chrome --version | awk {print $3}与打标签脚本中的探测命令保持了一致性确保镜像内版本与标签语义严格对应。结语一条chrome_117.md发布日志完整呈现了 docker-selenium 的浏览器镜像版本管理哲学以Grid 版本-构建日期为基准以浏览器完整版本 驱动版本为语义通过长短版本两组标签为不同精度需求的使用者提供选择。理解这套标签体系后无论是排查环境差异、复现线上问题还是搭建跨版本兼容矩阵你都能快速定位到正确的镜像。若需深入可直接阅读 tag_and_push_browser_images.sh 源码或对照 CHANGELOG/README.md 的完整版本矩阵规划自己的浏览器版本策略。赞分享测试后端云原生容器编排可观测性【免费下载链接】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 104 发布记录为例docker selenium 浏览器镜像多重标签发布机制解析——以 Selenium Grid 4.48.0 Chrome 104 发布记录为例 本文以仓库中测试后端云原生容器编排可观测性docker-selenium 浏览器镜像版本标签全解析以 Selenium Grid 4.48.0 与 Chrome for Testing 115 为例docker selenium 浏览器镜像版本标签全解析以 Selenium Grid 4.48.0 与 Chrome for Testing 115 为例测试后端云原生容器编排可观测性docker-selenium 浏览器镜像标签体系全解析以 Selenium Grid 4.48.0 与 Chrome 102 版本组合为例docker selenium 浏览器镜像标签体系全解析以 Selenium Grid 4.48.0 与 Chrome 102 版本组合为例 在 docker测试后端云原生容器编排可观测性上一篇跟踪一次git commit在Git源码里走过的路从命令行到函数指针的命令分发全路径下一篇uBlockOrigin-HUGE-AI-Blocklist技术债务清理重构列表格式提升可维护性创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考