测试后端云原生容器编排可观测性【免费下载链接】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 101 镜像打标签日志为切入点逐行解读./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true这条命令背后的参数语义、版本探测机制与六类 Tag 的生成规则并结合 tag_and_push_browser_images.sh、Makefile 与 CHANGELOG/README.md 中的版本矩阵帮助你彻底理解 Selenium Grid 与浏览器版本组合镜像的发布管线掌握在真实测试环境中「按标签锁定浏览器 Driver Grid 版本组合」的实操能力。一、日志来源一次 Chrome 101 镜像的多标签发布本次发布的完整终端输出如下./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 - 101.0.4951.64 Short Chrome version - 101.0 ChromeDriver version - 101.0.4951.41 Short ChromeDriver version - 101.0 Tagged selenium/node-chrome:101.0.4951.64-chromedriver-101.0.4951.41-grid-4.48.0-20260909 Tagged selenium/standalone-chrome:101.0.4951.64-chromedriver-101.0.4951.41-grid-4.48.0-20260909 Tagged selenium/node-chrome:101.0.4951.64-chromedriver-101.0.4951.41-20260909 Tagged selenium/standalone-chrome:101.0.4951.64-chromedriver-101.0.4951.41-20260909 Tagged selenium/node-chrome:101.0.4951.64-20260909 Tagged selenium/standalone-chrome:101.0.4951.64-20260909 Tagged selenium/node-chrome:101.0-chromedriver-101.0-grid-4.48.0-20260909 Tagged selenium/standalone-chrome:101.0-chromedriver-101.0-grid-4.48.0-20260909 Tagged selenium/node-chrome:101.0-chromedriver-101.0-20260909 Tagged selenium/standalone-chrome:101.0-chromedriver-101.0-20260909 Tagged selenium/node-chrome:101.0-20260909 Tagged selenium/standalone-chrome:101.0-20260909这段日志本质上是一份**「发布记录」**它展示了在 Selenium Grid4.48.0发布版本中仓库如何为selenium/node-chrome与selenium/standalone-chrome两种镜像生成一组可追溯、可锁定的 Docker Tag。日志文件保存在 CHANGELOG/4.48.0/chrome_101.md对应的历史版本归档位于 CHANGELOG/archived/ 各版本目录下如4.47.0/chrome_101.md并且所有可用组合都汇总在 CHANGELOG/README.md 的「Grid Version × Browser Version」矩阵中。二、命令参数拆解七个位置参数的含义日志第一行调用的命令是./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true对照 tag_and_push_browser_images.sh 开头的参数解析位置参数日志中的值含义1VERSION4.48.0Selenium Grid 主版本号2BUILD_DATE20260909构建日期YYYYMMDD 格式3NAMESPACEselenium镜像命名空间仓库前缀4PUSH_IMAGEfalse是否执行docker push默认为false5BROWSERchrome浏览器类型chrome/chromium/edge/firefox/chrome-for-testing6RELEASE_OLD_VERSIONtrue是否为历史版本补发标签7PLATFORM未传默认linux/amd64运行容器探测版本时使用的平台脚本第 15–16 行会据此拼接出构建标签TAG_VERSION${VERSION}-${BUILD_DATE} NAMESPACE${NAME:-selenium}即TAG_VERSION4.48.0-20260909、NAMESPACEselenium这解释了日志中出现的所有grid-4.48.0-20260909片段。脚本第 88 行有一个关键分支当RELEASE_OLD_VERSION为true时本次日志即此情况跳过「仅含浏览器/Driver 版本、不含日期」的短标签如101.0.4951.64、101.0只生成带构建日期或 Grid 版本信息的完整标签。这是为了让历史浏览器版本的重发不影响当前主流标签的指向避免101.0这类短标签与新版 Chrome 镜像产生歧义。当前版本RELEASE_OLD_VERSIONfalse才会追加这些短标签。三、版本探测镜像内部的真实版本是如何读出来的脚本通过docker run临时启动已构建好的镜像读取内部浏览器与 Driver 的真实版本号而不是依赖外部参数硬编码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})对应日志输出Chrome version - 101.0.4951.64 ChromeDriver version - 101.0.4951.41随后short_version()函数脚本第 53–57 行将长版本截断为主版本.次版本function short_version() { local __long_version$1 local __version_split(${__long_version//./ }) echo ${__version_split[0]}.${__version_split[1]} }因此得到101.0.4951.64 → 101.0、101.0.4951.41 → 101.0对应日志中Short Chrome version - 101.0与Short ChromeDriver version - 101.0两行。这种「从镜像内部探测版本」的设计保证了标签与镜像内容的一致性——标签永远不会与内部实际安装的浏览器/Driver 版本脱节。而 NodeChrome/Dockerfile 也展示了版本信息在构建阶段就被固化到镜像中镜像内/opt/selenium/browsers/chrome/version文件由google-chrome --version | awk {print $3}生成与脚本探测所用命令一致。这也意味着该日志中的Chrome 101.0.4951.64是一个较旧的历史版本当前最新已到 152此日志正是仓库为满足用户「锁定旧浏览器版本」需求而保留的历史发布记录。四、标签体系六类 Tag 的完整生成逻辑脚本第 75–87 行定义了三组「完整标签」和三组「短标签」每组同时作用于node-chrome与standalone-chrome两个镜像CHROME_TAGS( # 完整版浏览器版本 Driver 版本 Grid 版本 构建日期 ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}-grid-${TAG_VERSION} # 完整版浏览器版本 Driver 版本 构建日期 ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}-${BUILD_DATE} # 完整版浏览器版本 构建日期 ${CHROME_VERSION}-${BUILD_DATE} # 短版主次版本 Driver 主次版本 Grid 版本 构建日期 ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}-grid-${TAG_VERSION} # 短版主次版本 Driver 主次版本 构建日期 ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}-${BUILD_DATE} # 短版主次版本 构建日期 ${CHROME_SHORT_VERSION}-${BUILD_DATE} )代入本次探测到的版本值后即得到日志中的 12 条Tagged输出。将这 6 类标签按信息粒度整理如下括号内为该类标签的适用场景标签模式本次实际值以 node-chrome 为例语义Browser-chromedriver-Driver-grid-Grid-Date101.0.4951.64-chromedriver-101.0.4951.41-grid-4.48.0-20260909信息最完整浏览器、Driver、Grid、构建日期全部锁定跨浏览器/跨 Grid 测试最安全Browser-chromedriver-Driver-Date101.0.4951.64-chromedriver-101.0.4951.41-20260909锁定浏览器 Driver 构建日期Grid 取镜像内固定版本Browser-Date101.0.4951.64-20260909锁定浏览器与构建日期Driver 为镜像内配套版本ShortBrowser-chromedriver-ShortDriver-grid-Grid-Date101.0-chromedriver-101.0-grid-4.48.0-20260909主次版本的简写版便于记忆与复用ShortBrowser-chromedriver-ShortDriver-Date101.0-chromedriver-101.0-20260909主次版本 日期ShortBrowser-Date101.0-20260909最简标签主次版本 日期日志第 9 行起先输出node-chrome的 6 个标签再输出standalone-chrome的 6 个标签正对应脚本第 101–104 行的循环for chrome_tag in ${CHROME_TAGS[]}; do retag node-chrome ${chrome_tag} retag standalone-chrome ${chrome_tag} done五、retag 函数标签打制与推送的两条路径脚本核心的retag()函数第 31–51 行根据发布模式走两条不同的路径function retag() { local __image$1 local __tag$2 local __source${NAMESPACE}/${__image}:${TAG_VERSION} if [ ${PROMOTE_TAGS} true ]; then # 路径一registry 到 registry 的 manifest 复制多架构安全 docker buildx imagetools create ${__targets[]} ${__source} ... return fi # 路径二本地 docker tag 可选 push docker tag ${__source} ${NAMESPACE}/${__image}:${__tag} echo Tagged ${NAMESPACE}/${__image}:${__tag} if [ ${PUSH_IMAGE} true ]; then docker push ${NAMESPACE}/${__image}:${__tag} fi }常规路径默认对本地镜像执行docker tag为node-chrome:4.48.0-20260909这一基础构建镜像逐一添加别名当PUSH_IMAGEtrue时再逐条docker push。本次日志PUSH_IMAGEfalse因此只打标签、不推送输出均为Tagged ...而非 push 日志。PROMOTE 路径当PROMOTE_TAGStrue由部署流程deploy.yml在「复用已测试镜像而非重新构建」时设置见脚本第 10–13 行注释时使用docker buildx imagetools create直接在镜像索引manifest index层面、registry 对 registry 地复制标签。这样能保持多架构 manifest的完整性——因为docker tag依赖本地镜像且docker pull只能拉取运行机架构会导致浏览器标签变成单架构而imagetools在索引层面操作可以规避这个问题。同时设置PROMOTE_GHCR_NAMESPACE可在同一次调用中把标签同步镜像到 GHCR 命名空间。六、发布管线中的位置Makefile 目标与 CI 集成这段打标签逻辑并非孤立脚本而是通过 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_chrome_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五种浏览器执行打标签参数VERSION、BUILD_DATE、NAMESPACE、PUSH_IMAGE、RELEASE_OLD_VERSION均由 Make 变量注入。脚本内部也为每种浏览器定义了独立的探测与标签逻辑浏览器分支版本探测命令Driver 版本命令短版本提取字段chromegoogle-chrome --version \| awk {print $3}chromedriver --version \| awk {print $2}前两段chromiumchromium --version \| awk {print $2}chromedriver --version \| awk {print $2}前两段edgemicrosoft-edge --version \| awk {print $3}msedgedriver --version \| awk {print $4}前两段firefoxfirefox --version \| awk {print $3}geckodriver --version \| awk NR1{print $2}前两段chrome-for-testinggoogle-chrome --version \| awk {print $5}chromedriver --version \| awk {print $2}前两段各分支均按照与 Chrome 相同的「完整版三组 短版三组」模式生成node-*与standalone-*两套镜像的标签如node-firefox、standalone-edge、node-chrome-for-testing等。若传入未识别的浏览器名脚本会输出Unknown browser!第 283 行。七、使用侧视角如何用这批标签锁定测试环境发布这些标签的最终目的是让使用者能够精确锁定浏览器、Driver 与 Grid 的组合。以本次 Chrome 101 为例可直接使用# 最完整的组合锁定推荐用于跨版本回归 docker run -d --net grid -e SE_EVENT_BUS_HOSTselenium-hub \ --shm-size2g \ selenium/node-chrome:101.0.4951.64-chromedriver-101.0.4951.41-grid-4.48.0-20260909 # 简写标签便于记忆 docker run -d --net grid -e SE_EVENT_BUS_HOSTselenium-hub \ --shm-size2g \ selenium/node-chrome:101.0-20260909从 docs/docker-hub/node-chrome.md 的标签约定说明可以看出这套命名规则与镜像文档中的browserVersion-browserDriver-browserDriverVersion-Major.Minor.Patch-YYYYMMDD结构完全对应。使用含grid-前缀的完整标签时可以确保测试不会因为 Grid 升级而意外改变运行行为这正是 CHANGELOG/README.md 中「提供最新 Grid 核心能力的同时允许用户固定浏览器版本」这一设计动机的直接体现。需要留意的是CHANGELOG/README.md 明确说明项目并未对每一种「Grid 版本 × 浏览器版本」组合做全量测试验证使用者需要根据自己的测试需求评估选择。Chrome 101 属于较早期的浏览器版本适合用于验证旧版本浏览器兼容性等场景。八、版本矩阵与历史归档本日志在仓库中的定位在 CHANGELOG/README.md 的「Latest Grid Version → Chrome」矩阵中4.48.0一行从 95 到 152 共 58 个 Chrome 版本均有对应的详细变更记录链接其中101列的链接即指向本文分析的 CHANGELOG/4.48.0/chrome_101.md。该矩阵同时列出 Chrome for Testing、Edge、Firefox 的对应矩阵且更早的 Grid 版本4.28.1 至 4.47.0的打标签记录归档在 CHANGELOG/archived/ 各版本目录下——例如archived/4.47.0/chrome_101.md记录的是该 Chrome 版本在 4.47.0 Grid 下打标签的完整过程。矩阵中的每个 ✓ 都是指向对应变更记录文档的链接用于快速定位某一浏览器版本在特定 Grid 版本下的发布细节。这些归档记录形成了一条完整的时间线同一浏览器版本在不同 Grid 版本下的标签命名模式保持一致仅TAG_VERSIONGrid 版本 构建日期不同这使得使用者可以在升级 Grid 的同时维持浏览器版本不变或将二者同时升级均能通过矩阵快速找到对应的镜像标签。九、小结一条命令产出的发布资产以./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true为例脚本完成的工作可以概括为解析 7 个位置参数确定版本、构建日期、命名空间、推送开关、浏览器类型、历史版本开关与平台探测镜像内部真实版本Chrome 101.0.4951.64 / ChromeDriver 101.0.4951.41并截取主次版本生成 6 类标签同时作用于node-chrome与standalone-chrome通过retag()打制标签常规模式走docker tagPUSH_IMAGEtrue时附带docker push发布推广模式走docker buildx imagetools create保持多架构完整性输出Tagged ...记录作为发布证据沉淀到 CHANGELOG/4.48.0/chrome_101.md并在 CHANGELOG/README.md 矩阵中登记。理解这一流程后你在任何需要「固定浏览器版本跑测试」的场景中都能从仓库的 CHANGELOG 矩阵出发逆推出应该拉取的镜像标签——这正是 docker-selenium 项目将「最新 Grid 任意浏览器版本」组合能力交付给使用者的核心机制。赞分享测试后端云原生容器编排可观测性【免费下载链接】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点击查看免费下载相关推荐RePKG深度解析如何通过逆向工程解锁Wallpaper Engine资源格式RePKG深度解析如何通过逆向工程解锁Wallpaper Engine资源格式 RePKG是一个完全使用C 开发的开源工具专门用于提取Wallpaper E测试后端云原生容器编排可观测性simplebank 前端实战基于 Vue 3 Vite 的登录界面开发与工程化配置指南simplebank 前端实战基于 Vue 3 Vite 的登录界面开发与工程化配置指南 导读 本文以 simplebank 项目 frontend/RE测试后端云原生容器编排可观测性在 Linux 上安装与运行 TiXL实时动态图形工具基于 Wine 与 Bottles 的完整指南在 Linux 上安装与运行 TiXL实时动态图形工具基于 Wine 与 Bottles 的完整指南 TiXL原 Tooll3是一款开源的实时动态图形测试后端云原生容器编排可观测性上一篇KubeOS配置管理终极教程统一管理内核参数、Kubelet和containerd下一篇cu-scanner数据库设计如何高效存储和管理OVAL定义创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考