测试后端云原生容器编排可观测性【免费下载链接】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点击查看免费下载本文以仓库中 CHANGELOG/4.48.0/chrome_104.md 这份发布记录为核心逐行拆解 docker-selenium 项目一个浏览器版本打多个镜像标签的完整机制从tag_and_push_browser_images.sh的调用参数、镜像内版本探测、标签命名规则到docker tag/docker push与buildx imagetools两种发布路径。读完本文你将能够读懂任意一份CHANGELOG/4.48.0/chrome_*.md发布记录理解selenium/node-chrome与selenium/standalone-chrome上不同粒度标签的由来并学会如何用精确标签固定浏览器与驱动版本。这份发布记录记录了什么CHANGELOG/4.48.0/chrome_104.md全文是一段脚本执行日志记录的是 Selenium Grid 4.48.0构建日期 20260909发布时为 Chrome 104 这一旧版本浏览器补打镜像标签的过程。它由版本矩阵文档 CHANGELOG/README.md 中的链接直接引用——矩阵中每个 ✓ 都指向对应浏览器版本的详细 changelog。其动机正如矩阵文档所述让最新版 Selenium Grid 核心功能与历史浏览器版本共存满足跨浏览器测试、以及因兼容性限制而必须钉住特定浏览器版本的场景。日志本身的信息密度并不低从中可以直接读出四条关键事实事实数值Selenium Grid 版本4.48.0-20260909Chrome 完整版本104.0.5112.101Chrome 短版本104.0ChromeDriver 版本104.0.5112.79生成的标签数每类镜像 6 个node 与 standalone 各 6 个共 12 行 Tagged 输出命令与七个入参逐项解析日志第一行暴露了实际执行命令./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true对照脚本 tag_and_push_browser_images.sh 第 3~9 行的参数定义VERSION$1、BUILD_DATE$2、NAMESPACE$3、PUSH_IMAGE${4:-false}、BROWSER$5、RELEASE_OLD_VERSION${6:-false}、PLATFORM${7:-linux/amd64}七个参数含义如下位置参数本次取值作用$1VERSION4.48.0Selenium Grid 版本号$2BUILD_DATE20260909构建日期与 VERSION 拼成基础镜像标签4.48.0-20260909$3NAMESPACEselenium镜像命名空间注意脚本第 16 行NAMESPACE${NAME:-selenium}会用环境变量NAME覆盖$4PUSH_IMAGEfalse是否在打标签后执行docker push$5BROWSERchrome浏览器类型脚本支持 chrome / chromium / edge / firefox / chrome-for-testing 五个分支$6RELEASE_OLD_VERSIONtrue是否为旧版本浏览器补打标签影响是否生成纯版本标签$7PLATFORM默认linux/amd64探测版本时docker run的目标平台该命令被 Makefile 中的tag_and_push_browser_images/tag_and_push_chrome_images目标统一调度make传参时还会补充$(PUSH_IMAGE)与$(RELEASE_OLD_VERSION)因此这份日志也等价于在 CI 的 release 流程中对chrome_104这一条目执行的结果。版本号从哪里来容器内动态探测脚本并不在宿主环境假设 Chrome 版本而是直接运行刚构建好的镜像读取真实版本。Chrome 分支第 65~73 行的关键调用链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})先以基础标签${NAMESPACE}/node-chrome:4.48.0-20260909启动一次性容器分别执行google-chrome --version与chromedriver --version再用awk截取版本字段Chrome 取第 3 个字段得到104.0.5112.101ChromeDriver 取第 2 个字段得到104.0.5112.79与日志中 Chrome version - 104.0.5112.101 完全吻合随后调用short_version()第 53~57 行按.切分后保留前两段得到短版本104.0并输出 Short Chrome version - 104.0。从镜像内部读取版本这一设计保证了标签永远与镜像内真实二进制一致避免了版本声明与镜像内容漂移的问题。镜像内 Chrome 的安装与版本声明逻辑可在 NodeChrome/Dockerfile 中看到——它通过google-chrome --version | awk {print $3}将版本写入/opt/selenium/browsers/chrome/version与脚本的字段截取方式一脉相承。六类标签的命名规则与粒度脚本第 75~87 行把上述四个版本变量组合出基础六类标签日志中每类同时打在selenium/node-chrome与selenium/standalone-chrome两个镜像上#标签含意1104.0.5112.101-chromedriver-104.0.5112.79-grid-4.48.0-20260909浏览器完整版 驱动完整版 Grid 完整版 构建日期精度最高2104.0.5112.101-chromedriver-104.0.5112.79-20260909浏览器完整版 驱动完整版 构建日期3104.0.5112.101-20260909浏览器完整版 构建日期4104.0-chromedriver-104.0-grid-4.48.0-20260909短版本粒度其余同上5104.0-chromedriver-104.0-20260909短版本粒度含驱动短版本6104.0-20260909最短粒度浏览器短版本 构建日期日志中每类标签都先出现在node-chrome上、再出现在standalone-chrome上第 9~20 行正是脚本末尾循环retag node-chrome ${chrome_tag}、retag standalone-chrome ${chrome_tag}第 101~104 行的执行结果。注意这份日志中并没有出现104.0.5112.101、104.0-chromedriver-104.0.5112.79这类不含构建日期的裸版本标签。原因是第 6 个参数RELEASE_OLD_VERSIONtrue脚本第 88 行if [ ${RELEASE_OLD_VERSION} false ]才把纯版本标签追加进CHROME_TAGS。也就是说只有在浏览器版本恰好是本次发布的新版本时才会再额外生成不带日期的短标签新版本发布前latest等滚动标签需要被刷新而对 Chrome 104 这种早已发布过的旧版本只补打带构建日期的标签避免旧版本裸标签被无意义地重复推送。这解释了为什么日志输出恰为 6×212 行 Tagged。retag 的底层两条发布路径日志里每一行 Tagged ... 都由retag()第 31~51 行打印。该函数有两种行为模式常规路径PROMOTE_TAGS 未开启时——即本次日志所用的方式docker tag ${NAMESPACE}/${__image}:${TAG_VERSION} ${NAMESPACE}/${__image}:${__tag} docker push ${NAMESPACE}/${__image}:${__tag} # 仅当 PUSH_IMAGEtrue 时执行先在本地给同一个镜像 ID 打上别名标签再按需推送。因为本次PUSH_IMAGEfalse所以只输出 Tagged 而不涉及 push。Promote 路径PROMOTE_TAGStrue由 deploy.yml 在复用已测试镜像而非重建的发布流程中设置——此时源镜像不在本地构建环境中docker tag无法跨架构工作脚本改用docker buildx imagetools create第 41 行在 registry 与 registry 之间直接操作镜像 index从而保留多架构清单若同时设置了PROMOTE_GHCR_NAMESPACE还会在同一调用中把标签镜像到 GHCR第 38~39 行。脚本注释对此有完整说明这也是 Makefile 中tag_and_push_browser_images_ghcr目标用docker buildx imagetools create将 docker.io 镜像镜像到 GHCR 的同源做法。实战如何用这些标签固定测试环境这份发布记录的存在价值最终体现在用户侧。结合 docs/docker-hub/node-chrome.md 的说明选择标签遵循精度越高越稳定原则# 钉死到浏览器 驱动 Grid 全版本适合复现问题对应日志第 9~10 行 docker run -d --net grid -e SE_EVENT_BUS_HOSTselenium-hub --shm-size2g \ selenium/node-chrome:104.0.5112.101-chromedriver-104.0.5112.79-grid-4.48.0-20260909 # 仅关心浏览器大版本使用短版本标签对应日志第 19~20 行 docker run -d --net grid -e SE_EVENT_BUS_HOSTselenium-hub --shm-size2g \ selenium/node-chrome:104.0-20260909几点使用注意运行含浏览器的镜像时务必加--shm-size2g使用宿主共享内存否则 Chrome 可能因/dev/shm不足而崩溃测试脚本把 WebDriver 指向 Hub 的http://localhost:4444即可不要盲目使用latest滚动标签官方文档亦建议使用完整标签钉住浏览器与 Grid 版本——chrome_104.md这份记录的价值正在于它让104.0.5112.101这类旧版本永远有确定、可复现的完整标签可用若需要其他浏览器Chromium / Edge / Firefox / Chrome for Testing同一脚本的不同分支tag_and_push_browser_images.sh遵循完全相同的版本探测 → 拼装六类标签 → 可选追加纯版本标签流程。结语一份看似只有命令行回显的 changelog 文件实际浓缩了 docker-selenium 镜像发布流水线的核心设计容器内动态探测版本、粒度递进的六类标签体系、RELEASE_OLD_VERSION对历史版本的差异化处理以及docker tag/buildx imagetools双路径发布。理解了 tag_and_push_browser_images.sh 之后CHANGELOG/4.48.0 下 Chrome 95~152、Edge、Firefox 等全部同类记录都可以按同一套逻辑解读配合 CHANGELOG/README.md 的版本矩阵你可以快速定位任意 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点击查看免费下载相关推荐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 for Testing 137 生成镜像标签docker selenium 发布实录Selenium Grid 4.48.0 如何为 Chrome for Testing 137 生成镜像标签 本篇文章测试后端云原生容器编排可观测性GameDevMind 游戏 DevOps 实践CI/CD、出包生产线与自动化工具链搭建指南GameDevMind 游戏 DevOps 实践CI/CD、出包生产线与自动化工具链搭建指南 本文基于 GameDevMind 知识库的 4.3.3.DevO测试后端云原生容器编排可观测性上一篇Read the Docs 账户认证方式全解析邮箱密码、VCS OAuth、Google/SAML SSO 与 2FA下一篇ComfyUI-KJNodes突破性节点架构的革命性工作流优化方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考