测试后端云原生容器编排可观测性【免费下载链接】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_121.md 这份 Chrome 121 版本发布记录为核心完整解读它在 Selenium Grid 4.48.0 构建build date 20260909中打出的全部镜像标签并下沉到 tag_and_push_browser_images.sh、NodeChrome/Dockerfile 等源码级实现讲清楚浏览器版本 ChromeDriver 版本 Grid 版本 构建日期这套标签体系从生成到落地的完整链路。读完你不仅能准确读懂任意一份 browser changelog 中的标签还能知道在跨浏览器测试或固定浏览器版本时该拉取哪个镜像。一、这份 Changelog 记录了什么CHANGELOG/4.48.0/chrome_121.md是一份发布打标日志型文档它原样记录了在某次发布流程中执行镜像打标命令后的完整终端输出。整份日志围绕一个核心事实展开Selenium Grid 版本4.48.0-20260909Grid 版本号 构建日期Chrome 版本121.0.6167.184短版本号121.0ChromeDriver 版本121.0.6167.184短版本号121.0打标目标镜像selenium/node-chrome与selenium/standalone-chrome各 6 个标签共 12 个标签。这份文件在整个仓库中的定位是 CHANGELOG/README.md 版本矩阵中4.48.0行、121列下✓链接指向的详情页。矩阵用一句话说明了它的动机用最新的 Selenium Grid 核心版本提供新功能同时让用户仍能用于跨浏览器测试或在特定浏览器版本存在兼容性问题时固定浏览器版本——仓库同时交付 Node 与 Standalone 两类镜像打包了 Grid 与特定驱动/浏览器版本。也就是说这份 changelog 的价值不在于描述功能而在于回答一个非常实际的运维问题Grid 4.48.0 时代的 Chrome 121 镜像有哪些 tag 可用、每个 tag 精确对应什么版本组合。二、命令与版本对应关系一行命令打出的 12 个标签日志第一行展示了触发本次打标的原始命令./tag_and_push_browser_images.sh 4.48.0 20260909 selenium false chrome true对照 tag_and_push_browser_images.sh 顶部的位置参数定义L1-L9可以逐一解读参数值含义$1VERSION4.48.0Selenium Grid 版本号$2BUILD_DATE20260909构建日期与版本号拼成TAG_VERSION4.48.0-20260909$3NAMESPACEselenium镜像命名空间docker.io/selenium$4PUSH_IMAGEfalse是否推送镜像到仓库本次仅本地打标$5BROWSERchrome浏览器类型决定走哪个case分支$6RELEASE_OLD_VERSIONtrue是否同时发布老版本风格标签详见下文$7PLATFORM默认linux/amd64探测版本时使用的运行平台随后脚本进入chrome)分支用两条docker run从已构建好的selenium/node-chrome:4.48.0-20260909镜像内部探测出真实版本L65-L73CHROME_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})awk {print $3}/{print $2}分别从google-chrome --version与chromedriver --version的输出中截取版本号日志中的Chrome version - 121.0.6167.184与ChromeDriver version - 121.0.6167.184正是这两条命令的产物。注意 Chrome 与 ChromeDriver 同为121.0.6167.184——在 Chrome 121 时代两者的版本号保持完全一致这也是后续标签里 121.0.6167.184-chromedriver-121.0.6167.184 成对出现的原因。三、Tag 命名规范六类标签的构成与语义日志中每个镜像各打了 6 个标签命名遵循浏览器版本 × 驱动版本 × Grid 版本 × 构建日期的组合矩阵全部由脚本内的CHROME_TAGS数组生成L75-L99。以node-chrome为例# 完整版本号长标签 selenium/node-chrome:121.0.6167.184-chromedriver-121.0.6167.184-grid-4.48.0-20260909 selenium/node-chrome:121.0.6167.184-chromedriver-121.0.6167.184-20260909 selenium/node-chrome:121.0.6167.184-20260909 # 短版本号短标签取主.次版本 selenium/node-chrome:121.0-chromedriver-121.0-grid-4.48.0-20260909 selenium/node-chrome:121.0-chromedriver-121.0-20260909 selenium/node-chrome:121.0-20260909逐一拆解这 6 类标签的信息量chrome-chromedriver-driver-grid-grid-date信息最完整——浏览器、驱动、Grid、构建日期四元组全部显式标明适合精确复现某个发布快照例如跨团队对齐 CI 环境时chrome-chromedriver-driver-date浏览器与驱动全版本 构建日期省略 Grid 版本号chrome-date仅浏览器版本与构建日期驱动版本信息隐含在镜像内容中short-chromedriver-short-grid-grid-date把 Chrome/ChromeDriver 压缩为主.次版本121.0Grid 与日期仍完整short-chromedriver-short-date短版本 构建日期short-date最精简的短版本 构建日期标签也是日常最容易记忆、最常用的形式。短版本由short_version()函数生成L53-L57以.分割版本号后仅保留前两段因此121.0.6167.184→121.0。这样做的意义在于浏览器小版本补丁patch频繁发布而121.0这类主.次标签能让使用方在同一个大版本周期内少改配置。值得注意的一个细节是RELEASE_OLD_VERSIONtrue的影响。对比脚本逻辑L88-L99当该参数为false时会额外追加 4 个标签包括121.0.6167.184-chromedriver-121.0.6167.184、121.0.6167.184、121.0-chromedriver-121.0、121.0不含构建日期的浮动标签而本次日志传入了true因此这 4 个不带日期的标签没有被生成。这正是发布老版本场景下的刻意收敛对已被历史发布固定住的浏览器版本不再产生会随日期漂移的短标签避免用户在同一浏览器版本上意外拿到不同 Grid 构建。作为对照仓库中同时保留了 Chrome for Testing 路径的发布记录 CHANGELOG/4.48.0/chrome-for-testing_121.md同一构建日期、同一版本号121.0.6167.184但镜像名为node-chrome-for-testing/standalone-chrome-for-testing且日志第一行命令的第 5 个参数为chrome-for-testing。两者可以互相印证同一套标签规范在不同镜像家族上的复现。四、源码级原理Tag 是如何生成的4.1retag()本地打标、推送与提升发布脚本核心的retag()函数L31-L51处理三种模式默认模式docker tag ${source} ${NAMESPACE}/${image}:${tag}仅给本地镜像加别名若PUSH_IMAGEtrue随后执行docker pushPROMOTE_TAGS 模式由发布流水线设置源镜像并不在本地而是位于镜像仓库中。此时直接以仓库中的 manifest 为目标执行docker buildx imagetools create在 registry 之间完成打标避免docker pull只带回单架构镜像、从而破坏多架构multi-architecture标签的问题GHCR 镜像同步当设置PROMOTE_GHCR_NAMESPACE时同一次调用还会同步在 GHCR 命名空间生成对应标签。4.2 从 Makefile 到发布流水线仓库根目录的 Makefile 把这些脚本调用封装成了 make 目标L781-L796tag_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 变量。该目标也被登记在 Makefile 的SKIP_BUILD_TARGETS列表中L1831意味着在SKIP_BUILDtrue的复用预构建镜像发布路径下它同样会被调用。此外每次构建新版本镜像前Makefile 的chrome_upgrade_version等目标会先构建node-chrome与standalone-chrome随后用三条docker run校验selenium-server.jar info --version、google-chrome --version、chromedriver --version——与打标脚本内部的版本探测方式完全一致保证构建产物真实版本与打标所用版本同源。4.3 浏览器与驱动的版本从哪来镜像构建侧打标脚本只是读取者Chrome 与 ChromeDriver 的真实版本在镜像构建阶段就已固定。看 NodeChrome/DockerfileARG CHROME_VERSIONgoogle-chrome-stableL18决定安装的 Chrome 渠道/版本构建期可通过--build-arg CHROME_VERSION...指定例如google-chrome-stable、google-chrome-beta、google-chrome-unstableNodeChrome/install-chrome.sh 支持两种安装路径常规的 apt 渠道安装以及google-chrome-stable121.0.6167.120-1这类指定精确版本的安装从 Chrome 发行归档下载对应架构的.deb并--allow-downgrades安装这正是固定浏览器版本需求的来源ARG CHROME_DRIVER_VERSIONL48为空时由 NodeChrome/install-chromedriver.sh自动探测 Chrome 主版本号并匹配对应 ChromeDriver构建完成后google-chrome --version的完整版本会被写入/opt/selenium/browsers/chrome/versionL65-L72供 Selenium Grid 的 Node 配置读取。这里的驱动与浏览器同版本并非巧合Chrome 121 起ChromeDriver 走 Chrome for TestingCfT发布通道install-chromedriver.sh在 amd64 上从 CfT 拉取与 Chrome 主版本号一致的驱动在 CfT 未提供对应架构构建的平台上则回退到 Chromium 驱动包。这个选源决策被单独抽成了 NodeChrome/resolve-chromedriver-source.sh并有对应的单元测试 tests/node_chrome/test_resolve_chromedriver_source.py 覆盖通过 stub 掉wget验证amd64走cft/linux64、arm64在 CfT 无 arm64 构建时回退chromium-package等分支。五、Changelog 与版本矩阵如何被检索与维护这份chrome_121.md不是孤立文件它由 CHANGELOG/generate-matrix-readme.py 纳入统一管理扫描脚本用正则([\w-])_(\d)\.md匹配每个版本目录下的 changelog 文件名如chrome_121.md把浏览器 版本号登记进矩阵L45-L67归档当出现新的 Grid 版本目录时旧版本目录被移入CHANGELOG/archived/只保留最新版本在根目录L8-L42生成重新生成 CHANGELOG/README.md其中4.48.0行的121列下✓就链接到本文解析的4.48.0/chrome_121.md。对使用方而言正确的检索路径是先到 CHANGELOG/README.md 矩阵中确认Grid 版本 × 浏览器版本组合是否提供再点进对应 changelog 获取精确到构建日期的完整标签清单。README 也明确提示项目并未对每个 Grid 与浏览器版本的组合做全量测试用户在固定版本时需结合自身测试需求评估。六、实战用这份 Changelog 拉取并运行 Chrome 121 镜像6.1 按需选择 Node 或 Standaloneselenium/node-chromeGrid 架构中的浏览器节点需配合 Hubselenium/hub:4.48.0-20260909使用适合分布式、可横向扩展的测试集群selenium/standalone-chrome单机即 GridHub Node 一体适合本地调试、单机 CI 或小规模任务。以最精简的短标签为例# 分布式Node 模式 docker pull selenium/node-chrome:121.0-20260909 # 单机Standalone 模式 docker pull selenium/standalone-chrome:121.0-20260909如需精确复现发布快照则用最长标签docker pull selenium/node-chrome:121.0.6167.184-chromedriver-121.0.6167.184-grid-4.48.0-202609096.2 在 Compose 中固定版本仓库根目录的 docker-compose-v3.yml 展示了 Grid 的编排方式chrome服务使用selenium/node-chrome镜像并设置shm_size: 2gbChrome 渲染依赖共享内存过小易崩溃、通过SE_EVENT_BUS_HOSTselenium-hub连接 HubHub 暴露4442/4443/4444端口。将该文件中的镜像 tag 换成121.0-20260909即可在 Compose 场景下固定 Chrome 121services: chrome: image: selenium/node-chrome:121.0-20260909 shm_size: 2gb depends_on: - selenium-hub environment: - SE_EVENT_BUS_HOSTselenium-hub selenium-hub: image: selenium/hub:4.48.0-20260909 ports: - 4444:4444启动命令为docker compose -f docker-compose-v3.yml up加-d后台运行down停止。注意docker-compose-v3.yml中 Grid 镜像的构建日期为20260905与本文 changelog 的20260909不同——构建日期是标签的重要组成部分不同批次的 Grid 构建对应不同日期后缀混用时需保持前后一致。6.3 验证拉取的镜像拉取后可自行复现打标脚本的探测逻辑确认镜像内版本与标签一致docker run --rm selenium/node-chrome:121.0-20260909 google-chrome --version docker run --rm selenium/node-chrome:121.0-20260909 chromedriver --version七、小结回到 CHANGELOG/4.48.0/chrome_121.md 这份只有 21 行的日志它浓缩了 docker-selenium 发布体系中最核心的版本钉扎信息Chrome 121.0.6167.184 与 ChromeDriver 121.0.6167.184 被固定进 Grid 4.48.0-20260909 的 node-chrome / standalone-chrome 镜像并以 6 类标签覆盖从完整四元组到短版本的不同精确度需求。理解这套标签体系就能在跨浏览器测试、版本回归、CI 环境复现等场景下精准选择镜像不再被一长串 tag 字符串迷惑。赞分享测试后端云原生容器编排可观测性【免费下载链接】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点击查看免费下载相关推荐Selenium Grid 4.48.0 与 Chrome for Testing 134 镜像标签全解析docker-selenium 的浏览器版本矩阵与镜像打标机制Selenium Grid 4.48.0 与 Chrome for Testing 134 镜像标签全解析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 生成镜像标签 本篇文章测试后端云原生容器编排可观测性上一篇Next Terminal跨平台兼容性测试从Windows到Linux的全面验证下一篇什么是DeepSTARR-NPU249bp DNA序列预测增强子活性的昇腾910B4完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考