测试后端云原生容器编排可观测性【免费下载链接】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 仓库归档变更日志 CHANGELOG/archived/4.29.0/chrome_104.md 中记录的 Chrome 104 镜像打标日志为核心拆解其背后由 tag_and_push_browser_images.sh 驱动的标签生成机制。读者读完将掌握docker-selenium 镜像标签的完整命名约定、如何读懂一份浏览器镜像构建日志、如何根据测试需求精确挑选selenium/node-chrome与selenium/standalone-chrome的历史版本镜像以及如何复用该脚本生成自定义标签。一、这份归档日志记录了什么事CHANGELOG/archived/4.29.0/目录下的每个文件对应一次浏览器镜像发布记录。chrome_104.md的完整内容是一次tag_and_push_browser_images.sh脚本执行的标准输出./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 - 104.0.5112.101 Short Chrome version - 104.0 ChromeDriver version - 104.0.5112.79 Short ChromeDriver version - 104.0日志表明发布方在 2025 年 3 月 3 日构建日期20250303为 Selenium Grid4.29.0这一代归档版本补发/记录 Chrome104的镜像标签。其中包含三组关键版本事实组件完整版本短版本主.次Selenium Grid Server4.29.0-202503034.29Chrome 浏览器104.0.5112.101104.0ChromeDriver104.0.5112.79104.0日志末尾的 12 行Tagged ...则展示了脚本为selenium/node-chrome与selenium/standalone-chrome两个镜像各生成的 6 个标签下文第三节详解。这份日志之所以归档在4.29.0下是因为它对应 CHANGELOG/README.md 中“Archived Grid Versions”矩阵里的一个条目Grid 4.29.0 × Chrome 104用户可以通过矩阵上的 ✓ 链接逐版本查看这类打标明细。二、驱动这份日志的脚本tag_and_push_browser_images.sh2.1 脚本参数与本次调用的对应关系tag_and_push_browser_images.sh 是生成浏览器镜像标签的唯一入口它接收最多 7 个位置参数参数位置变量本次取值含义$1VERSION4.29.0Selenium Grid 版本号$2BUILD_DATE20250303构建日期YYYYMMDD$3NAMESPACEselenium镜像命名空间$4PUSH_IMAGEfalse是否执行docker push$5BROWSERchrome浏览器类型chrome/chromium/edge/firefox/chrome-for-testing$6RELEASE_OLD_VERSIONtrue是否追加纯版本号类标签$7PLATFORM默认linux/amd64查询版本信息时运行的平台脚本首先拼接出基础镜像标签TAG_VERSION${VERSION}-${BUILD_DATE}即4.29.0-20250303对应日志第 4 行Selenium Grid version - 4.29.0-20250303。2.2 浏览器版本信息的动态探测与人工填写版本号不同脚本通过临时运行已构建的node-chrome镜像来动态探测Chrome 与 ChromeDriver 的真实版本脚本第 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})google-chrome --version输出形如Google Chrome 104.0.5112.101取第 3 个字段得到104.0.5112.101chromedriver --version输出形如ChromeDriver 104.0.5112.79 ...取第 2 个字段得到104.0.5112.79short_version()函数脚本第 53-57 行以.分割版本号并保留前两段得到短版本104.0与日志第 6、8 行完全吻合。这种“以容器内真实二进制为准”的设计保证了标签永远与实际打包的浏览器一致不会出现版本漂移。同样的探测逻辑在脚本中还覆盖 chromium、edge、firefox、chrome-for-testing 分支每个分支的awk取字段位置各不相同如 Edge 取microsoft-edge --version的第 3 个字段、msedgedriver --version的第 4 个字段反映了各浏览器版本输出格式的差异。2.3 标签数组的构造规则脚本为 chrome 分支构建了CHROME_TAGS数组脚本第 75-99 行核心规律是“三段式组合”浏览器版本 × 驱动版本 × Grid 版本/构建日期并同时提供完整版本与短版本两套CHROME_TAGS( ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}-grid-${TAG_VERSION} ${CHROME_VERSION}-chromedriver-${CHROMEDRIVER_VERSION}-${BUILD_DATE} ${CHROME_VERSION}-${BUILD_DATE} ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}-grid-${TAG_VERSION} ${CHROME_SHORT_VERSION}-chromedriver-${CHROMEDRIVER_SHORT_VERSION}-${BUILD_DATE} ${CHROME_SHORT_VERSION}-${BUILD_DATE} )当RELEASE_OLD_VERSIONfalse时还会追加 4 个不带构建日期的“纯版本”标签104.0.5112.101-chromedriver-104.0.5112.79、104.0.5112.101、104.0-chromedriver-104.0、104.0。本次调用第 6 个参数为true即发布归档旧版本因此不追加纯版本标签最终每个镜像恰好生成 6 个标签。三、日志中的 12 个标签逐行解读将脚本的retag调用对node-chrome与standalone-chrome各执行一次展开就得到日志末尾的 12 行输出。以node-chrome为例6 个标签及其语义如下标签语义104.0.5112.101-chromedriver-104.0.5112.79-grid-4.29.0-20250303完整 Chrome/ChromeDriver 版本 Grid 版本 构建日期最精确104.0.5112.101-chromedriver-104.0.5112.79-20250303完整版本 构建日期不带 Grid 版本104.0.5112.101-20250303仅浏览器完整版本 构建日期104.0-chromedriver-104.0-grid-4.29.0-20250303短版本组合 Grid 版本 构建日期104.0-chromedriver-104.0-20250303短版本组合 构建日期104.0-20250303仅浏览器短版本 构建日期同样的 6 个标签同时打到standalone-chrome上形成镜像的“Node/Standalone”双形态。这种设计在 docs/docker-hub/node-chrome.md 与 docs/docker-hub/standalone-chrome.md 中有完整说明让使用者可以按精度需求选择标签追求可复现用“完整版本 grid 日期”最长标签追求便捷用最短的104.0-20250303即可锁定该次发布。3.1 retag 函数打标还是跨仓库镜像复制retag() 是实际执行打标的函数。常规路径下执行docker tag并将源镜像selenium/node-chrome:4.29.0-20250303打上目标标签若PUSH_IMAGEtrue则随后docker push。它还支持一种特殊模式当环境变量PROMOTE_TAGStrue时发布流水线直接推广已测试镜像而非重建改用docker buildx imagetools create在仓库与仓库之间复制多架构镜像清单——这是docker tag无法胜任的场景因为docker pull只能拉取运行者自身架构而imagetools直接操作 registry index可保留多架构属性。3.2 Makefile 如何编排这些目标根目录 Makefile第 781-808 行将上述调用封装为发布目标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 第 15-16 行PUSH_IMAGEfalse、RELEASE_OLD_VERSIONfalse。一次完整的make tag_and_push_browser_images会按顺序为五种浏览器镜像生成标签归档日志中的单条记录正是该流程中 chrome 分支的一次快照。四、如何利用归档版本标签落地测试4.1 直接拉取精确版本镜像基于本日志你可以在任意需要 Chrome 104 场景下使用docker pull selenium/node-chrome:104.0.5112.101-chromedriver-104.0.5112.79-grid-4.29.0-20250303 docker pull selenium/standalone-chrome:104.0-20250303重要前提4.29.0属于 CHANGELOG/README.md 中“Archived Grid Versions”归档段意味着这批标签对应的是历史发布适合复现旧版本兼容性问题、回归测试或锁定浏览器行为全新项目应优先使用最新 Grid 版本如当前 4.48.0 行对应的最新 Chrome 标签。同时该矩阵也明确提示项目并未对每一种 Grid × 浏览器组合做全量测试使用者需根据自身测试要求评估取舍。4.2 与 Node/Standalone 镜像结合使用标签里的node-chrome与standalone-chrome对应两种运行模式完整命令可参考 docs/docker-hub/node-chrome.md 与 docs/docker-hub/standalone-chrome.mdNode 模式加入 Hub 所在的 Docker 网络注册为 Grid 节点docker network create grid docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-hub selenium/hub:4.29.0-20250303 docker run -d --net grid -e SE_EVENT_BUS_HOSTselenium-hub \ --shm-size2g \ selenium/node-chrome:104.0-20250303Standalone 模式单容器自含 Grid适合本地快速验证docker run -d -p 4444:4444 -p 7900:7900 --shm-size2g \ selenium/standalone-chrome:104.0-20250303两条命令都带上了--shm-size2g这是运行含浏览器镜像时使用宿主机共享内存的标准实践测试代码统一指向http://localhost:4444可选通过http://localhost:7900/?autoconnect1resizescalepasswordsecret观察容器内界面。此外仓库根目录的 docker-compose-v3.yml 展示了将selenium/node-chrome纳入完整 Grid 编排的典型方式把其中的 tag 替换为本日志中的归档标签即可整体锁定到 Chrome 104。4.3 自定义打标按需复用脚本若你的内部流程需要为自己的镜像生成类似标签可直接按第三节的规则复用脚本。例如只打本地标签、不推送、且追加纯版本标签./tag_and_push_browser_images.sh 4.29.0 20250303 myregistry false chrome false此时会在myregistry/node-chrome与myregistry/standalone-chrome上额外生成104.0.5112.101、104.0等不带日期的标签便于后续按浏览器版本直接引用。跨架构或跨仓库复制场景则参考前文PROMOTE_TAGStrue与PROMOTE_GHCR_NAMESPACE环境变量的用法。五、标签与镜像构建的底层对应日志中的版本组合之所以可信是因为它们与 NodeChrome/Dockerfile 的构建逻辑一一对应Chrome 版本由ARG CHROME_VERSION默认google-chrome-stable控制也可通过ARG CHROME_DRIVER_VERSION固定 ChromeDriver 版本NodeChrome/Dockerfile 第 18-51 行构建阶段会把浏览器与驱动信息写入/opt/selenium/browsers/chrome/name、version、binary_location其中 version 提取方式与打标脚本一致——google-chrome --version | awk {print $3}Standalone/Dockerfile 以node-chrome为基础层叠加 Selenium Server 与start-selenium-standalone.sh因此standalone-chrome与node-chrome天然共享同一套浏览器版本标签。换句话说一份归档日志 一次完整发布动作的可复现证据从命令参数、版本探测到最终标签产物都被完整留存。需要横向对比不同浏览器chromium/edge/firefox在同一 Grid 版本的打标差异时可参照CHANGELOG/archived/4.29.0/下的同名日志文件如chrome_105.md、edge_133.md、firefox_136.md等它们的输出结构与本文解读的chrome_104.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点击查看免费下载相关推荐理解 docker-selenium 浏览器镜像标签体系以 Chrome 103 与 Selenium Grid 4.29.0 的归档记录为例理解 docker selenium 浏览器镜像标签体系以 Chrome 103 与 Selenium Grid 4.29.0 的归档记录为例 本文将围绕 d测试后端云原生容器编排可观测性docker-selenium 浏览器镜像 Tag 体系全解析以 Selenium Grid 4.29.0 Chrome 100 为例docker selenium 浏览器镜像 Tag 体系全解析以 Selenium Grid 4.29.0 Chrome 100 为例 本文以 CHANG测试后端云原生容器编排可观测性GyroFlow索尼镜头配置文件加载不出来三招从入门到源码修好GyroFlow索尼镜头配置文件加载不出来三招从入门到源码修好 你在 GyroFlow 里导入一段索尼素材画面突然黑掉或者镜头配置列表空着。这篇给你三招修测试后端云原生容器编排可观测性上一篇如何快速上手Chat AI Desktop5分钟完成安装配置的完整指南下一篇Swagger Codegen 生成 Dart(Jaguar) 客户端PetApi 全量接口调用实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考