资讯详情

docker-selenium 镜像标签体系解析:以 Selenium Grid 4.29.0 + Chrome 102 的 changelog 为例

📅 2026/10/5 11:40:41 | 华诺云谱 👁 阅读
docker-selenium 镜像标签体系解析:以 Selenium Grid 4.29.0 + Chrome 102 的 changelog 为例
测试后端云原生容器编排可观测性【免费下载链接】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点击查看免费下载导读本文以仓库归档的 Chrome 102 版本 changelog 为线索完整拆解 docker-selenium 项目Grid 版本 × 浏览器版本 × 构建日期三维镜像标签体系的生成逻辑。读者将掌握tag_and_push_browser_images.sh脚本的全部参数含义、12 个浏览器镜像标签的命名规则与使用场景以及旧版 Chrome版本 115ChromeDriver 的安装与匹配原理从而能够精确选择适合自己测试环境的镜像标签。背景从版本矩阵到 changelog 文档docker-selenium 项目长期维护着一个浏览器版本兼容矩阵用于同时提供两种能力一是持续供应最新 Selenium Grid 核心功能二是允许用户按需固定某个浏览器版本例如因为特定浏览器版本存在已知缺陷、或业务只兼容特定版本继续执行跨浏览器测试。矩阵由 CHANGELOG/README.md 承载其中每个✓都会链接到对应浏览器版本在该 Grid 版本下的详细 changelog 文档最新的 Grid 版本排在最前旧版本归档到archived/目录。本文的主角 chrome_102.md 正是这样一份 changelog它记录了在 Selenium Grid 4.29.0构建日期 20250303下Chrome 102 镜像被打上全部标签的过程与结果。这些矩阵文档并非手工维护而是由 CHANGELOG/generate-matrix-readme.py 自动生成脚本先扫描当前与archived目录下所有形如4.29.0的版本目录按([\w-])_(\d)\.md正则解析出每个浏览器及其版本号再按版本降序渲染出矩阵表格。也就是说每次发布新 Grid 版本并归档旧版本时该脚本都会重写 README确保矩阵与磁盘上的 changelog 文件一一对应。命令全景一次调用生成 12 个标签chrome_102.md记录的完整命令与输出如下./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 - 102.0.5005.115 Short Chrome version - 102.0 ChromeDriver version - 102.0.5005.61 Short ChromeDriver version - 102.0 Tagged selenium/node-chrome:102.0.5005.115-chromedriver-102.0.5005.61-grid-4.29.0-20250303 Tagged selenium/standalone-chrome:102.0.5005.115-chromedriver-102.0.5005.61-grid-4.29.0-20250303 Tagged selenium/node-chrome:102.0.5005.115-chromedriver-102.0.5005.61-20250303 Tagged selenium/standalone-chrome:102.0.5005.115-chromedriver-102.0.5005.61-20250303 Tagged selenium/node-chrome:102.0.5005.115-20250303 Tagged selenium/standalone-chrome:102.0.5005.115-20250303 Tagged selenium/node-chrome:102.0-chromedriver-102.0-grid-4.29.0-20250303 Tagged selenium/standalone-chrome:102.0-chromedriver-102.0-grid-4.29.0-20250303 Tagged selenium/node-chrome:102.0-chromedriver-102.0-20250303 Tagged selenium/standalone-chrome:102.0-chromedriver-102.0-20250303 Tagged selenium/node-chrome:102.0-20250303 Tagged selenium/standalone-chrome:102.0-20250303脚本本身位于仓库根目录的 tag_and_push_browser_images.sh它接收最多 7 个位置参数。各参数含义如下表参数含义默认值本次调用值$1VERSIONSelenium Grid 版本号无必填4.29.0$2BUILD_DATE构建日期%Y%m%d格式无必填20250303$3NAMESPACE镜像命名空间无必填selenium$4PUSH_IMAGE是否推送镜像到 registryfalsefalse$5BROWSER浏览器类型无必填chrome$6RELEASE_OLD_VERSION是否为旧版本发布falsetrue$7PLATFORM构建平台linux/amd64未传使用默认在 Makefile 中该脚本被封装为多个 target便于按浏览器分别调用例如 tag_and_push_chrome_images 实际执行./tag_and_push_browser_images.sh $(VERSION) $(BUILD_DATE) $(NAMESPACE) $(PUSH_IMAGE) chrome $(RELEASE_OLD_VERSION)其中VERSION、BUILD_DATE、NAMESPACE、PUSH_IMAGE、RELEASE_OLD_VERSION均可通过环境变量或 make 参数覆盖仓库默认值可见 Makefile 顶部变量定义默认NAMESPACEselenium、PUSH_IMAGEfalse、RELEASE_OLD_VERSIONfalse。此外 Makefile 还提供了tag_and_push_browser_images_ghcr、mirror_browser_images_ghcr等 target用于把同样的标签集通过docker buildx imagetools create镜像到 GHCR 等二级仓库。版本探测镜像即事实来源脚本不会凭空假设浏览器与驱动的版本号而是直接从已构建的 node 镜像中读取真实版本。对于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})即先构造基础标签${VERSION}-${BUILD_DATE}如4.29.0-20250303临时运行selenium/node-chrome:4.29.0-20250303容器分别执行google-chrome --version与chromedriver --version再用awk截取第 3、第 2 个字段得到完整版本号102.0.5005.115与102.0.5005.61。长版本号随后被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]} }按.分割后取前两段102.0.5005.115→102.0102.0.5005.61→102.0。这一镜像内容反查版本号的设计保证了标签永远与实际打包进镜像的二进制版本一致不会出现标签与内容脱节的情况。标签命名规则六种组合 × 两个镜像脚本为每个浏览器版本生成 6 个不同粒度的标签然后同时打给node-chrome与standalone-chrome两个镜像因此单次调用共产生 12 个标签。标签由若干版本段拼接而成每个版本段本身也遵循固定格式版本段格式示例说明浏览器完整版-chromedriver-驱动完整版-grid-Grid版本-构建日期102.0.5005.115-chromedriver-102.0.5005.61-grid-4.29.0-20250303最完整、最精确的组合所有维度全部锁定浏览器完整版-chromedriver-驱动完整版-构建日期102.0.5005.115-chromedriver-102.0.5005.61-20250303浏览器与驱动完整版本 构建日期浏览器完整版-构建日期102.0.5005.115-20250303仅锁定浏览器完整版本与构建日期浏览器短版-chromedriver-驱动短版-grid-Grid版本-构建日期102.0-chromedriver-102.0-grid-4.29.0-20250303短版本的精简组合浏览器短版-chromedriver-驱动短版-构建日期102.0-chromedriver-102.0-20250303短版本 构建日期浏览器短版-构建日期102.0-20250303最精简的可辨识标签上述 6 种标签在 tag_and_push_browser_images.sh 的CHROME_TAGS数组中按序定义。注意chrome_102.md对应的这次调用是旧版本发布第 6 个参数为true因此没有追加第 712 个不带构建日期的裸版本标签只有当RELEASE_OLD_VERSIONfalse即常规新版本发布时脚本才会额外补上如下标签tag_and_push_browser_images.sh追加标签格式示例说明浏览器完整版-chromedriver-驱动完整版102.0.5005.115-chromedriver-102.0.5005.61浏览器与驱动完整版本不含日期浏览器完整版102.0.5005.115仅浏览器完整版本浏览器短版-chromedriver-驱动短版102.0-chromedriver-102.0短版本对浏览器短版102.0仅浏览器短版本最后通过retag函数逐个应用tag_and_push_browser_images.sh默认用docker tag复制本地镜像引用PUSH_IMAGEtrue时再执行docker push推送若启用PROMOTE_TAGStrue则改为docker buildx imagetools create在 registry 间直接创建索引别名从而保留多架构 manifest见脚本头部注释。这套规则的动机在 CHANGELOG/README.md 中写得很清楚用户找到镜像标签拉取所需镜像直接开始测试。粒度从粗到细的标签设计让使用者既可以只锁定102.0这样的大版本范围也可以把 Grid、浏览器、驱动、构建日期全部钉死兼顾灵活性与可复现性。实际使用按标签拉取并运行以本文 changelog 对应的发布为例选择最精确的标签即可获得完全确定的运行环境docker pull selenium/node-chrome:102.0.5005.115-chromedriver-102.0.5005.61-grid-4.29.0-20250303 docker pull selenium/standalone-chrome:102.0.5005.115-chromedriver-102.0.5005.61-grid-4.29.0-20250303若只关心浏览器大版本可用短标签docker pull selenium/node-chrome:102.0-20250303 docker pull selenium/standalone-chrome:102.0-20250303standalone-chrome是内置了完整 Selenium Grid 的开箱即用形态拉取后可直接作为 Grid 节点或独立服务器运行node-chrome则作为分布式 Grid 中的浏览器节点使用。项目根目录的 docker-compose 系列文件如 docker-compose-v3.yml、docker-compose-v3-full-grid.yml演示了如何通过环境变量SE_NODE_*将 node 镜像注册到 Hub。需要提醒的是矩阵文档明确声明项目并不会对每个Grid × 浏览器组合做全量回归测试用户需要根据自己的测试需求评估并决定是否采用某个组合。这正是指定浏览器版本镜像的价值所在——当某个新浏览器版本出现兼容问题时可以快速回退到本 changelog 锁定的旧版本组合。源码纵深旧版 Chrome 的 ChromeDriver 匹配原理Chrome 102 属于早于 115 的版本其 ChromeDriver 的安装路径在 NodeChrome/install-chromedriver.sh 中有专门处理。该脚本按架构与主版本号分流其中 amd64 且主版本 115 时走legacy路径install-chromedriver.shif [ ${ARCH} amd64 ] [ -n ${CHROME_MAJOR_VERSION} ] [ ${CHROME_MAJOR_VERSION} -lt 115 ]; then DRIVER_SOURCElegacy DRIVER_ARCHlinux64 RESOLVED_VERSIONlegacy路径使用 Google 早已冻结的旧版 APIinstall-chromedriver.shCHROME_DRIVER_VERSION$(wget -qO- https://chromedriver.storage.googleapis.com/LATEST_RELEASE_${CHROME_MAJOR_VERSION} | sed s/\r$//) CHROME_DRIVER_URLhttps://chromedriver.storage.googleapis.com/$CHROME_DRIVER_VERSION/chromedriver_linux64.zip即请求LATEST_RELEASE_102获取 Chrome 102 系列最新的驱动版本再下载对应的chromedriver_linux64.zip。由于 Chrome 115 之前的版本不存在 Chrome for TestingCfT通道因此脚本刻意保留这条旧路径而不走 CfT 解析器脚本注释明确说明这一点。安装完成后驱动会被放置为/opt/selenium/chromedriver-版本并通过符号链接/usr/bin/chromedriver暴露给 Selenium。浏览器侧则由 NodeChrome/install-chrome.sh 负责默认从 Google 官方 apt 源安装google-chrome-stable若指定形如google-chrome-stable102.0.5005.115-1的精确版本则走版本固定分支从归档下载对应 deb 包并用--allow-downgrades安装。这正是 4.29.0 时代构建 Chrome 102 固定版本镜像时使用的机制。在 NodeChrome/Dockerfile 中CHROME_DRIVER_VERSION作为构建参数传入默认留空以启用根据镜像内已装 Chrome 自动探测驱动版本的行为镜像构建最后会把浏览器版本信息写入/opt/selenium/browsers/chrome/含 name、version、binary_location供 Grid 节点配置使用。结论与适用边界chrome_102.md这份 changelog 虽然只有一段命令输出但它浓缩了 docker-selenium 浏览器镜像发布机制的核心链路版本矩阵生成CHANGELOG/generate-matrix-readme.py→ 构建带基础标签的 node 镜像NodeChrome/Dockerfile→ 从镜像反查浏览器/驱动真实版本 → 按六种粒度组合打标签tag_and_push_browser_images.sh。适用时需注意以下前提与限制本文示例基于 Selenium Grid 4.29.0构建日期 20250303与 Chrome 102.0.5005.115 / ChromeDriver 102.0.5005.61且属于归档的旧版本发布未生成无日期的裸版本标签Chrome 102 的驱动来自冻结的chromedriver.storage.googleapis.com旧 API仅提供linux64架构较新版本≥ 115则走 Chrome for Testing 通道参见 resolve-chromedriver-source.sh相同浏览器版本在不同 Grid 版本下生成的标签格式完全一致只需替换 Grid 版本与构建日期字段例如最新矩阵 CHANGELOG/4.48.0/chrome_102.md 即展示了同一浏览器在 Grid 4.48.0 下的对应标签项目未对每个版本组合做全量回归生产使用前应基于自身测试场景验证所选标签组合的可用性。赞分享测试后端云原生容器编排可观测性【免费下载链接】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 98 与 Selenium Grid 4.29.0 发布记录为例Docker Selenium 镜像标签全解析以 Chrome 98 与 Selenium Grid 4.29.0 发布记录为例 本篇以仓库 CHANGELO测试后端云原生容器编排可观测性docker-selenium 浏览器镜像 Tag 体系全解析以 Selenium Grid 4.29.0 Chrome 100 为例docker selenium 浏览器镜像 Tag 体系全解析以 Selenium Grid 4.29.0 Chrome 100 为例 本文以 CHANG测试后端云原生容器编排可观测性理解 docker-selenium 浏览器镜像标签体系以 Chrome 103 与 Selenium Grid 4.29.0 的归档记录为例理解 docker selenium 浏览器镜像标签体系以 Chrome 103 与 Selenium Grid 4.29.0 的归档记录为例 本文将围绕 d测试后端云原生容器编排可观测性上一篇深度剖析kfyty725/loveqq-framework的AOP代理代理扩展性下一篇终极像素字体指南3种尺寸、多语言融合的完整解决方案创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。

↑