如何用 runner-images 自建 GitHub Actions Runner 镜像3 个场景跑通构建、裁剪与验证【免费下载链接】runner-imagesGitHub Actions runner images项目地址: https://gitcode.com/GitHub_Trending/ru/runner-imagesrunner-images 是 GitHub 托管 Runner 的虚拟机镜像定义仓库Ubuntu、Windows、macOS 三族镜像的构建步骤、预装软件清单都在这里你可以直接拿它构建自己的镜像。本文带你走三个真实场景首次构建一张 Ubuntu 24.04 镜像、用 toolset 裁剪预装版本、部署自建镜像并跑通 post-generation 脚本。快速上手最短路径构建一张镜像构建 agent 上装好四样东西Packer 1.8.2、Git、PowerShell 5.0、Azure CLI然后 clone 仓库git clone https://gitcode.com/GitHub_Trending/ru/runner-images进入目录。下面这段命令通过仓库自带的辅助函数创建 Azure 资源并触发 Packer 构建。优先用它而不是裸调packer build——你要少传 10 来个模板变量资源组的创建和清理它也帮你做了Import-Module .\helpers\GenerateResourcesAndImage.ps1 GenerateResourcesAndImage -SubscriptionId 你的订阅ID -ResourceGroupName imagegen-test -AzureLocation East US -ImageType Ubuntu2404跑完后资源组里会出现名为Runner-Image-Ubuntu2404的托管镜像managed image构建全程在 Packer 日志里可以看到临时 VM 的创建、逐条软件安装步骤和最终销毁。场景一首次构建一张 Ubuntu 24.04 镜像场景设定团队想在自有 Azure 订阅上复刻一张官方 Ubuntu 24.04 镜像用于验证自托管 Runner。关键取舍用辅助函数不裸调 Packer。直接packer build需要手传订阅、租户、密钥、位置、镜像名等一长串变量见images/ubuntu/templates/variable.ubuntu.pkr.hcl漏一个就报错辅助函数把这些都收敛成 4 个参数。代价是它的定制项少一些需要打 Tag、走私有 VNet 时才得回退到原生 Packer。认证用 Service Principal别用交互式登录。函数默认会弹交互式登录放进 CI 会卡死提前建好 SP 并传AzureClientId、AzureClientSecret、AzureTenantId三个参数。坚持用 main 分支构建。仓库的 tag 只是文档里程碑快照旧 tag 上的构建不是幂等的不保证能成功main 才是官方推荐的构建源。如何验证生效确认资源组里出现了Runner-Image-Ubuntu2404镜像且构建期间创建过的临时资源组已被删除。场景二用 toolset 裁剪预装版本缩短构建时间场景设定官方 toolset 默认预装 Python 5 个大版本、Node 2 个 LTS、Go 3 个版本构建一张全量镜像耗时不短。你的流水线只固定用 Python 3.12 和 Go 1.24其余都是浪费。关键取舍镜像里装什么由images/ubuntu/toolsets/toolset-2404.json声明把versions数组砍到只剩需要的版本构建时间和镜像体积都会明显下降。代价是多版本并存的便利没了——工作流如果哪天想用 Python 3.10就得在流水线里用 setup 动作临时安装。取舍原则只删你确定不用的拿不准的先留。注意版本字段支持通配符3.12.*且 toolset 改动要符合 schemas/toolset-schema.json 的约束。{ name: Python, versions: [ 3.12.* ] }如何验证生效改完重新构建对比 Packer 日志中 toolcache 阶段的耗时再跑一遍 images/ubuntu/scripts/tests/ 里的测试确认没把依赖被删版本的检查跑挂。场景三部署自建镜像跑通 post-generation 脚本场景设定镜像已经生成现在要真正拿它起一台 VM 当 Runner 用。这里最容易踩坑的是构建期用的用户不存在于最终镜像里所以一些用户目录相关的环境变量、目录权限需要在部署后一次性修正也就是 post-generation 脚本。关键取舍部署这一步优先用仓库的现成函数它顺带把网络资源建好让 VM 可访问Import-Module .\helpers\CreateAzureVMFromPackerTemplate.ps1 CreateAzureVMFromPackerTemplate -SubscriptionId 订阅ID -ResourceGroupName imagegen-test -ManagedImageName Runner-Image-Ubuntu2404 -VirtualMachineName testvm1 -AdminUsername shady1 -AdminPassword 强密码 -AzureLocation eastusVM 起来后以有 sudo 权限的默认用户执行 post-generation 脚本脚本构建时已被复制进镜像的/opt/post-generationsudo su -c find /opt/post-generation -mindepth 1 -maxdepth 1 -type f -name *.sh -exec bash {} \;如何验证生效grep -i HOME /etc/environment应指向当前用户的家目录/var/log里构建期日志已被清理再检查 Rust 相关目录属主是否已修正。这几项没做Runner 装上去后环境变量和权限都会出怪问题。运行与扩展三个高频运维问题现象构建中途失败整个流程中止Packer 的设计是任何安装步骤失败就中止并终止临时 VM所以日志停在哪一步问题就在哪一步。先翻 Packer 输出定位失败步骤再看 Azure 资源组——临时资源组理论上自动清理有残留就手动删掉再重跑避免命名冲突。现象构建耗时超出预算两条路一是调 builders 段的vm_size构建机越大约快越多且这个规格不影响你之后用镜像起的 VM二是回到场景二砍 toolset 里不用的版本。两条可以叠加。现象没改任何配置CI 行为却变了镜像每周滚动更新同一个 YAML 标签下的软件版本会漂移。建议订阅 releases 感知变更如果流水线对版本敏感把ubuntu-latest换成固定标签如ubuntu-24.04。官方迁移-latest标签会提前 1-2 个月公告留意 Announcements 即可。某次构建实际用了哪个版本看 job 日志里Set up job步骤打印的镜像版本号。这套仓库把镜像里装什么和怎么装拆成了 toolset 与 Packer 模板两层维护起来是清晰的——代价是构建链路涉及 Azure 资源、模板、脚本三处上手门槛比写个 Dockerfile 高。按上面的路径走一遍基本就通了。下一步完整构建与部署文档docs/create-image-and-azure-resources.mdPacker 模板与变量定义images/ubuntu/templates/toolset 格式约束schemas/toolset-schema.json各镜像预装软件清单images/ubuntu/Ubuntu2404-Readme.md【免费下载链接】runner-imagesGitHub Actions runner images项目地址: https://gitcode.com/GitHub_Trending/ru/runner-images创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考