Red Hat于8月5日宣布，RHEL 9与RHEL 10运行器镜像已经作为GitHub Actions托管大型运行器进入公开预览。使用RHEL部署生产应用的团队，可以直接在相同操作系统基础上执行构建与测试，减少CI环境和生产服务器之间的差异。
这批镜像由Red Hat与GitHub联合提供，当前面向组织级GitHub Actions使用。它们属于Linux x64基础系统镜像，开发团队可以在上面继续安装项目需要的编译器、依赖、配置和安全工具。
RHEL 9与10镜像进入托管运行器
GitHub Actions的大部分Linux托管任务过去运行在其他Linux发行版上。应用最终部署到RHEL时，软件包版本、默认配置、加密策略和系统行为可能不同，构建成功并不代表生产环境一定兼容。
新的RHEL 9与RHEL 10镜像把企业Linux直接放进GitHub托管运行器。团队可以在工作流中测试目标系统的依赖解析、脚本行为和应用打包，提前发现只会在RHEL环境中出现的问题。
镜像是基础运行环境，不会预装每个项目需要的完整工具链。工作流仍要明确安装软件、锁定依赖版本并保留构建记录，不能把操作系统一致等同于整个供应链完全一致。
使用范围限于组织级大型运行器
公开预览阶段需要在GitHub组织设置中创建大型运行器，再从Linux x64合作伙伴镜像里选择RHEL 9或RHEL 10。个人账户暂不支持这一入口。
创建完成后，工作流通过对应运行器组和标签调度任务。组织可以把不同仓库或团队分配到指定运行器组，避免所有项目共用一套权限和构建环境。
大型运行器属于GitHub托管资源，与用户自行维护的自托管服务器不同。团队不需要负责底层主机生命周期，但仍要管理工作流权限、机密变量、依赖来源与构建产物。
构建环境由Red Hat签名与扫描
Red Hat表示，运行器的主机操作系统环境由其构建和签名，镜像中的软件包在提供给GitHub前会经过跟踪、审计与漏洞扫描。这为需要核对操作系统来源的团队提供了更明确的基础。
CI/CD流水线常会拉取源代码、依赖、密钥和制品，运行器一旦被污染，风险可能继续进入最终发布包。使用受控的RHEL基础镜像能够减少未知系统差异，但并不能替代依赖签名、最小权限和制品验证。
Red Hat还建议结合精简的加固容器镜像降低无关软件包数量。软件越少，漏洞扫描产生的噪声通常越低，但团队仍要确认业务需要的库、证书和调试工具没有被一并删除。
相同操作系统有助于提前发现兼容问题
生产服务器运行RHEL时，直接在RHEL运行器上测试可以更早暴露包管理、SELinux、系统库和默认安全策略差异。对需要同时支持RHEL 9与10的软件，还可以建立并行任务验证两个版本。
这种一致性对编译型程序、系统服务、RPM打包和依赖底层库的应用更有价值。纯容器化应用也可能受益，因为镜像构建工具、签名流程与宿主机策略仍会影响流水线。
运行器环境与生产环境仍不完全相同。网络拓扑、存储、内核参数、硬件规格和长期运行状态不会仅靠同一发行版自动复制，最终上线前仍需要独立的预发布验证。
公开预览暂不提供正式SLA
Red Hat明确说明，公开预览代表功能已经可以进行技术测试并有正式文档，但现阶段不包含GitHub正式服务等级协议或技术支持义务。关键发布流程不应在没有备用方案的情况下立即全部迁移。
团队可以先选择非核心仓库测试排队时间、软件安装速度、缓存、网络访问、构建重复性和费用，再逐步扩大范围。涉及合规的项目还要确认公开预览是否符合内部采购与支持要求。
此次上线为RHEL生产环境与GitHub Actions之间补上了更一致的托管构建层。真正进入关键流水线之前，仍需等待预览阶段的稳定性数据、正式支持范围与后续商用公告。
