把 GitHub Actions 的 self-hosted runner 放进 Modal Sandbox 里按需运行很多人第一次听到会觉得很绕GitHub Actions 本身不是有现成的 runner 吗为什么还要用 Modal 再套一层但如果你维护过 CI 流水线尤其是项目里需要 GPU、高频并发构建、隔离环境或者不想长期养一台 CI 服务器的时候就会发现这个组合非常实用。本文围绕“如何用 Modal Sandboxes 启动临时 GitHub Actions self-hosted runner”展开会先讲清楚原理再给出一套可以照着复现的代码和 workflow 示例。如果你已经熟悉 GitHub Actions但对 self-hosted runner 的维护成本和安全边界一直不太满意或者你正在找一个“用多少付多少、跑完即销毁”的 CI 方案这篇文章应该能给你一个可行的起点。1. 背景与核心概念1.1 GitHub Actions 默认 Runner 的限制GitHub Actions 默认提供的 runner 是 GitHub 托管的虚拟机覆盖了 ubuntu-latest、windows-latest、macos-latest 等常用环境。对大多数普通项目来说默认 runner 开箱即用不需要关心硬件、系统镜像或网络配置。但实际使用中会遇到下面几个问题并发配额有限免费额度用完以后或者企业账号并发数不够时job 只能排队。硬件规格固定默认 runner 的 CPU、内存是固定的且不支持 GPU。环境不持久每次 job 都是全新的虚拟机虽然干净但如果要预装大量依赖每次都要重新下载。网络策略固定默认 runner 的网络出口统一很多企业希望 CI 能跑在自己的内网环境里。这时很多人会选择自建 runner也就是 self-hosted runner。1.2 Self-Hosted Runner 的痛点self-hosted runner 的思路很简单你找一台机器下载 GitHub 提供的 runner 软件注册到仓库或组织里之后 GitHub Actions 就会把 job 派发给这台机器执行。优点是显而易见的硬件完全自定义可以挂大内存、多核 CPU、GPU。可以访问内网资源。可以预装依赖避免每次重复安装。不消耗 GitHub 托管的免费额度。但问题也很明显机器需要长期运行哪怕没有 job 也在空转。为了高可用通常要用 ASG、K8s 或者多台虚拟机做弹性伸缩维护成本高。runner 长期驻留在宿主机上job 的执行环境可能残留上一个人的文件、环境变量甚至恶意脚本。如果 runner 同时挂多个 job资源竞争会导致构建不稳定。安全问题突出尤其对于公开仓库任何人都可能提交 PR 来触发 job恶意代码可能直接在你的机器上执行。在这些问题中最让人头疼的是“维护成本”和“安全性”。你本来想让 CI 更可控结果发现自己还要维护一套 CI 基础设施。1.3 Modal Sandbox 是什么Modal 是一个云端计算平台核心能力是运行 Python 函数、容器和作业。它最大的特点就是“按需”和“隔离”。Modal Sandbox 是 Modal 提供的一种隔离运行环境可以理解为一个临时的云沙箱。你可以指定镜像、CPU、内存、GPU按需创建任务跑完以后销毁。和传统的虚拟机相比Modal Sandbox 有几个优势创建速度快秒级启动。按用量计费不用的时候不花钱。环境隔离每个 Sandbox 之间互不影响。可以通过代码定义镜像和运行参数容易和 CI/CD 集成。正因为这些特性Modal Sandbox 很适合用来跑临时任务。而 GitHub Actions 的 self-hosted runner本质上就是一个“需要跑完 job 就退出”的临时进程。这两者天然契合。1.4 为什么把两者结合起来把 GitHub Actions self-hosted runner 放到 Modal Sandbox 里核心思路是每次需要执行 CI job 时创建一个临时的 Modal Sandbox在 Sandbox 里启动一个 runnerrunner 注册到 GitHub领取并执行 job完成后 Sandbox 销毁。这样做的好处非常明确不再需要常驻服务器按 job 按需启动。runner 生命周期极短job 结束环境就销毁安全性和隔离性远好于传统 self-hosted runner。可以在 Sandbox 里定义任意镜像、系统依赖、GPU 环境。弹性天然具备并发 job 多就多创建几个 Sandbox。当然这也带来了一些新的问题比如 runner 启动需要时间、Sandbox 内环境是否和本地一致、网络出口如何连通 GitHub 等。这部分放在后面章节详细讨论。2. 整体方案与工作流程2.1 架构成员这套方案涉及的组件不多核心有四个组件作用GitHub Actionsworkflow 的定义和 job 调度平台GitHub Actions Runner真正执行 job 的本地进程运行在 Modal Sandbox 内Modal Sandbox提供临时的、隔离的云端运行环境GitHub Personal Access Token / GitHub App用于生成 runner 注册所需的 registration token2.2 一次 job 的完整生命周期为了便于理解我们把一次构建的流程拆成下面几步执行modal run runner.py或通过 CI 触发一个启动脚本。Modal 根据代码中的镜像和资源参数创建 Sandbox。Sandbox 内下载 GitHub Actions runner 解压包。通过 GitHub API 获取仓库级 registration token。执行config.sh让 runner
把 GitHub Actions 的 self-hosted runner 放进 Modal Sandbox 里按需运行很多人第一次听到会觉得很绕GitHub Actions 本身不是有现成的 runner 吗为什么还要用 Modal 再套一层但如果你维护过 CI 流水线尤其是项目里需要 GPU、高频并发构建、隔离环境或者不想长期养一台 CI 服务器的时候就会发现这个组合非常实用。本文围绕“如何用 Modal Sandboxes 启动临时 GitHub Actions self-hosted runner”展开会先讲清楚原理再给出一套可以照着复现的代码和 workflow 示例。如果你已经熟悉 GitHub Actions但对 self-hosted runner 的维护成本和安全边界一直不太满意或者你正在找一个“用多少付多少、跑完即销毁”的 CI 方案这篇文章应该能给你一个可行的起点。1. 背景与核心概念1.1 GitHub Actions 默认 Runner 的限制GitHub Actions 默认提供的 runner 是 GitHub 托管的虚拟机覆盖了 ubuntu-latest、windows-latest、macos-latest 等常用环境。对大多数普通项目来说默认 runner 开箱即用不需要关心硬件、系统镜像或网络配置。但实际使用中会遇到下面几个问题并发配额有限免费额度用完以后或者企业账号并发数不够时job 只能排队。硬件规格固定默认 runner 的 CPU、内存是固定的且不支持 GPU。环境不持久每次 job 都是全新的虚拟机虽然干净但如果要预装大量依赖每次都要重新下载。网络策略固定默认 runner 的网络出口统一很多企业希望 CI 能跑在自己的内网环境里。这时很多人会选择自建 runner也就是 self-hosted runner。1.2 Self-Hosted Runner 的痛点self-hosted runner 的思路很简单你找一台机器下载 GitHub 提供的 runner 软件注册到仓库或组织里之后 GitHub Actions 就会把 job 派发给这台机器执行。优点是显而易见的硬件完全自定义可以挂大内存、多核 CPU、GPU。可以访问内网资源。可以预装依赖避免每次重复安装。不消耗 GitHub 托管的免费额度。但问题也很明显机器需要长期运行哪怕没有 job 也在空转。为了高可用通常要用 ASG、K8s 或者多台虚拟机做弹性伸缩维护成本高。runner 长期驻留在宿主机上job 的执行环境可能残留上一个人的文件、环境变量甚至恶意脚本。如果 runner 同时挂多个 job资源竞争会导致构建不稳定。安全问题突出尤其对于公开仓库任何人都可能提交 PR 来触发 job恶意代码可能直接在你的机器上执行。在这些问题中最让人头疼的是“维护成本”和“安全性”。你本来想让 CI 更可控结果发现自己还要维护一套 CI 基础设施。1.3 Modal Sandbox 是什么Modal 是一个云端计算平台核心能力是运行 Python 函数、容器和作业。它最大的特点就是“按需”和“隔离”。Modal Sandbox 是 Modal 提供的一种隔离运行环境可以理解为一个临时的云沙箱。你可以指定镜像、CPU、内存、GPU按需创建任务跑完以后销毁。和传统的虚拟机相比Modal Sandbox 有几个优势创建速度快秒级启动。按用量计费不用的时候不花钱。环境隔离每个 Sandbox 之间互不影响。可以通过代码定义镜像和运行参数容易和 CI/CD 集成。正因为这些特性Modal Sandbox 很适合用来跑临时任务。而 GitHub Actions 的 self-hosted runner本质上就是一个“需要跑完 job 就退出”的临时进程。这两者天然契合。1.4 为什么把两者结合起来把 GitHub Actions self-hosted runner 放到 Modal Sandbox 里核心思路是每次需要执行 CI job 时创建一个临时的 Modal Sandbox在 Sandbox 里启动一个 runnerrunner 注册到 GitHub领取并执行 job完成后 Sandbox 销毁。这样做的好处非常明确不再需要常驻服务器按 job 按需启动。runner 生命周期极短job 结束环境就销毁安全性和隔离性远好于传统 self-hosted runner。可以在 Sandbox 里定义任意镜像、系统依赖、GPU 环境。弹性天然具备并发 job 多就多创建几个 Sandbox。当然这也带来了一些新的问题比如 runner 启动需要时间、Sandbox 内环境是否和本地一致、网络出口如何连通 GitHub 等。这部分放在后面章节详细讨论。2. 整体方案与工作流程2.1 架构成员这套方案涉及的组件不多核心有四个组件作用GitHub Actionsworkflow 的定义和 job 调度平台GitHub Actions Runner真正执行 job 的本地进程运行在 Modal Sandbox 内Modal Sandbox提供临时的、隔离的云端运行环境GitHub Personal Access Token / GitHub App用于生成 runner 注册所需的 registration token2.2 一次 job 的完整生命周期为了便于理解我们把一次构建的流程拆成下面几步执行modal run runner.py或通过 CI 触发一个启动脚本。Modal 根据代码中的镜像和资源参数创建 Sandbox。Sandbox 内下载 GitHub Actions runner 解压包。通过 GitHub API 获取仓库级 registration token。执行config.sh让 runner
