测试后端云原生容器编排可观测性【免费下载链接】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_133.md 发布记录为核心完整拆解该项目为 Chrome 133.0.6943.141 生成的全部镜像标签并结合 tag_and_push_browser_images.sh 与 Makefile 中的实现细节说明浏览器镜像的版本探测、标签命名规则、发布参数与多架构镜像处理原理。读完本文你将掌握 docker-selenium 浏览器镜像node/standalone 系列的标签语义能够按需精确拉取指定 Chrome ChromeDriver Selenium Grid 组合的镜像并理解该仓库浏览器镜像发布流水线的工作方式。一、记录背景一次完整的 Chrome 133 镜像打标签发布CHANGELOG/archived/4.32.0/目录保存的是 Selenium Grid 4.32.0 版本周期内各浏览器镜像发布时实际执行的打标签脚本输出。其中 chrome_133.md 完整记录了 2025 年 5 月 15 日为 Chrome 133 执行的一次发布./tag_and_push_browser_images.sh 4.32.0 20250515 selenium false chrome true Tagging images for browser chrome, version 4.32.0, build date 20250515, namespace selenium Selenium Grid version - 4.32.0-20250515 Chrome version - 133.0.6943.141 Short Chrome version - 133.0 ChromeDriver version - 133.0.6943.141 Short ChromeDriver version - 133.0 Tagged selenium/node-chrome:133.0.6943.141-chromedriver-133.0.6943.141-grid-4.32.0-20250515 Tagged selenium/standalone-chrome:133.0.6943.141-chromedriver-133.0.6943.141-grid-4.32.0-20250515 ...这组输出并非随意文本它对应着仓库中真实存在的发布脚本的一次调用。命令行上的 7 个位置参数分别定义了这次发布的关键属性位置取值含义$14.32.0Selenium Grid 版本号VERSION$220250515构建日期BUILD_DATE决定基础标签4.32.0-20250515$3selenium镜像命名空间NAMESPACE即 Docker Hub 上的组织名$4false是否立即推送PUSH_IMAGE本次只打标签不推送$5chrome浏览器类型BROWSER脚本的分支选择依据$6true是否为旧版本补发标签RELEASE_OLD_VERSION$7缺省目标平台PLATFORM缺省为linux/amd64同类归档记录还包含 Edge 133edge_133.mdEdge 133.0.3065.92 EdgeDriver 133.0.3065.92与 Firefox 135firefox_135.mdFirefox 135.0.1 GeckoDriver 0.36.0说明该打标签机制对 Chrome、Chromium、Edge、Firefox、Chrome for Testing 五种浏览器一视同仁本文以 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})即先假定镜像selenium/node-chrome:4.32.0-20250515已构建完成然后用docker run --rm在容器内执行google-chrome --version取输出第 3 个字段得到133.0.6943.141同理执行chromedriver --version取第 2 个字段得到133.0.6943.141再由short_version()函数把133.0.6943.141截断为133.0取前两段用于生成短版本标签。function short_version() { local __long_version$1 local __version_split(${__long_version//./ }) echo ${__version_split[0]}.${__version_split[1]} }各浏览器分支的字段提取位置略有差异例如 Firefox 分支取firefox --version的第 3 个字段与geckodriver --version首行的第 2 个字段Edge 分支取microsoft-edge --version第 3 个字段与msedgedriver --version第 4 个字段。这也解释了为什么 CHANGELOG 中各浏览器记录的输出格式彼此不同——它们忠实反映了各自命令的实际输出结构。为什么版本会与 Grid 版本解耦因为浏览器二进制是在构建镜像时由镜像内脚本安装的。以 NodeChrome/Dockerfile 为例install-chrome.sh默认安装google-chrome-stable渠道可通过CHROME_VERSION构建参数指定具体版本见 install-chrome.shinstall-chromedriver.sh则默认根据已安装 Chrome 的主版本号自动匹配 ChromeDriver见 install-chromedriver.sh。因此同一个 Grid 4.32.0 周期内可以同时发布 Chrome 133、134、135 等多套浏览器镜像标签体系必须同时承载 Grid 版本、浏览器版本、驱动版本三个维度。三、标签体系一次发布生成的 10 类标签脚本为node-chrome与standalone-chrome各生成一套完全平行的标签见 tag_and_push_browser_images.sh因为这两类镜像内容相同只是启动形态不同Node 角色接入 GridStandalone 自包含。归档记录中实际产出的标签可归纳为以下五组1. 全版本 Grid 版本最长标签信息最全133.0.6943.141-chromedriver-133.0.6943.141-grid-4.32.0-20250515格式为Chrome全版本-chromedriver-ChromeDriver全版本-grid-Grid版本-构建日期一次锁定浏览器、驱动、Grid 三个版本维度适合需要严格复现测试环境的场景。2. 全版本 构建日期133.0.6943.141-chromedriver-133.0.6943.141-20250515 133.0.6943.141-20250515前者同时锁定浏览器与驱动后者只锁定浏览器版本与构建日期驱动随 Chrome 自动匹配。3. 短版本 Grid 版本 / 构建日期本组共 5 个133.0-chromedriver-133.0-grid-4.32.0-20250515 133.0-chromedriver-133.0-20250515 133.0-20250515使用133.0短版本号表示该大版本下的最新小版本适合日常使用——当 Chrome 133 系列发布新补丁时重新构建并覆盖这些标签即可。4. 无日期前缀的裸版本标签本组 4 个133.0.6943.141-chromedriver-133.0.6943.141 133.0.6943.141 133.0-chromedriver-133.0 133.0这些是最常用、最易记的标签。注意它们在脚本中受RELEASE_OLD_VERSION参数控制只有当$6为false即当前周期首个版本时才生成避免旧版本覆盖新版本的裸标签。5. 镜像名 × 标签的完整组合归档记录显示每个标签都同时打到selenium/node-chrome和selenium/standalone-chrome两个镜像上对应脚本末尾的循环for chrome_tag in ${CHROME_TAGS[]}; do retag node-chrome ${chrome_tag} retag standalone-chrome ${chrome_tag} done四、retag与PUSH_IMAGE本地打标签与推送的分工所有标签都是通过统一的retag()函数落地的见 tag_and_push_browser_images.shfunction retag() { local __image$1 local __tag$2 local __source${NAMESPACE}/${__image}:${TAG_VERSION} if [ ${PROMOTE_TAGS} true ]; then docker buildx imagetools create ... return fi 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.32.0-20250515复制出第 3 节所列的所有别名标签。归档记录中PUSH_IMAGEfalse所以只执行docker tag与echo Tagged ...——这正是记录里每一行Tagged输出的来源。若第五个参数改为true每个标签都会紧跟一次docker push。此外retag还支持PROMOTE_TAGStrue的发布优化路径当测试已通过、发布时希望直接推广已验证镜像而非重新构建时改用docker buildx imagetools create在 registry 之间复制多架构 manifest index避免docker tag只能操作本地单架构镜像的限制。该机制同时受PROMOTE_GHCR_NAMESPACE控制可在一个调用内同步镜像到 GHCR 命名空间。五、如何用这些标签拉取与运行镜像理解标签体系后实际使用就非常直接。以归档记录对应的 4.32.0 版本为例# 锁定 Chrome 133 全版本 对应 ChromeDriver Grid 4.32.0 docker pull selenium/node-chrome:133.0.6943.141-chromedriver-133.0.6943.141-grid-4.32.0-20250515 # 日常使用短版本标签取 133 系列最新补丁 docker pull selenium/node-chrome:133.0 docker pull selenium/standalone-chrome:133.0在 compose 编排中镜像标签直接写在image字段。参考当前仓库的 docker-compose-v3.yml将selenium-hub与各浏览器节点组合成 Gridservices: chrome: image: selenium/node-chrome:4.48.0-20260905 # 当前版本示例可替换为任意上述标签 platform: linux/amd64 shm_size: 2gb depends_on: - selenium-hub environment: - SE_EVENT_BUS_HOSTselenium-hub selenium-hub: image: selenium/hub:4.48.0-20260905 container_name: selenium-hub ports: - 4442:4442 - 4443:4443 - 4444:4444建议的版本选择原则CI 环境、需要结果可复现使用第 1 组最长标签三版本维度全部固定日常开发、跟随补丁使用133.0短标签自动跟进该大版本的最新构建跨浏览器矩阵可同时部署 chrome/edge/firefox 节点分别对应 node-chrome、node-edge、node-firefox并配合SE_EVENT_BUS_HOST指向 Hub实现多浏览器并行自动化。六、发布流程自动化Makefile 中的编排打标签脚本不是孤立运行的它被 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均可在命令行覆盖例如make tag_and_push_chrome_images VERSION4.32.0 BUILD_DATE20250515 PUSH_IMAGEtrue该目标的设计动因在 Makefile 注释中说明它源于 SeleniumHQ/docker-selenium#992 对应的需求为浏览器镜像提供更丰富的附加标签让用户无需知道完整的三段式版本就能通过selenium/node-chrome:133.0这类易记标签拉取镜像。归档记录中$6传true的场景对应旧版本补发RELEASE_OLD_VERSIONtrue时不生成第 4 组裸版本标签从而保护已存在的裸标签不被旧版本覆盖。七、版本一致性的底层保障安装脚本如何保证 Chrome 与 ChromeDriver 同步标签中的Chrome 133.0.6943.141与ChromeDriver 133.0.6943.141完全一致并非巧合而是镜像构建脚本刻意保证的结果install-chromedriver.sh 在未显式指定CHROME_DRIVER_VERSION时会先执行google-chrome --version提取主版本号如133再据此解析驱动来源与版本amd64 平台上从 Chrome for Testing 官方渠道获取同版本 ChromeDriverCfT 保证了版本号完全对应旧版本Chrome 115则走chromedriver.storage.googleapis.com的LATEST_RELEASE_major接口非 amd64 架构如 arm64因 Google 不发布对应 ChromeDriver回退到 Debian 的chromium-driver包版本号带-1修订后缀脚本会剥离去掉从而保证驱动主版本与 Chrome 一致。因此标签中chromedriver-133.0.6943.141与133.0.6943.141的完全同步是安装脚本版本解析逻辑的必然结果也是该标签体系可靠性的基础。若需构建自定义版本组合可在构建时通过 NodeChrome/Dockerfile 暴露的CHROME_VERSION、CHROME_DRIVER_VERSION等ARG覆盖。八、小结读懂一张发布记录的三个要点三个版本维度每条浏览器标签同时表达 Grid 版本、浏览器版本、驱动版本归档记录中的每一行Tagged都是 tag_and_push_browser_images.sh 中retag()的一次真实输出两种长度全版本标签用于精确复现短版本标签133.0用于跟随大版本补丁两者由short_version()从探测到的完整版本派生一套发布参数VERSION/BUILD_DATE/NAMESPACE/PUSH_IMAGE/BROWSER/RELEASE_OLD_VERSION/PLATFORM七个参数完全决定一次发布的标签范围与推送行为配合 Makefile 的make tag_and_push_*_images目标即可复用整套流程。对照阅读同目录下的 edge_133.md、firefox_135.md或当前周期的 chrome-for-testing_141.md可以确认这套机制在 Edge/Firefox/Chromium/Chrome for Testing 上以完全一致的逻辑运行——这正是 docker-selenium 多浏览器镜像矩阵发布的核心支撑。赞分享测试后端云原生容器编排可观测性【免费下载链接】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 123 发布记录读懂 tag_and_push_browser_images.shdocker selenium 浏览器镜像标签体系详解从 Chrome 123 发布记录读懂 tag_and_push_browser_images.sh 本测试后端云原生容器编排可观测性docker-selenium 浏览器镜像标签体系全解从 Chrome 96 的标签生成记录看 tag_and_push_browser_images.sh 的版本化发布机制docker selenium 浏览器镜像标签体系全解从 Chrome 96 的标签生成记录看 tag_and_push_browser_images.sh测试后端云原生容器编排可观测性docker-selenium 浏览器镜像标签体系与 tag_and_push_browser_images.sh 全解析以 Chrome 115 发布记录为例docker selenium 浏览器镜像标签体系与 tag_and_push_browser_images.sh 全解析以 Chrome 115 发布记录为测试后端云原生容器编排可观测性上一篇Paperless-ngx把一摞纸质发票变成一秒钟搜到的档案下一篇Unstract FileManagement API面向组织的文件列表、下载与上传 REST 接口全解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考