测试后端云原生容器编排可观测性【免费下载链接】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 归档中的chrome_112.md发布记录为线索完整解析tag_and_push_browser_images.sh脚本的标签生成机制、Chrome 112 与 ChromeDriver 112 的版本探测流程以及node-chrome/standalone-chrome系列镜像的 6 级标签命名规范。读完本文你将能独立读懂仓库中任意一条浏览器镜像变更记录并掌握自建或复刻这套浏览器镜像标签发布流程的完整方法。一、这条变更记录在讲什么在 CHANGELOG/archived/4.29.0/ 目录下保存着 docker-selenium 历史上每个 Selenium Grid 版本的浏览器版本变更记录。本文分析的 chrome_112.md 属于 4.29.0 版本的归档记录它的全部内容是一次tag_and_push_browser_images.sh脚本的真实运行输出./tag_and_push_browser_images.sh 4.29.0 20250303 selenium false chrome true Tagging images for browser chrome, version 4.29.0, build date 20250303, namespace selenium Selenium Grid version - 4.29.0-20250303 Chrome version - 112.0.5615.165 Short Chrome version - 112.0 ChromeDriver version - 112.0.5615.49 Short ChromeDriver version - 112.0 Tagged selenium/node-chrome:112.0.5615.165-chromedriver-112.0.5615.49-grid-4.29.0-20250303 Tagged selenium/standalone-chrome:112.0.5615.165-chromedriver-112.0.5615.49-grid-4.29.0-20250303 Tagged selenium/node-chrome:112.0.5615.165-chromedriver-112.0.5615.49-20250303 Tagged selenium/standalone-chrome:112.0.5615.165-chromedriver-112.0.5615.49-20250303 Tagged selenium/node-chrome:112.0.5615.165-20250303 Tagged selenium/standalone-chrome:112.0.5615.165-20250303 Tagged selenium/node-chrome:112.0-chromedriver-112.0-grid-4.29.0-20250303 Tagged selenium/standalone-chrome:112.0-chromedriver-112.0-grid-4.29.0-20250303 Tagged selenium/node-chrome:112.0-chromedriver-112.0-20250303 Tagged selenium/standalone-chrome:112.0-chromedriver-112.0-20250303 Tagged selenium/node-chrome:112.0-20250303 Tagged selenium/standalone-chrome:112.0-20250303这段输出表面上是 12 行 Tagged 日志实质上浓缩了 docker-selenium 浏览器镜像发布的核心机制一次发布命令同时为node-chrome与standalone-chrome两类镜像生成 6 组不同粒度的标签既保留完整版本号的精确标识又提供短版本号的稳定入口。值得注意的是同一条 Chrome 112 记录至今仍保留在最新版本目录中例如 CHANGELOG/4.48.0/chrome_112.md 记录了以 4.48.0-20260909 构建日期重新打标签的过程——这说明 Chrome 112 这类旧版本浏览器在 docker-selenium 中作为长期可用镜像持续维护这也是理解该仓库镜像策略的关键点。二、命令调用与参数语义变更记录第一行给出了完整的调用方式./tag_and_push_browser_images.sh 4.29.0 20250303 selenium false chrome true对照 tag_and_push_browser_images.sh 的开头定义这 7 个位置参数依次为位置参数变量本次取值含义1VERSION4.29.0Selenium Grid 版本号2BUILD_DATE20250303构建日期YYYYMMDD3NAMESPACEseleniumDocker 镜像命名空间4PUSH_IMAGEfalse是否执行docker push默认 false仅本地打标签5BROWSERchrome浏览器类型chrome / chromium / edge / firefox / chrome-for-testing6RELEASE_OLD_VERSIONtrue是否为历史版本追加纯版本号标签7PLATFORM未传目标平台默认linux/amd64脚本先将VERSION与BUILD_DATE组合成完整发布标签TAG_VERSION4.29.0-20250303即Grid 版本-构建日期后续所有 Grid 相关标签都以此为基础。BROWSER参数通过case分支决定处理流程仓库当前支持五种浏览器tag_and_push_browser_images.shchrome、chromium、edge、firefox、chrome-for-testing。每种浏览器的标签生成逻辑结构一致仅版本提取命令和镜像名不同因此读懂 chrome 分支即可举一反三。三、标签命名体系6 组标签的完整拆解脚本在确定版本后会构造一个标签数组CHROME_TAGStag_and_push_browser_images.sh并按数组中定义的顺序对每个镜像执行打标签操作。以本次记录为例标签可以分为两大类共 6 组第一类带构建日期/Grid 版本的标签始终生成标签形式本次实际值用途浏览器全版本-chromedriver全版本-grid-完整发布号112.0.5615.165-chromedriver-112.0.5615.49-grid-4.29.0-20250303最精确同时锁定浏览器、驱动、Grid 与构建日期浏览器全版本-chromedriver全版本-构建日期112.0.5615.165-chromedriver-112.0.5615.49-20250303锁定浏览器与驱动的完整版本及构建日期浏览器全版本-构建日期112.0.5615.165-20250303锁定浏览器完整版本与构建日期第二类短版本标签始终生成标签形式本次实际值用途短浏览器版本-chromedriver短版本-grid-完整发布号112.0-chromedriver-112.0-grid-4.29.0-20250303短版本 Grid 发布号短浏览器版本-chromedriver短版本-构建日期112.0-chromedriver-112.0-20250303短版本 构建日期短浏览器版本-构建日期112.0-20250303短版本 构建日期第三类纯版本标签仅RELEASE_OLD_VERSIONfalse时生成当第六个参数为false即当前版本首次发布时还会追加 4 个无日期、无 Grid 版本的稳定标签112.0.5615.165-chromedriver-112.0.5615.49112.0.5615.165112.0-chromedriver-112.0112.0这些标签不带构建日期是用户最容易直接拉取的稳定入口。而本次记录中第六个参数是trueRELEASE_OLD_VERSIONtrue代表 Chrome 112 属于历史归档版本因此只补充带日期的标签不覆盖纯版本标签避免与当时主流版本产生歧义。短版本号的生成规则所谓短版本由脚本中的short_version函数计算tag_and_push_browser_images.shfunction short_version() { local __long_version$1 local __version_split(${__long_version//./ }) echo ${__version_split[0]}.${__version_split[1]} }即取完整版本号以.分割后的前两段112.0.5615.165→112.0112.0.5615.49→112.0。这也是变更记录中 Short Chrome version - 112.0 的来源。标签的应用对象标签循环tag_and_push_browser_images.sh对每个标签同时应用到两个镜像for chrome_tag in ${CHROME_TAGS[]}; do retag node-chrome ${chrome_tag} retag standalone-chrome ${chrome_tag} done这解释了为什么变更记录中每个标签都会出现两次node-chrome与standalone-chrome各一次。其中node-chrome是 Grid 节点镜像通过NodeBase/基础镜像构建standalone-chrome则是在 Standalone/Dockerfile 中以BASEnode-chrome为基底构建的单机镜像两者共享同一套浏览器与驱动。四、版本探测一次发布如何拿到真实版本号变更记录中的版本号Chrome112.0.5615.165、ChromeDriver112.0.5615.49并非手写而是脚本启动后从已构建好的镜像内实时探测得到的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})工作流是先用构建日期标签selenium/node-chrome:4.29.0-20250303临时启动容器--rm用完即删--platform指定目标架构在容器内执行google-chrome --version用awk {print $3}提取第三个字段得到 Chrome 版本执行chromedriver --version用awk {print $2}提取第二个字段得到 ChromeDriver 版本各自调用short_version得出短版本然后拼接标签数组。这套先构建、再探测、后打标签的流程保证了标签上的版本号与镜像内二进制永远一致杜绝了手写版本号与真实安装版本错位的风险。五、Chrome 112 镜像的构建底层安装脚本如何决定版本标签上的版本号最终由 NodeChrome/Dockerfile 的构建产物决定。该 Dockerfile 的关键参数CHROME_VERSION默认google-chrome-stable控制 Chrome 的安装通道或具体版本INSTALL_CFT/CFT_VERSION默认false/STABLE是否走 Chrome for Testing 分支CHROME_DRIVER_VERSIONChromeDriver 版本留空则自动探测。默认走 install-chrome.sh 从 Google apt 仓库安装 Chrome。该脚本支持两种安装模式install-chrome.sh若CHROME_VERSION形如google-chrome-stable121.0.6167.120-1则解析出版本号下载对应版本的.deb包并--allow-downgrades安装实现固定历史版本否则按通道名stable / beta / unstable直接apt-get install。ChromeDriver 的安装由 install-chromedriver.sh 完成其中对Chrome 112 有一个专门的历史分支install-chromedriver.shChrome 115 之前的版本早于 Chrome for TestingCfT项目Google 只通过旧的chromedriver.storage.googleapis.comAPI 提供linux64构建因此脚本对major 115的 amd64 架构直接走legacy来源if [ ${ARCH} amd64 ] [ -n ${CHROME_MAJOR_VERSION} ] [ ${CHROME_MAJOR_VERSION} -lt 115 ]; then DRIVER_SOURCElegacy DRIVER_ARCHlinux64 ... CHROME_DRIVER_VERSION$(wget -qO- https://chromedriver.storage.googleapis.com/LATEST_RELEASE_${CHROME_MAJOR_VERSION} ...) CHROME_DRIVER_URLhttps://chromedriver.storage.googleapis.com/$CHROME_DRIVER_VERSION/chromedriver_linux64.zip也就是说112.0.5615.49这个 ChromeDriver 版本正是通过LATEST_RELEASE_112接口查询得到的该主版本线的最新驱动。而 115 及以上版本则改由 resolve-chromedriver-source.sh 决定来源优先从 Chrome for Testing 官方存储桶拉取与 Chrome 锁步的驱动arm64 等架构在 CfT 未提供构建时回退到 Debianchromium-driver包。这套新旧双轨制正是仓库能同时维护 Chrome 95~152 众多历史镜像的技术基础。镜像构建完成后NodeChrome/Dockerfile 还会把浏览器名、版本号、binary 位置写入/opt/selenium/browsers/chrome/供 Selenium Grid 的 Node 配置NodeBase/generate_config自动生成 capabilities 使用。六、retag 与发布升级标签如何落地脚本中真正执行打标签动作的是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} echo Tagged ${NAMESPACE}/${__image}:${__tag} if [ ${PUSH_IMAGE} true ]; then docker push ${NAMESPACE}/${__image}:${__tag} fi }其逻辑是以TAG_VERSION如4.29.0-20250303作为源标签为镜像创建别名标签。变更记录中每次 Tagged 输出即来自此处的echo。当第 4 个参数PUSH_IMAGE为true时每个别名都会同步docker push到仓库为false时仅在本地打标签这正是变更记录所示场景用于发布前验证标签体系。函数还保留了PROMOTE_TAGS与PROMOTE_GHCR_NAMESPACE两个发布专用开关tag_and_push_browser_images.sh当发布流程直接复用测试过的镜像而非重新构建时改用docker buildx imagetools create在 registry 之间做多架构 manifest 别名并可同时镜像到 GHCR 命名空间。这套流程与 Makefile 深度集成make 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五个目标每个目标都以$(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE)加浏览器名调用本脚本。此外 Makefile 中的tag_and_push_browser_images_ghcr目标会把本地所有浏览器标签通过docker buildx imagetools create同步到 GHCR 命名空间。七、变更记录如何被校验与消费CHANGELOG 中的每一条记录并非只给人看还被自动化测试直接消费。仓库中的 tests/dockerhub_description/test_resolve_versions.py 以chrome_152.md等记录作为测试样本验证解析逻辑test_picks_the_highest_version_not_the_alphabetical_one版本目录按数值而非字典序选取4.10.0正确排在4.9.0之后test_ignores_non_release_directoriesarchived目录会被忽略——这印证了本文分析的archived/4.29.0/属于历史归档而CHANGELOG/4.48.0/才是当前生效版本目录test_prefers_the_short_version_over_the_full_one从记录中提取的浏览器版本优先使用112.0这样的短版本从 Short Chrome version - 112.0 行读取而非完整版本号test_chrome_prefix_does_not_match_chrome_for_testingchrome_*.md前缀不会误匹配chrome-for-testing_*.md。这些测试说明记录中的每行输出如 Selenium Grid version - 4.29.0-20250303都是被解析器依赖的机器可读字段解析结果用于自动生成 Docker Hub 上的镜像版本说明文档。这解释了为什么每条记录都保持高度统一的格式。八、实战如何拉取与使用这些标签理解了标签体系后实际使用非常直接。以本次记录为例发布完成后可用的镜像入口包括# 精确锁定浏览器/驱动/Grid 完整版本 docker pull selenium/node-chrome:112.0.5615.165-chromedriver-112.0.5615.49-grid-4.29.0-20250303 # 仅按短版本 构建日期拉取 docker pull selenium/standalone-chrome:112.0-20250303 # 通过 docker-compose 使用见仓库根目录的 docker-compose-v3-*.yml 系列 # 将 image 字段替换为上述标签之一即可选择建议追求可复现性、需要锁定回归现场时用浏览器全版本-驱动全版本-grid-发布号的最长标签日常使用想跟随某次构建的修复用短版本-构建日期标签在 Selenium Grid 拓扑docker-compose-v3.yml中运行应使用node-chrome系列单机直连则用standalone-chrome系列。若需确认镜像内版本与标签一致可以执行与脚本相同的探测命令docker run --rm selenium/node-chrome:112.0-20250303 google-chrome --version docker run --rm selenium/node-chrome:112.0-20250303 chromedriver --version九、总结一条变更记录背后的完整链路回看 chrome_112.md 这份 21 行的记录它实际上是 docker-selenium 浏览器镜像发布流水线的运行日志快照背后串起了构建层NodeChrome/Dockerfile 通过 install-chrome.sh 与 install-chromedriver.sh 安装指定版本的 Chrome 与 ChromeDriver115 以下走 legacy 驱动 API、115 以上走 Chrome for Testing探测层tag_and_push_browser_images.sh 启动镜像实例实时读取版本号并计算短版本打标签层retag函数以TAG_VERSION为源为node-chrome与standalone-chrome各生成 6 组历史版本或 10 组当前版本别名标签校验层tests/dockerhub_description/test_resolve_versions.py 与 Makefile 保证记录格式可被自动化解析、发布流程可一键复用。这套一个命令、两类镜像、多级标签的设计让 docker-selenium 得以在保持浏览器版本高度可复现的同时为使用者提供从精确锁定到快速拉取的全梯度标签入口。若你想继续深入可以从 CHANGELOG/4.48.0/ 下对比chrome_112.md与chrome_152.md的差异观察短版本与驱动版本如何随 Chrome 主版本线演进也可以对照 ENV_VARIABLES.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 浏览器镜像标签体系详解从 Chrome 123 发布记录读懂 tag_and_push_browser_images.shdocker selenium 浏览器镜像标签体系详解从 Chrome 123 发布记录读懂 tag_and_push_browser_images.sh 本测试后端云原生容器编排可观测性docker-selenium 镜像标签生成指南解读 tag_and_push_browser_images.sh 与 Chrome 112 发布记录docker selenium 镜像标签生成指南解读 tag_and_push_browser_images.sh 与 Chrome 112 发布记录 本篇技测试后端云原生容器编排可观测性docker-selenium 浏览器镜像的多标签发布机制从 Chrome 111 的发布记录看 Selenium Grid 镜像版本体系docker selenium 浏览器镜像的多标签发布机制从 Chrome 111 的发布记录看 Selenium Grid 镜像版本体系 本文以 docke测试后端云原生容器编排可观测性上一篇Browsh 项目使用教程下一篇推荐开源项目Docker Github Actions Runner创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考