Selenium Grid 镜像新增 GHCR 官方渠道

官方新增镜像分发渠道

2026年4月4日, Grid官方博客正式发布了一则公告, 该公告确认了镜像仓库已经同步上架到了GitHub Container Registry, 并且统一使用ghcr.io/作为命名空间。这一调整为之企业用户提供了新的镜像的拉从途径之了。

官方清晰表明, 此次上线单单是当作新增的分散站点, 而非进行迁移或者将原有的渠道予以替换。Docker Hub依旧还是Grid的官方分散体系, 现有的布置配置不需要作出任何的变更, 团队能够持续正常地运用原有的镜像地址。

解决企业网络访问难题

企业用户于镜像拉取进程里遭遇的实际难题, 乃是此次调整的起始缘由。一些公司由于安全策略方面的限制, 没办法访问Docker Hub, 或者期望在托管的环境之中对所有依赖项进行统一管理, 而新增的GHCR渠道恰恰契合了这样的需求。

将仓库前缀替换为GHCR区域, 并使其变更为需要的访问策略, 这是用户必须要做的事儿。镜像名称以及标签规则得和原来习惯契合度契合, 切换成本特别低, 只需要把仓库地址配置给修改过来就行咯。

需求源于社区长期反馈

最早推动相关需求的是这个新增渠道, 它是由Grid仓库的第2939号议题引发的, 此议题在2025年8月27日被提交, 起初讨论主要围绕Docker Hub的拉取限额问题展开, 其后渐渐扩展至更多企业场景。

有多个实际问题被议题讨论所覆盖, 具体如下: 企业禁用Docker Hub致使部署受到阻碍, 分支任务没办法正常运行, 本地开发环境无法达成Hub身份验证等情况。在新增GHCR渠道之后, 团队于遭遇仓库限额或者服务中断时拥有了备选方案。

镜像覆盖范围已全量同步

官方发布的信息显示, GHCR对所有Grid镜像的标签实现了全量覆盖, 正式发布的镜像都已上线。官方博客所点名的首个完整发布标签是4.42.0版本, 后续仓库的改动把Dev和Beta浏览器镜像也纳入到了同步的范围。

是需要特别加以注意的, 最终的命名空间它是ghcr.io, 而并非是早期需求示例所呈现出来的格式。当进行固定版本部署这个行为的时候, 一定要锁死那明确的标签, 千万不要错误地认为新增了仓库就能使得标签内容长久地固定维持下去。

历史版本同样可用

于2026年发布的官方所提供的4.41.0历史版本入口, 能够对旧项目兼容, 可用于自动化测试环境复现以及Grid版本对比。此版本在GHCR仓库也能被找到, 如此方便团队呢进行版本回退之际的对照测试。

针对那生产环境来讲, GHCR引发的直接收益乃是增添了分发弹性, 并不会给Grid自身增加任何全新功能。团队于切换之前依旧需要核查公司对GHCR的访问许可、缓存代理规则以及镜像签入流程。

双渠道并存供用户选择

官方没有宣告停止Docker Hub服务一事, 也并没有要求全部用户一致迁移到新渠道。两条分发渠道会长期一同存在, 团队能够依据自身的网络状况、合规要求以及持续集成条件, 自由挑选最为合适的镜像来源。

相关的所有规则, 是以官方博客以及组织的公开页面作为标准的, 在进行部署以前,建议再次去核对当下的镜像覆盖范围, 以及标签状态如何, 以此来确保所选择的路径, 是契合企业实际使用需求状况的。

目前, 你的团队所使用的是Docker Hub, 还是已然切换到了GHCR? 于实际部署进程当中, 遭遇了哪些网络方面或者合规相关的问题? 欢迎在评论区域分享你的经验以及看法。