测试后端云原生容器编排可观测性【免费下载链接】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.32.0/chrome_105.md展开完整剖析其背后的自动化脚本 tag_and_push_browser_images.sh 如何为一个浏览器版本批量生成并打上十余个语义化 Docker 标签。读者读完本文后将理解 docker-selenium 版本矩阵的生成原理、Chrome 与 ChromeDriver 版本的自动探测方式、标签命名约定的每种组合含义以及如何根据这些标签精确拉取自己所需的 Selenium Grid 镜像。一次发布记录里藏着什么关联文档 CHANGELOG/archived/4.32.0/chrome_105.md 的全文是tag_and_push_browser_images.sh的一次真实执行输出。表面上看它只是一段命令日志实际上它完整记录了 docker-selenium 项目发布某个浏览器版本时的全部动作调用脚本、传入参数、探测浏览器版本、计算短版本号、为node-chrome与standalone-chrome两个镜像各打上 10 个标签。还原这次发布的关键信息如下./tag_and_push_browser_images.sh 4.32.0 20250515 selenium false chrome true对应版本组合维度值Selenium Grid 版本4.32.0-20250515Chrome 版本105.0.5195.125Chrome 短版本105.0ChromeDriver 版本105.0.5195.52ChromeDriver 短版本105.0脚本参数一条命令如何驱动整个发布流程从 tag_and_push_browser_images.sh 的源码可以看到脚本共支持 7 个位置参数VERSION$1 # Grid 主版本如 4.32.0 BUILD_DATE$2 # 构建日期如 20250515 NAMESPACE$3 # 镜像命名空间如 selenium PUSH_IMAGE${4:-false} # 是否推送镜像到仓库默认 false BROWSER$5 # 浏览器类型chrome / chromium / edge / firefox / chrome-for-testing RELEASE_OLD_VERSION${6:-false} # 是否为旧版本补打标签默认 false PLATFORM${7:-linux/amd64} # 探测版本时使用的平台默认 linux/amd64其中两个关键行为值得注意PUSH_IMAGE控制是否调用docker push。记录中的调用传入了false第 4 个参数因此只执行本地docker tag不打推送适合作为发布前的验证步骤。RELEASE_OLD_VERSION决定是否补打仅含浏览器版本的标签如105.0.5195.125、105.0。结合 Makefile 中的发布流程可以推断新版本发布时该参数为false会打全 10 个标签而为旧浏览器版本补发标签时设为true只打 6 个含 Grid 版本或日期的标签避免覆盖当前浏览器主版本对应的最新标签。脚本开头的TAG_VERSION${VERSION}-${BUILD_DATE}将 Grid 版本与构建日期拼接为形如4.32.0-20250515的基础版本串后续所有标签都以此为根。版本自动探测从镜像里读出真实版本号脚本不会硬编码版本号而是通过临时运行已经构建好的 Node 镜像来探测浏览器与驱动版本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})docker run --rm临时拉起node-chrome:4.32.0-20250515执行google-chrome --version与chromedriver --version再用awk提取版本号字段。这样既验证了镜像可运行又保证了标签与镜像内实际二进制版本严格一致杜绝人工维护版本号造成的漂移。随后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]} }因此105.0.5195.125得到105.0105.0.5195.52得到105.0。短版本标签的价值在于当 Chrome 105 发布补丁版本时短标签105.0无需改动即可指向该系列的最新构建方便使用者锁定主版本又自动跟进补丁。十种标签的生成规则脚本为每个浏览器版本维护一个标签数组tag_and_push_browser_images.sh由 Chrome 长/短版本、ChromeDriver 长/短版本、Grid 版本串、构建日期四类信息组合而成序号标签模式示例node-chrome语义1Chrome-chromedriver-Driver-grid-TAG105.0.5195.125-chromedriver-105.0.5195.52-grid-4.32.0-20250515完全锁定浏览器驱动Grid日期2Chrome-chromedriver-Driver-DATE105.0.5195.125-chromedriver-105.0.5195.52-20250515浏览器驱动日期3Chrome-DATE105.0.5195.125-20250515浏览器日期4ShortChrome-chromedriver-ShortDriver-grid-TAG105.0-chromedriver-105.0-grid-4.32.0-20250515短版本完全锁定5ShortChrome-chromedriver-ShortDriver-DATE105.0-chromedriver-105.0-20250515短版本浏览器驱动日期6ShortChrome-DATE105.0-20250515短版本浏览器日期7Chrome-chromedriver-Driver105.0.5195.125-chromedriver-105.0.5195.52浏览器驱动滚动更新8Chrome105.0.5195.125精确浏览器版本滚动更新9ShortChrome-chromedriver-ShortDriver105.0-chromedriver-105.0短版本浏览器驱动10ShortChrome105.0短版本浏览器其中 710 仅在RELEASE_OLD_VERSIONfalse时追加。记录输出中node-chrome与standalone-chrome各出现 10 行Tagged正是两套镜像分别套用同一标签集合的结果与脚本尾部retag node-chrome ${chrome_tag}; retag standalone-chrome ${chrome_tag}的循环逻辑完全对应tag_and_push_browser_images.sh。底层打标与发布docker tag 到 buildx imagetools脚本核心的retag函数tag_and_push_browser_images.sh有两条路径常规路径docker tag本地打标若PUSH_IMAGEtrue则追加docker push。提升路径PROMOTE_TAGStrue改用docker buildx imagetools create直接在 registry 之间创建清单索引标签。脚本注释解释了原因docker tag需要镜像在本地且docker pull只能拉回 runner 单一架构无法表达多架构清单而imagetools在 index 层面操作可从 registry 到 registry 保留多架构属性。这与 Makefile 中 release 阶段的PROMOTE_NAMESPACE提升流程形成配套。发布阶段的完整链条是CI 构建出NAMESPACE/镜像:TAG_VERSION如selenium/node-chrome:4.32.0-20250515→ 脚本探测版本 → 生成标签数组 → 对 node/standalone 镜像逐一打标 → 可选推送。CHANGELOG 中记录的4.32.0 20250515 selenium false chrome true调用即对应这条链路中的浏览器镜像打标环节。同构设计四种浏览器共用一套发布脚本脚本的case ${BROWSER}分支tag_and_push_browser_images.sh为chrome、chromium、edge、firefox、chrome-for-testing五种浏览器实现了完全对称的逻辑仅版本探测命令不同浏览器浏览器探测命令驱动探测命令chromegoogle-chrome --version字段 3chromedriver --version字段 2chromiumchromium --version字段 2chromedriver --version字段 2edgemicrosoft-edge --version字段 3msedgedriver --version字段 4firefoxfirefox --version字段 3geckodriver --version首行字段 2chrome-for-testinggoogle-chrome --version字段 5chromedriver --version字段 2正因为脚本与浏览器类型解耦CHANGELOG/README.md 才能生成 Chrome、Chrome for Testing、Edge、Firefox 四个维度、横跨数十个浏览器版本的矩阵表。该矩阵的动机在文档中写得很清楚在持续提供最新 Selenium Grid 核心版本的同时让用户能够锁定特定浏览器版本进行跨浏览器测试或规避特定版本的兼容性问题其如何阅读一节说明每个 ✓ 链接指向对应 Grid 版本下的详细 changelog。镜像内版本从哪来NodeChrome 构建链路标签里出现的105.0.5195.125并非凭空产生而是源于 NodeChrome/Dockerfile 的构建期固化镜像通过 install-chrome.sh 安装指定版本的google-chrome-stable通过 install-chromedriver.sh 安装 ChromeDriver并将版本写入/opt/selenium/browsers/chrome/version见 NodeChrome/Dockerfile。docker run ... google-chrome --version之所以能取到准确版本正是依赖这条构建期写入、运行期探测的一致性设计。实战根据标签拉取并运行镜像理解了标签体系之后实际使用只需按需选择。docs 目录下的镜像说明如 docs/docker-hub/node-chrome.md、docs/docker-hub/standalone-chrome.md给出的标签模板为selenium/node-chrome-Major.Minor.Patch-YYYYMMDD selenium/node-chrome-browserVersion-browserDriver-browserDriverVersion-Major.Minor.Patch-YYYYMMDD以本文的 Chrome 105 为例对应本次发布记录中的两个典型标签selenium/standalone-chrome:105.0.5195.125-20250515锁定 Chrome 补丁版本与构建日期适合可复现的 CI 环境selenium/standalone-chrome:105.0-chromedriver-105.0锁定主版本与驱动主版本补丁自动跟进适合日常开发。Standalone 模式的启动方式见 docs/docker-hub/standalone-chrome.mddocker run -d -p 4444:4444 -p 7900:7900 --shm-size2g selenium/standalone-chrome:105.0.5195.125-20250515Node 模式需要先建网络再接 Hub见 docs/docker-hub/node-chrome.mddocker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:latest docker run -d --net grid -e SE_EVENT_BUS_HOSTselenium-hub \ --shm-size2g \ selenium/node-chrome:105.0.5195.125-20250515两种模式都必须加--shm-size2g使用宿主机共享内存否则浏览器进程可能因/dev/shm空间不足而崩溃如需可视化调试可访问http://localhost:7900/?autoconnect1resizescalepasswordsecret。小结一次看似平凡的发布日志背后是 docker-selenium 精心设计的版本矩阵工程以 tag_and_push_browser_images.sh 为引擎通过镜像内版本探测、短版本推导、多组合标签数组和docker tag/buildx imagetools双路径打标为每个 Grid 版本和浏览器版本组合生成从完全锁定到滚动跟进的 10 种标签。当你在 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点击查看免费下载相关推荐AgentOps Dashboard 的 Cypress E2E 测试实践data-testid 命名规范、自定义命令与隐式断言AgentOps Dashboard 的 Cypress E2E 测试实践data testid 命名规范、自定义命令与隐式断言 AgentOps 是一个面向测试后端云原生容器编排可观测性从 CHANGELOG 到源码ohif/ui-next 组件库演进全解析与定制实践从 CHANGELOG 到源码ohif/ui next 组件库演进全解析与定制实践 导读 ohif/ui next 是 OHIF Viewer 新一代 U测试后端云原生容器编排可观测性docker-selenium 浏览器镜像多标签发布机制以 4.28.1 版 Chrome 105 镜像为例docker selenium 浏览器镜像多标签发布机制以 4.28.1 版 Chrome 105 镜像为例 本文基于 CHANGELOG/archived/测试后端云原生容器编排可观测性上一篇喜马拉雅音频获取终极指南XMly-Downloader-Qt5便捷获取VIP付费专辑下一篇Python金融量化分析完整教程从基础概念到高级实战应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考