测试后端云原生容器编排可观测性【免费下载链接】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/archived/4.28.1/chrome_128.md 这份发布记录展开它完整记录了 docker-selenium 项目在 Selenium Grid 4.28.1 版本中为 Chrome 128.0.6613.137 镜像生成并打上全部标签的过程。通过对照根目录下的 tag_and_push_browser_images.sh 发布脚本源码读者可以彻底理解一套标签的命名构成规则、脚本参数的含义与默认值、短版本号的计算逻辑以及如何在 CIMakefile中触发这套发布流程最终在自己的测试环境中精准选择、拉取并验证对应版本的 Chrome 节点镜像。发布记录里发生了什么chrome_128.md是一份由发布脚本直接生成的执行日志记录了为 Chrome 128 镜像打标签并推送push的完整过程。日志开头的命令说明了本次发布的核心参数./tag_and_push_browser_images.sh 4.28.1 20250202 selenium false chrome true随后脚本依次输出了本次发布涉及的关键版本信息Selenium Grid 版本4.28.1-20250202Grid 版本号与构建日期的组合即脚本中的TAG_VERSIONChrome 版本128.0.6613.137Short Chrome 版本短版本128.0ChromeDriver 版本128.0.6613.137Short ChromeDriver 版本短版本128.0这里可以看到一个值得注意的事实Chrome 与 ChromeDriver 在该次发布中版本号完全一致128.0.6613.137这正是 Chrome for TestingCfT模式出现后 Chrome 与驱动版本严格对齐的典型表现。12 个标签的完整清单与命名拆解发布脚本为node-chrome与standalone-chrome两个镜像各打上了 6 个标签合计 12 个。原始记录如下Tagged selenium/node-chrome:128.0.6613.137-chromedriver-128.0.6613.137-grid-4.28.1-20250202 Tagged selenium/standalone-chrome:128.0.6613.137-chromedriver-128.0.6613.137-grid-4.28.1-20250202 Tagged selenium/node-chrome:128.0.6613.137-chromedriver-128.0.6613.137-20250202 Tagged selenium/standalone-chrome:128.0.6613.137-chromedriver-128.0.6613.137-20250202 Tagged selenium/node-chrome:128.0.6613.137-20250202 Tagged selenium/standalone-chrome:128.0.6613.137-20250202 Tagged selenium/node-chrome:128.0-chromedriver-128.0-grid-4.28.1-20250202 Tagged selenium/standalone-chrome:128.0-chromedriver-128.0-grid-4.28.1-20250202 Tagged selenium/node-chrome:128.0-chromedriver-128.0-20250202 Tagged selenium/standalone-chrome:128.0-chromedriver-128.0-20250202 Tagged selenium/node-chrome:128.0-20250202 Tagged selenium/standalone-chrome:128.0-20250202逐项拆解这 6 种标签后缀其语义分别是标签后缀示例语义128.0.6613.137-chromedriver-128.0.6613.137-grid-4.28.1-20250202完整浏览器版本 完整驱动版本 完整 Grid 版本 构建日期128.0.6613.137-chromedriver-128.0.6613.137-20250202完整浏览器版本 完整驱动版本 构建日期128.0.6613.137-20250202完整浏览器版本 构建日期128.0-chromedriver-128.0-grid-4.28.1-20250202短浏览器版本 短驱动版本 完整 Grid 版本 构建日期128.0-chromedriver-128.0-20250202短浏览器版本 短驱动版本 构建日期128.0-20250202短浏览器版本 构建日期每一类标签都同时打在node-chrome和standalone-chrome两个镜像上因为浏览器节点Node与独立Standalone形态共享同一套浏览器与驱动的组合区别只在于前者需配合 Hub 组成 Grid后者自带 Grid 服务。这套标签命名结构在 docs/docker-hub/node-chrome.md 中有官方化的描述其通用模板为selenium/node-chrome-browserVersion-browserDriver-browserDriverVersion-Major.Minor.Patch-YYYYMMDD以及简化形态selenium/node-chrome-Major.Minor.Patch-YYYYMMDD标签从何而来脚本源码中的生成逻辑这 12 个标签并不是手工拼写的而是 tag_and_push_browser_images.sh 在chrome分支中自动生成的。脚本首先通过docker run临时启动刚刚构建好的node-chrome:4.28.1-20250202镜像从容器内部探测真实的浏览器与驱动版本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})这两条命令分别从容器内的google-chrome --version与chromedriver --version输出中提取版本字段保证标签与镜像内实际安装的二进制版本严格一致而不是依赖构建参数中声明的版本号。随后脚本根据浏览器/驱动版本构造标签数组见 tag_and_push_browser_images.sh并循环调用retag函数为node-chrome与standalone-chrome同时打标签for chrome_tag in ${CHROME_TAGS[]}; do retag node-chrome ${chrome_tag} retag standalone-chrome ${chrome_tag} done从源码结构看脚本的其他分支chromium、edge、firefox、chrome-for-testing遵循完全相同的模式只是探测命令与驱动名不同例如 Edge 用microsoft-edge --version/msedgedriver --versionFirefox 用firefox --version/geckodriver --version。短版本号的由来short_version 函数日志中 Chrome 与 ChromeDriver 都输出了Short 版本128.0这一简化版本由脚本中的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]} }其逻辑是把完整版本号按.拆分成数组只取前两个数字主版本与次版本拼接。128.0.6613.137因此得到128.0。短版本标签的价值在于它提供了一个不随补丁版本变化的稳定入口当 Chrome 从128.0.6613.137升级到128.0.6613.140这类同主次版本的补丁发布时selenium/node-chrome:128.0-20250202这类标签无需改写即可滚动指向新的构建方便团队在测试配置中维持一个较长周期的稳定引用。脚本的七个参数与默认行为发布日志开头的命令是理解整个记录的关键其参数映射如下对应 tag_and_push_browser_images.sh 的位置参数解析位置命令中的值参数含义$14.28.1VERSIONSelenium Grid 版本号$220250202BUILD_DATE镜像构建日期YYYYMMDD$3seleniumNAMESPACEDocker Hub 命名空间$4falsePUSH_IMAGE是否在打标签后执行docker push默认false$5chromeBROWSER目标浏览器chrome / chromium / edge / firefox / chrome-for-testing$6trueRELEASE_OLD_VERSION是否为旧版本补发标签默认false$7未传PLATFORM探测版本时使用的平台默认linux/amd64其中RELEASE_OLD_VERSION参数直接决定了本日志中标签清单的长度。看脚本源码当该值为false即常规发布时标签数组会额外追加 4 个不带构建日期的纯版本标签见 tag_and_push_browser_images.sh${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION} ${CHROME_VERSION} ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION} ${CHROME_SHORT_VERSION}而本次记录中RELEASE_OLD_VERSIONtrue意味着这是一次对已归档旧版本的补发/补标操作因此不带构建日期的通用标签被跳过避免覆盖当前仍在滚动更新的latest语义标签只保留了带构建日期的 6 个标签这正是日志中恰好出现 12 条 Tagged 输出的原因。retag 与推送打标签与推送的实际动作日志中每条Tagged输出都来自retag()函数见 tag_and_push_browser_images.sh。默认路径下它的核心动作是docker tag ${__source} ${NAMESPACE}/${__image}:${__tag} echo Tagged ${NAMESPACE}/${__image}:${__tag} if [ ${PUSH_IMAGE} true ]; then docker push ${NAMESPACE}/${__image}:${__tag} fi即先基于已构建的selenium/node-chrome:4.28.1-20250202源镜像执行docker tag生成别名标签再根据PUSH_IMAGE决定是否执行docker push推送。本记录中PUSH_IMAGEfalse所以日志只停留在Tagged阶段——这也解释了记录里没有出现 push 相关输出。源码中还保留了PROMOTE_TAGS与PROMOTE_GHCR_NAMESPACE两个环境变量分支由发布工作流deploy.yml设置当发布直接复用已测试通过的镜像而非重新构建时retag()会改用docker buildx imagetools create在 registry 之间复制 manifest index从而保住多架构镜像特性并可同步镜像到 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)其中$(VERSION)、$(BUILD_DATE)、$(NAMESPACE)、$(PUSH_IMAGE)、$(RELEASE_OLD_VERSION)均由 Makefile 变量注入Makefile的.PHONY列表中也将tag_and_push_browser_images声明为伪目标。tag_and_push_browser_images_ghcr目标则对应上文提到的 GHCR 镜像镜像流程通过docker images枚举本地标签后逐一用docker buildx imagetools create打到$(GHCR_NAMESPACE)命名空间下。发布记录的来源与版本矩阵定位本记录存放于 CHANGELOG/README.md 定义的浏览器版本矩阵体系中。该 README 明确指出矩阵的目的在持续供给最新 Selenium Grid 核心版本的同时允许用户固定pin某个浏览器版本进行跨浏览器测试或规避特定浏览器版本的已知问题。矩阵表格中4.28.1行的 Chrome 128 列即链接到本文分析的chrome_128.md同目录下的chrome_127.md、chrome_126.md等文件结构与本文完全一致只是浏览器版本号不同。同时矩阵 README 也给出了重要免责声明项目并未对每个 Grid 版本 × 浏览器版本的组合都做全量测试用户需要依据自身测试需求自行评估组合可用性。如何用这套标签拉取并验证镜像理解了标签命名后实际使用就非常直观。例如在 README.md 描述的 Hub Node 模式下固定 Chrome 128 与 Grid 4.28.1docker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:4.28.1-20250202 docker run -d --net grid -e SE_EVENT_BUS_HOSTselenium-hub \ --shm-size2g \ selenium/node-chrome:128.0.6613.137-chromedriver-128.0.6613.137-grid-4.28.1-20250202若希望团队配置在补丁升级时保持稳定可选用短版本标签例如selenium/node-chrome:128.0-20250202。拉取后可通过与发布脚本相同的方式核对镜像内真实版本docker run --rm selenium/node-chrome:128.0-20250202 google-chrome --version docker run --rm selenium/node-chrome:128.0-20250202 chromedriver --version对照 CHANGELOG/archived/4.28.1/chrome_128.md 中的128.0.6613.137即可验证镜像内容与发布记录一致。README 同时提醒运行含浏览器的镜像务必携带--shm-size2g使用宿主机共享内存避免 Chrome 在容器内因/dev/shm过小而崩溃。版本来源的底层支撑NodeChrome 镜像构建标签中的版本号最终来源于 NodeChrome/Dockerfile 构建的镜像本身。该 Dockerfile 通过ARG CHROME_VERSIONgoogle-chrome-stable指定 Chrome 安装通道stable/beta/unstable并依次执行 NodeChrome/install-chrome.sh、NodeChrome/install-chromedriver.sh 完成浏览器与驱动的安装构建末尾还会把google-chrome --version解析出的版本写入/opt/selenium/browsers/chrome/version供 Grid 节点上报能力。install-chromedriver.sh中针对 Chrome 128 这类 115 以后的版本走 Chrome for TestingCfT下载源amd64 架构从chrome-for-testing-public存储桶获取与 Chrome 同版本号的驱动这也是日志中两者版本号一致的根本原因。小结chrome_128.md虽是一份简短的脚本输出但它是理解 docker-selenium 镜像发布与标签体系的理想样本一次命令、两次版本探测、12 个标签背后是脚本中参数化、短版本化、按RELEASE_OLD_VERSION裁剪标签数组、retag统一执行打标/推送的一套成熟设计。结合 tag_and_push_browser_images.sh 与 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点击查看免费下载相关推荐Task 实验性功能Experiments完整指南启用方式与从提案到发布的工作流Task 实验性功能Experiments完整指南启用方式与从提案到发布的工作流 Task 是一个受 Make 启发的快速、跨平台构建工具仓库见 REA测试后端云原生容器编排可观测性docker-selenium 浏览器镜像标签体系全解析以 Selenium Grid 4.28.1 与 Chrome 124 发布记录为例docker selenium 浏览器镜像标签体系全解析以 Selenium Grid 4.28.1 与 Chrome 124 发布记录为例 在 Seleni测试后端云原生容器编排可观测性docker-selenium 浏览器镜像多重标签发布机制解析——以 Selenium Grid 4.48.0 Chrome 104 发布记录为例docker selenium 浏览器镜像多重标签发布机制解析——以 Selenium Grid 4.48.0 Chrome 104 发布记录为例 本文以仓库中测试后端云原生容器编排可观测性上一篇Dependency Injector多容器管理复杂应用架构设计指南下一篇DBeaver驱动包终极指南一站式解决30数据库连接烦恼创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考